Follow the Requirements or Else

A sprint is a boundary that creates the freedom for effective self-organization, and self-organization brings collaboration and experimentation front and center. Each sprint, your team should ask the following questions:

• Are we building the right things?
• Are we building the thing right?
• What assumptions have we made about the product?
• What might change about our product?

All these questions will come up throughout the sprint, and teams will learn the answers to these questions by doing the work, inspecting what they’ve done, and adapting along the way. The business will do that right along with the team, too.

But we often see sprints misunderstood as time boxes that follow exhaustive, detailed requirements that were defined far in advance of the current sprint, and added to product backlog items by the product owner. The development team is expected to explicitly follow the detailed requirements without questioning the product owner. We’ve seen product backlog items that contain hundreds of lines of text and have detailed documents (including finite implementation strategies) attached that give exact outcomes. Under these circumstances, interfacing with the business or a customer is frowned upon. As a result, the wrong thing usually gets built—and it’s built the wrong way.

We don’t mean that you shouldn’t gather good requirements and have an idea of what you’re going to be building in advance of a sprint. But the more time that elapses between writing requirements and validating them against customer feedback, the higher risk of building the wrong thing. Instead of getting too far ahead with writing requirements, focus efforts on creating smaller sets of requirements and shortening the time it takes to get a deployment to production.

A sprint gives Scrum teams a time box with a maximum duration of one month, where we can try things without massive risk and without any permanent damage to our business or our ability to deliver. The business gets a lot of freedom to experiment as well. For example, the business may not know the best course of action among two or three competing ideas. So, they could ask for a sprint where we do investigatory product backlog items on each one, release something to the market at the end of that sprint, gather some feedback, and pick a direction for moving forward. So instead of picking an option blindly, they get the option of making a limited investment on one sprint and see which approach could potentially be the best, based on real market feedback and not guesses and assumptions. That’s very powerful. The worst case scenario is that the team learned a little bit about the problem space, they thought up a new experiment for next sprint, and we used up a maximum of one month of work.

The sprint limits the impact of failure to the time box of the sprint and provides lots of benefits and opportunities. But if we’re trying to follow old, detailed requirements, we lose the opportunities that the sprint could create.