Let’s Change the Sprint Length
A sprint’s duration is limited to one calendar month or less. Keeping the duration of a sprint consistent during a development effort establishes a cadence. A consistent time box also helps the team provide consistent forecasts to the product owner and stakeholders. And it offers the Scrum team a way to easily interpret a consistent set of data around how the team works and the complexities they’re facing.
Once a sprint has started, its length can’t change. We don’t make them shorter because we completed all of our work done sooner, and we don’t make them longer because we’re not quite done. Once we decide a sprint length or set a cadence, it’s a rhythm, it’s a heartbeat, it’s how we space out our feedback loops. Consistency is key.
Nope. Not even if you’ve hit the end of your two-week sprint and aren’t quite done with the product increment. That’s a difficult spot, but you have to go to the sprint review and discuss what happened during the sprint and why you don’t have a done increment of product to inspect. We do not exceed the time box—no matter what.
There’s no such thing as a failed sprint, just an undesired outcome that we can learn from with stakeholders.
The issue with extending a sprint is that continually extending it just one more day increases the risk of moving in the wrong direction, because you’re not getting feedback as often as needed. You also avoid inspecting why the team struggled to deliver value at the end of the sprint. These impediments to delivery won’t go away on their own and, if left unresolved, will compound in cost, delays, and risk.
And what if the extra day you request isn’t enough? How many times have you seen “just one more day” turn into “just one more month”?
The sprint is a creative constraint. Every issue within our organization that prevents, delays, or inhibits delivery will come forward quickly because of the sprint time box. The urgency to deliver, coupled with the necessity to improve, drives Scrum teams to become creative at solving problems.
Why does this matter? A sprint is a fixed period of time that you’ve decided to use to capitalize on an opportunity in the marketplace. You’re delivering the right feature at the right time for the right customer. You’re opening up the opportunity for the product owner to get validation for the assumptions they’ve made about value. The increments created each sprint are opportunities for the product owner (and the organization as a whole) to realize a return on their investment in the product.
When the team is deciding on a sprint length, your first consideration should be how long it’s safe for the product owner to go without feedback from their stakeholders and customers. In highly complex environments, an overly long feedback loop could be risky.
Your team needs to discuss the product and technical implications of various sprint length options, and determine how long they’re comfortable going without feedback, and how long the stakeholders are comfortable going without inspecting the latest product increment. Of course, the sprint duration also has to be technically feasible so that “done” work can be completed in its entirety.
The number of weeks that your team decides on isn’t nearly as important as the reasoning behind the choice and the collaborative discussions that led to that decision. Before your team decides on “just right”, make sure you’ve balanced risk, delivering value frequently to your customers, and technical feasibility.
You’re going to find problems within your processes. Development practices will need refinement. Meanwhile, you’re still on the hook to deliver features by the end of the sprint. This positive sense of urgency leads to improvements that allow you to meet the definition of done and deliver features by the end of the sprint.
If you extend a sprint, you rob the team of the opportunity to improve their process, practices, and collaboration. Stick to the time box and use it to drive continuous improvement and delivery.
Ask yourself and the team honestly, “Are we extending the sprint to meet an artificial goal or to meet a metric?” Address the underlying issues of why you’re not accomplishing your sprint goals. Removing the impediments to delivery will pay off far better than extending a sprint to game a metric, or make it look like you delivered a done increment within the sprint.