Potential Dysfunctions of Sprint Commitments

by Brad on March 11, 2010

Many Scrum teams subscribe to the following set of rules, which are the prevailing guidance in the Scrum community and literature.

  1. At the beginning of a sprint, the team commits to delivering some number of backlog items
  2. Teams should not start work on a backlog item unless it can be finished in the same sprint
  3. Sprints should never be extended

The reasoning behind these rules are that the time pressure of a short, fixed sprint helps a team focus and get more done than they otherwise would, and that extending a sprint is a slippery slope toward anarchy. While I understand this logic, in practice I’ve seen two dysfunctions result from these tenets of Scrum.

First, in many organizations the word commitment invokes fear in the team: if we don’t deliver our commitment, we’ll be punished. As a result, teams are likely to under-commit and bring less work than they otherwise would into the Sprint. “But then they can bring in more work if they finish early,” goes the argument. But rules #2 and #3 tell them to do this only if they can finish the work by a fixed date, and the same fear factor makes them very reluctant to do this. I have actually seen teams with idle time at the end of the sprint as a result.

On teams without the fear of commitment, an entirely different dysfunction can result from these rules. While speaking to an audience of about 50 people at Agile Denver recently, I asked two questions.

  1. How many of you believe sprint deadlines are a positive motivation?
  2. How many of you have cut corners with quality to meet a sprint deadline?

To my surprise, only a handful of people timid raised their hands in response to the first question. To my further surprise, almost every hand in the room shot up emphatically in response to the second question. The evidence indicates that this combination of rules is having unintended consequences.

So what should we do? A few things I would recommend.

First, replace the phrase Sprint commitment with Sprint estimate. Be sure to have the crucial conversation with your team, Product Owner and stakeholders about what it means when the team accepts a set of user stories in sprint planning, and what it means if they are unable to complete all the items they estimated; particularly that no punishment will be doled out as a result. This is a good opportunity to stress the importance of limiting WIP and focusing on the highest priority items within the sprint, so that if anything isn’t finished it will be the lowest priority item.

Secondly, be sure to have good quality metrics as compensating measures for your velocity metrics. While velocity metrics give an incentive for the team to go faster, they also can result in pressure to cut quality. Effective quality metrics, such as code complexity and code coverage of automated tests, combined with practices like pair programming or code reviews, provide a balancing incentive to keep quality high.

Third, I believe it’s ok for a team to start a new backlog item even if they don’t think it can be finished by the end of the sprint, assuming that all the higher priority items are truly done and accepted by the product owner, and the team has established practices to ensure a sustainable pace with high quality. Some people might suggest that rather than starting a new story that can’t be finished by the end of the sprint, the team should do “extra” refactoring or work on resolving impediments. In my view, the team’s Definition of Done and working agreements should already ensure there is adequate time for these activities. If you wait until you have “extra” time, it’s likely that you’ll never have time.

Kanban eliminates the sprint deadline, which is another way to possibly reduce the motivations that lead to this dysfunction. But beware that kanban should not be used as an excuse to be undisciplined; perhaps that’s a topic for a separate post.

Bob Hartman March 11, 2010 at 10:35 am

Brad, I agree with some things in your post but not with others. I understand the potential dysfunction you talk about, but I think that ties back to a team’s training and working agreements. In particular your first items #2 and #3 I cover very differently. #3 I specifically say should never be done because there are “good sprint failures” and “bad sprint failures.” At the retrospective figure out which you had and adjust accordingly. On #2 I specifically tell teams if everything else in a sprint is completed, pull an item from the backlog and not finishing it is ok. It spills into the next sprint. There is not “penalty” for doing that, in fact it is considered a good thing because the commitment was already met.

It all boils down to the initial training and the way the team and the rest of the organization interprets it. I am very clear about good vs. bad failure but that’s too big a subject for a comment! The rest of the org needs to understand this as well because that is where the pressure WOULD come from if they didn’t understand. Once the org understands appropriately it is easier for the team to relax.

Interestingly you can also look at some of the sprint metrics and see various dysfunctions in action as I mention in a series of blog posts about burndown charts http://www.agileforall.com/2009/12/29/agile-antipattern-dysfunctional-burndown-charts-roundup-post/ These may actually be applicable here as well because the burndown wall or cliff may also be caused by cutting quality corners. I didn’t think about that at the time but I’m making it a note to add at a later time.

Having said all that, you and I have both been in situations where the initial training made NONE of this very clear and the result is exactly what you say. I just want people to know there are alternatives depending mostly on how things are presented and interpreted.

Great blog post though. Very thought provoking.

Brad March 13, 2010 at 5:07 am

Thanks for your comments, Bob. I do agree with rule #3 that sprints should not be extended. I like the rhythm that regular sprints provide, particularly for planning and retrospectives. You’re correct that proper training and adjusting company culture to understand that there is no “penalty” for not delivering a story by the end of a sprint. I also believe a focus on value & priorities, combined with the principles of flow and building quality in teach us to reach a sustainable pace and to keep the business value flowing – regardless of a somewhat arbitrary sprint boundary. I believe kanban is a way to reinforce those principles.

Previous post:

Next post: