One of the principles of Agile is that you welcome change, and this has a real benefit when looking at trying to reduce the number of requirements. If you want to be flexible, and you want to save time, then every detailed requirement you don’t spend time on initially gives you some time back. It also means you won’t be reluctant to ditch the requirement if you never wrote it 😉.

Some aspects that benefit from delaying getting into the detailed requirements are:

• Your design is evolving and some of your requirements simply won’t be relevant by the time you get there
• Tendency to over think a problem
• Unforeseen consequences or new issues arise
• Confusion because the problem isn’t easy to visualise and the context isn’t clear

The last point isn’t self-explanatory. In terms of decision making, they are all made based on the discussion at hand, combined with people contributing what they feel as logical extensions, or with problem explorations during this same discussion. That discussion rarely produces instant mental visuals for people, so there is confusion on how the design layers interact. In turn, this results in wasted effort as people realise later the requirements don’t fit together.

Use your wider solution perspective to work out which requirements need to be stable early on to build a foundation. You can then help teams be confident to delay the other requirements.

In addition to that, the requirements tend to end up being overly complicated, driven by going through a problem systematically. When you get closer to the relevant build sprint, you get a chance to look at the previous sprints outputs. Two things often occur:

• Context crystallises and you now know you can safely discard a number of requirements
• You find that the user workflow is too complex for one component, and you need to split the work into two. This gives each component a simpler, more focused scope — making them both quicker and easier to build

It can be hard to delay decisions, because most people want the solution nicely mapped out early on. However, trying to make too many decisions early on can result in very long meetings, or an excessive number of tickets, or email threads discussing a nuance that doesn’t actually arise. 

High level vs detailed requirements

None of those points above reduce the power of having an initial set of baseline or high level requirements. They are key to understanding your context, solution design, and are important to help track how close you are to finishing.

Creating high level requirements is orders of magnitude less work than the detailed version. This, in turn, makes it easier to have a few early iterations of requirements. It will help with epic creation, creating robust boundaries on the requirements needed. You need sufficient requirements to shape the number of epics and their high level content – but you can then put off the detailed build requirements when you get close to bringing the epic in.

It should help teams focus on the now, rather than details that are likely to change closer to the time.