Sprint scope changes are one of the most common ways Scrum goes sideways. "We have sprints, but... we change their scope." The paradox of keeping a sprint scope fixed is to welcome change!

Perhaps you've been in one of these situations: “We’ve just realised we need to quickly develop B instead of A". "We have a new, high-priority customer that needs to be served first". "We have a new VP of Galaxy Domination that has made requests to the scope of the project.” In many cases this results in constantly changing scope, which defeats the purpose of having sprints.

Note: This a 3rd post in my series on keeping the benefits of Scrum even if you can't do it 100%. Previous ones were about: 1. lack of retrospectives and 2. poor planning.

What's The Big Deal With Sprints?

Sprint is a period of intensive work that ends with an incremental delivery. It usually takes 2 weeks (10 working days). This duration can be set to anything less than 30 days. But once this length is set, it shouldn't be changed. For that time period the scope should be frozen. Why? That's described below. However having the current sprint frozen means the client is free to change anything in the coming sprints. The ones that haven't started yet.

Think of sprint scope as a destination of a trip. Once sprint is started, the team is on their way to the goal.

Benefits Behind Having a (Temporarily) Fixed Scope

  1. Commitment. The team commits to deliver certain chunk of work. It's a serious commitment. Having this commitment held up from the other side builds trust. It's kind of an unwritten contract.
  2. Productivity. Short term productivity increases because of limited context switching. People are not being asked to dump what they're doing and switch to something else. They can plan their work in an efficient way. Long term productivity from the benefits described below: accurate estimates, reasonable pressure and clear priorities.
  3. Welcome change. In the near future. Thanks to the current sprint being blocked client is free to change as much as they want in the upcoming sprints (backlog / plan). At the same time the team can focus on delivering what was agreed.
  4. Limit the pressure. Having a scope that’s fixed for 2 weeks takes excessive pressure off of the team. Once sprint is started everyone is in agreement on what’s to be delivered. Healthy pressure is there but nobody expects the impossible.
  5. Prioritisation. Clients' awareness that they need to wait till the end of the current sprint to make changes forces them to think carefully about their priorities.
  6. Better estimates. Having sprint scope frozen for each sprint enables the team to build a feel for how much can be delivered within 2 weeks. This in turn results in consistent delivery and realistic estimates.
  7. Morale boost. The team has promised and delivered. That's largely gratifying, builds team spirit and boosts energy levels.

Risks Of Changing The Sprint Scope

Changing sprint scope during its duration is like changing the destination of a trip in progress. Imagine the consequences:

  • Chaos in the work, deliverables and the information flow. Sprint planning, review and demo are explicit moments when information is being handed over.
  • Waste due to work being started then abandoned and unfinished.
  • Inefficiency due to context switching, lack of clear requirements.
  • Stress coming from conflicting demands, constant changes, lack of clarity, changing priorities.
  • Productivity drop in the short and long term due to all of the above.

Remedies

If you can’t hold a fixed scope of a sprint you can try to shorten it. Perhaps it’s possible to keep it unchanged for one week if two don’t work. Rule of thumb: how long can the client or product owner live without changing their mind? If that doesn't work you can try to keep the work specified for at least a couple of days ahead. If your sprints keep being broken by new requests perhaps it makes sense to stop trying to do Scrum altogether and switch to Kanban mode? You may also educate the stakeholders - the customer, the managers, the importance of holding to the sprint rhythm.

Summary

As you can see having a fixed sprint scope has it's deep purpose. It's rooted in the nature of software development and human psychology as well. Sprints are here to welcome change and enable adaptability to changing business conditions.

Be sure to subscribe (RSS) or check back in a week for the next one.