Stop Making Sprint Commitments!

I’ve become convinced that for most Agile projects, making sprint commitments is the wrong thing to do. I was happily surprised to find out that I’m in good company here—the 2011 Scrum Guide actually removed the word “commitment” in favor of the word “forecast”.

I have three reasons why I’d suggest you stop making sprint commitments and start making sprint forecasts instead.

1. Remember Parkinson’s Law

Parkinson’s Law tells us that work expands to fill the time available, and sprint commitments set us up to fall victim to this law. Most teams think of sprint commitments as at least somewhat important to hit, so they make conservative commitments. Once the conservative view is enshrined as the “commitment” for the sprint, it becomes less likely that teams will exceed that conservative goal.

The work we do is complex, and if we can take an extra day to think about architecture choices or edge cases, we often do. I suggest that you instead make conservative and aggressive forecasts—let the team know what can definitely get done, what can likely get done, and what your stretch goals are.  It’s useful to give the team a floor to communicate to the wider organization, but provide incentive to exceed the conservative plan.

2. Sprint Commitments Are Forecasts, Anyway

Does your team really commit to complete stories in a sprint? Are they willing to work late every day and through the weekend if a story isn’t going to be completed? Are you willing to lower your code quality or testing standards to get a story done within a sprint? Do you have the leverage to require other teams to prioritize your dependencies and work around the clock to get your stories unblocked?

I’d submit that what most teams really commit to is best effort—they’re going to do the best they can (within reasonable bounds) to complete stories. Knowing that stories become blocked, that priorities sometimes change, and that we sometime discover much greater complexity than initially expected, we really are forecasting here. We don’t win a whole lot by having language that implies shame and low moral character if the sprint goes differently than planned.

3. Commitments Carry Overhead

Given the weight that we attach to the word commitment, and the associations folks outside the team may make, we invest a lot in commitments. We spend all kinds of time in sprint planning figuring out what our velocity should be, doing fists of five, and going around asking if folks are comfortable. We wring our hands when a PO wants to bring a new story that wasn’t part of the commitment into a sprint. We often spend time afterwards analyzing how our commitments may have gone off the rails. There is a lot of overhead here, and it is likely costing your team productivity.

Summing Up

If you have real business needs that depend on certain features being done by the end of a sprint, then by all means, make commitments and ensure that the team does everything in its power to make them happen. But for most of us, most of the time, we’re really doing our best to build out as much of the backlog as we can on each sprint. You’ll save time and improve morale by challenging your team to see how far they can get down the backlog in each sprint rather than establishing a set of sprint commitments.

Conversation
  • David says:

    I couldn’t disagree more. For years I have been able to consistently predict within a 24 hour period when requested work can be delivered weeks beforehand.

    I’m not alone on this. Any Agile/Scrum/Kanban expert can walk you through it. The process of reaching this goal is fairly straightforward provided you know the steps and can follow through — in which case you can be extremely accurate on delivery dates.

    That is the power of accurate planning, task reductions/breakdowns, leveraging and deploying Continuous Integration/Delivery (for consistent deployment timelines), being consistent with your Agile process, etc.

    Perhaps you might consider bringing in an Agile coach?

    • Jesse Hill Jesse Hill says:

      Agile’s predictive power comes from measuring sprint velocity and projecting a completion date based on the remaining work in your backlog. Making sprint forecasts rather than sprint commitments doesn’t weaken that predictive power in any meaningful way.

  • Comments are closed.