Why are sprints never extended?

In Scrum, we time-box the sprints and never extend them. Why are sprints never extended?

Optimize for Value

Lets take a look at Scrum vs Traditional Project Management: In traditional project management, we optimize and control for scope. We set the scope up front. We actively manage scope creep, and we extend the timeline if the scope is not met. In scrum, we optimize and control for value. We order the backlog by value. We ensure the most valuable items are being delivered on a sprint by sprint basis, and we often compromise on scope in favor of value. We consistently monitor our feedback loops for value delivery and signs of waste.

Since we are optimizing for value, we have prioritized the backlog items so that we are always working on the highest value/highest priority items before the lowest value items. We do small batches of incremental value delivery on a per sprint basis to increase value flow, and therefore, give ourselves an opportunity to set a sustainable pace.

Since we are “fixing” the time (sprint duration) and varying the scope (what we can get done in a sprint), we get a much more accurate picture of what the team is able to deliver on an iteration by iteration basis, as well as an opportunity to dynamically manage risk. The goal of the current sprint is supposed to be relatively stable, all in the name of an empirical inspect and adapt cycle. If we were to constantly vary the lengths of the sprints, we have no “measuring stick” by which to figure out how much “stuff” our team can complete in 2 weeks, and therefore, no consistent way to forecast anything.

The Importance of Focus

I always notice something interesting in my training classes. I perform an exercise during the second half of the second day whereby the team has a project to complete in 3 sprints. The sprints are about 20 minutes each, and I give them 3 sprints. The team incrementally builds, tests and demos a product over the course of the three sprints. At the end of this exercise, I always ask the team, “What do you think would have happened if I had told you that you have an hour to complete this project?” The answers vary, but usually something along the lines of “We would have planned for 45 minutes then rushed to get something crappy finished in the last 15 minutes.” Parkinson’s law says that work always expands to fill up the time available to do it. The same thing happens in day to day life. People tend to take up all the time allotted for a particular task. Shortening the cycles allows the team to focus on high value targets for a short amount of time.

Root Cause Analysis

Let’s say we stick to our guns and do not extend the sprint, and invariably, the team does not accomplish the sprint goal. What do we do? A gut reaction may be to say, “if we had extended the sprint, we would have accomplished the goal!” A perhaps counter intuitive way of thinking about it is to understand that the team needs to comprehend its capacity to do work on a sprint by sprint basis. To extend the sprint deprives the team of their ability to do root cause analysis of why they weren’t able to complete the goal, and therefore short-circuits a critical feedback loop in the Scrum framework.

Extending the sprint removes our ability to do proper root cause analysis on why we weren’t able to accomplish the sprint goal

It simply hides the problem. Did the team bite off more than it could chew? Was there an external dependency that was not managed? Was there an impediment that prevented the team from finishing? Without failure, there can be no learning. A team that doesn’t meet its sprint goal has much to talk about during the retrospective.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Leave a Reply