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 explorations based on this same discussion. That discussion doesn’t result in an instant set of visuals, so those comments often get “built” on something that won’t actually exist.

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:

• The context crystalises and you now know you can safely discard a number of requirements that are never going to come up
• You find that the user workflow is too complex for one component, and you need to split the work into two. This allows you to have simpler context for both outputs – reducing the complexities

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 excessive number of tickets, or email threads discussing a nuance that doesn’t actually arise. 

High level vs detailed requirements

The above aspects are all focused on speeding up delivery because you don’t get into the detail too early. However, none of those reduce the power of having a initial set of baseline or high level requirements. They are key to understanding your context, solution design, and is important to help track how close you are to finishing.

Creating high level requirements is significantly less effort, and if you can have a few iterations of requirements then epic creation, if will really help you create 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.