How often does your sprint goal or stories change in the middle of the sprint? A late-breaking requirement or bug comes in, or a manager pops up with an urgent task, and before you know it your sprint is totally overloaded. Does that sound familiar?
Teams often think they’re being agile by responding to changing requirements during the sprint — or else they feel pressurised by managers to take on extra work that they didn’t plan for. And then at the end of the sprint, the inevitable questions get asked about why the team hasn’t delivered?
“The team committed to delivering this feature. What happened?” the manager might say — forgetting that they were the one that torpedoed the sprint in the first place!
Commitment goes both ways
The idea of a commitment at sprint planning goes both ways:
- The development team is meant to commit to delivering the stories in the sprint plan.
- The business is meant to commit to leaving the development team alone to deliver the stories!
The problem comes, however, when the business forgets or doesn’t know about their half of the bargain.
Protecting the sprint
Ideally the Product Owner should work to protect the sprint from outside interference. They need to act as the gatekeeper of all new requirements, and stop managers or other stakeholders approaching developers directly.
The Product Owner is responsible for delivering the maximum value from each sprint, and needs to maintain a good overview of what the team is working on. They can’t do this if the team is also working on stuff that:
- Isn’t tracked on the board
- Hasn’t been prioritised
- Might start off as “just a small request” and then grow to take up all the sprint capacity!
And so, all new requests — even urgent ones directly from the CEO — need to be assessed by the Product Owner first, and then they can make a call on whether the urgency warrants interrupting the sprint in mid-flight. Otherwise, the requirement will just have to wait for the next sprint.
Keeping to the sprint plan is good for the:
- Product Owner and Business, as it delivers the value as expected
- Development Team, as they don’t need to context-switch in mid-sprint
Front Door process
If you get a lot of new requests, then it may be worth setting up a Front Door process. It helps keep track of all the various requests that might come out of emails, meeting actions or random conversations.
It also helps to take an objective look at the priority of each request — and to make sure that you aren’t just working on something because the boss wants it, or because somebody shouted the loudest!