Protecting your sprint

A sprint is the most common piece of the Agile process that companies adopt. Even if the rest of their Agile understanding is imperfect, they still have sprints. At worst, that’s arbitrary two-week time blocks towards a waterfall delivery. At best it’s an integral part of a Scrum process of iterative delivery.

And sprints are always under pressure from external factors. Even if you get buy in to allow the sprint team to estimate their work, something new comes up. There’s an emergency. There’s a last minute piece of work. All things which undermine not only that sprint, but the point of sprints at all.

The biggest benefit of sprints is that they create predictability and transparency. The team estimates how much work they can do, delivers an iteration, and has a retrospective. Over time, their estimation gets better, and the sprints become more predictable. With my teams, I can say with a very high degree of confidence that what we put in a sprint will finished in that sprint.

That only works if I can protect my sprint. And there is very often an “emergency” that puts pressure on the sprint. Something that comes up mid sprint, at short notice, and needs doing fast.

The solution is not to work more hours.

Not only does this have the problem of “crunch time”, it undermines the long-term benefit of sprints.

One of the biggest benefits of having sprints is having predictability. That means that the same number of people, in the same period of time, can do a certain amount of work. A team reaches that predictability over time, by learning and refining their processes. If extra work adds to a sprint, and adds to the work hours, I can’t reach predictability. A short-term emergency has long-term negative impacts on predictable delivery.

Doing that extra work also rewards bad behavior, or false expectations. Once you say “yes” to undermining your sprint once, it’ll get undermined again. You’ll lose all the benefits of predictability. A sprint becomes a variable, not consistent, period of work.

The concept of a “silver bullet”

The best way to defend the sprint is to define a standard for “silver bullets”. These are those emergencies that need work. But the solution is not to add more work, it’s to replace existing work.

Emergency work should be defined like any other work. And once it’s defined, it can be sized like any other work.

If the work is sized, then the next step is to go back to the stakeholder and ask what they want replaced. Say the emergency piece of work is five story points. If there are more than five story points worth of work in the sprint that hasn’t been started yet, swap it out.

This makes the decision about the emergency work a business decision. The stakeholder needs to choose which pieces of work are more important. The sprint stays predictable, the scope doesn’t change much. We can be confident the “silver bullet” can ship.

If there’s more than one stakeholder defining work, then they need to agree on the swap.

This protects the scope of the sprint. But it has an extra benefit. If you tell someone their “emergency issue” needs to replace something…very often it’s suddenly less of an emergency!

Sprints are not arbitrary blocks of time. They exist for a reason. Even if they’re the only part of Agile process you’ve adopted, work to protect them.

Well protected sprints bring transparency and predictability to work. By doing so, they provide a foundation for long-term efficiency and performance. Don’t let that be undermined by short-term demands.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.