You first need to define:
- What is to be delivered.
- How you validate delivery.
Both traditional and agile methodologies have to answer this question, but they come at it from different directions.
Traditional schemes try to capture the fullest possible set of requirements upfront. This is where you'll read about stuff like Work Breakdown Structures or Earned Value Management. Approached from this direction, "every" requirement has a place in the overall structure of the project. It becomes necessary to control that set of requirements quite rigidly. In such schemes, every item in the Work Breakdown Structure is numbered, described and given rules that allow you to count it as "done". Often this might be some customer acceptance plan or signoff.
Agile instead gets a set of whatever-we-thought-of, then periodically re-prioritises the set. Instead of trying to know everything in advance, you just do a lot of mid-course correction and rely on your tools (such as JIRA) to help you remember what's what. The downside is that it's harder to estimate, in advance, how a very large project might unfold or how far you've progressed in it. The upside is that by focusing on incremental construction, you can terminate early with something that produces value. In agile, you also must provide some way of saying a feature is "done" -- usually this takes the form of some suite of automated tests.