In Scrum, you develop product increments in short iterations called sprints. The sprint is a very central concept in Scrum: everything revolves around it.
In this post I talk about sprint length, preconditions for a successful sprint, and what to do when a sprint falters.
Each sprint starts with a planning event which I covered in an earlier post. The sprint ends with two other meetings: the sprint review and the sprint retrospective. Those will be covered later. These three events are part of the sprint, and make out the sprint boundaries.
The length of sprints is frequently debated.
Both long and short sprints have their merits, but a sprint should never extend more than four weeks. Longer than that, and it becomes difficult to oversee scope and prevent outsiders from changing priorities.
Three things affect the appropriate sprint length:
- The complexity and type of product being built
- How experienced the organization is with Scrum
- How frequently priorities and scope change
Some people argue that shorter sprints cause too much overhead. However, shorter sprints means shorter meetings. For example, the rule of thumb for the sprint planning is sprint length in weeks x 2 hours. That is, a two week sprint equals a four hour meeting.
Whichever way you decide to go eventually, I strongly recommend shorter sprints for new Scrum teams. It gives you a chance to “go through the motions” more frequently.
Can you think of other benefits with shorter or longer sprints?
Once the team starts implementation no changes that affect the sprint goal should be made.
If the goal change it affects efficiency negatively. Do it often and it affects morale as well, and eventually developers will stop caring about commitments.
The same is true if the team composition changes. If someone is abruptly removed from the team, or works in two teams simultaneously, it hurts productivity.
Another very important rule is that the quality goals are not allowed to change in the middle of a sprint. A team that decides to skip quality to meet the target causes two major problems:
- They risk introducing defects and other technical debt into the code base
- They “lie” about their velocity and hence depicts the wrong image of progress to the product owner and other stakeholders
You often get objections about these rules from outsiders: stakeholders, project managers and sometimes product owners.
“The team should welcome change, that’s the whole point with agile, isn’t it?”
“We need John Doe to do this now, ok? It’s more important than this other project right now.”
I think these are signs of other organizational problems, rather than reflecting a true need. If management doesn’t have the two-four weeks foresight of a typical sprint, or lack the courage to hold back decisions during that time, it is a management issue – that should be addressed promptly.
That said, it’s perfectly fine to renegotiate scope during the sprint. To clarify and discuss stories as more knowledge is gained. It can even be ok to add new stories to a sprint if it makes sense, and other work of roughly the same size is removed.
It might also be ok, as a last resort, to cancel the sprint altogether. Before doing that, think it through carefully and consider the sprint emergency procedure, first worded by Jeff Sutherland.
The Emergency Procedure
Sometimes a sprint stops making sense: perhaps because nothing gets done, or because the sprint goal becomes obsolete or irrelevant. Other times the team simply realizes that they won’t be able to finish all the stories committed to.
The first thing to do if this happens is to look for impediments and try to remove them: to optimize the way the team works.
If that doesn’t work, perhaps it is possible to get help from outside the team. For example, if the team can’t solve a particular problem, perhaps an architect or a domain expert can help them get passed the hurdle.
The most common approach, however, is to reduce scope. This should be done in the light of the sprint goal: is it possible to do a delivery that is meaningful despite cutting some stories?
In the end, if nothing can be done to salvage the sprint, it might be better to cancel it and start over. If you do so, make sure that the new sprint is better planned with a more realistic goal.
That’s all I got about the sprint setup. Next time I’ll talk about the inner workings of the sprint: the daily scrum and the sprint backlog. Ciao!