Zen of Scrum: The Sprint Setup

By

yin-yang3

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.

Sprint Length

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?

Sprint Rules

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.

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.

Sprint Emergency Procedure slide

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?

Don’t reduce the scope without first considering impediments and trying to get outside help. Removing impediments will help the team in future sprints as well. Getting outside help fosters collaboration and brings new insight to the team.

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!

3 comments:

  1. After all, Scrum is about adapting to change; poorly chosen Sprint length will lead to impatient management, overburdened Scrum Team and ultimately, bad Project output. Variable Sprint Length seems like a magic bullet that will enable work according to the Real word conditions as expected now rather than anticipated for later. Sprint planning now becomes easier. One does not have to overanalyze whether to include or exclude one more week which will bring the Product to a better Stage after every Sprint but make the process less flexible.
    www.scrumstudy.com

    ReplyDelete
  2. The pursuit of truth and beauty is a sphere of activity in which we are permitted to remain children all our lives.

    ReplyDelete
  3. I was about to say something on this topic. But now i can see that everything on this topic is very amazing and mind blowing, so i have nothing to say here. I am just going through all the topics and being appreciated. Thanks for sharing.

    ReplyDelete