What’s in a Sprint Goal?

Based on the results from last month’s poll, it seems many people are finding themselves in a situation where some of their work is not fitting within their sprint. Indeed, nobody reported that they were consistently delivering all work, and nearly a third were reporting that half or more of the committed work was bleeding over into the proximate sprint. This ultimately begs the question: should a team always be meeting its sprint commitment? Is missing a goal a good thing or a bad thing?

Why Commit?

While this sounds like a simple question, it’s probably worth taking a closer look at precisely what we mean by a sprint or iteration commitment and we should be using it. We should be courageous enough to take any component of our project, including Agile practices, and ask ourselves “why are we doing this”. In fact, many within the Agile field are asking just that about the sprint plan and commitment and pointing to things, like Kanban, that simply do away with the idea of making a plan for a discrete point of time. I can certainly see that the concept of a sprint plan and commitment offer us several concrete things of value

  • It offers us an opportunity to try and pace ourselves – whether we meet a commitment or not will give us a good idea if we are indeed progressing at the rate we anticipated. While most Agile practices discourage tracking actual time on individual stories or tasks, this gives us the same thing, the ability to reflect on an estimate, and see if we met it or not. Quite simply, if we planned to deliver 4 use cases of functionality in 2 weeks, and we only delivered 2, that’s an important data point into understanding if our expectations and planning is realistic. I frequently find that most members of an Agile team actually aren’t terribly good at planning at first. Years of making estimates in isolation and never being able to validate them in a timely manner has caused any estimation skills to atrophy.  This frequent feedback is very useful to them to improve their estimates and get better at making consistent, reliable plans.
  • It creates a sense of tension – when a team commits to do some amount of work based on their own analysis and planning, they will have a bigger stake in it than most any mandated goal from on high. Thus, we tap into a powerful source of intrinsic motivation. This is particularly good when we see a team meeting or exceeding goals.
  • It builds trust & cooperation – Robert Axelrod in his exploration of the Evolution of Cooperation sought to identify patterns that would lead to more cooperation. One of the most powerful dynamics in encouraging cooperation was building trust over iterative rounds. The regular cadence of making and meeting commitments can be a powerful pattern for improving trust amongst project stakeholders and engendering cooperation.
  • It focuses on goals – a commitment is made by a team as a whole and thus shared by everyone. This can be a powerful catalyst for getting people to step beyond their boundaries and do what’s good for the team as opposed to optimizing on their own specialty. If the requirements are completed for all the work of the sprint, the analyst may realize that they need to help testers in order to meet their commitment, this will be more important to them than writing additional specifications of no immediate value in order to simply keep busy.

Of course, these cut the other way as well. Missed commitments may lower trust. Unrealistic goals imposed from outside may cause teams to simply not care, or teams may even offer to “give it the old college try” in an effort to be accommodating, without realizing that they are setting themselves up for disappointing their customers. Teams may fear missing a commitment so much that they consistently under commit and thus sacrifice capacity in the name of always meeting a commitment.

What are We Committing For?

At the risk of sounding like a consultant and saying “it depends”, the way we approach our strategy for commitment varies based on your circumstances. Let me offer some examples to illustrate some of the challenges we may face and how commitments could be used.

  • The undisciplined team: Agile requires a tremendous amount of discipline and many teams may struggle at first to operate in a consistently disciplined fashion, paying close attention to detail and seeing tasks through to completion. We may see this manifest itself in the team that is “basically done” with everything, but we keep seeing hang over tasks, or clean up work bleeding over into the next sprint. Or perhaps they are taking credit but there are bugs or other things left unattended to. In this case, a clear commitment to complete work, and follow through by the ScrumMaster or other voice of conscious within the team is a critical factor in helping the team hold themselves to a higher standard.
  • The fearful team: sometimes teams are afraid that a single missed commitment will cause them to incur the wrath of numerous managers trying to understand “what went wrong”. Of course, this is a tell for a bigger problem, namely managers or other stakeholders obsessing over single data points when the trend is most important. The negative impact this can have upon a team is that they consistently under commit and are unable to improve for fear of not being able to meet expectations. In this type of case, I have seen teams set two goals. A conservative goal is communicated to stakeholders, managers and the rest of an organization. That is the number they will be held to. The team then sets a stretch goal used for their own internal purposes of trying to push themselves and see how much they can do. Mike Cohn has an interesting take on this where he points out that teams should distinguish between estimating and committing.
  • The ambitous team: sometimes teams see the commitment as an opportunity to impress everyone. In these situations, commitment may sometimes be better described as “aspiration”. Of course, this causes other problems as people may not take it as seriously. The risk here is that in an attempt to get an incredible amount of work done, they over extend and end up delivering less. Good coaches know to help the team appreciate a sustainable pace.

Guidelines for Committing to a Sprint

The work that a team commits to should be their best approximation of what they can realistically deliver within a given time frame. It should include all of the agreed upon work to complete a given increment of functionality. It should also be a pace which the team can maintain indefinitely, which means no technical short cuts, no excessive overtime, and no neglecting necessary preparation for the successive sprint. The principle value of the commitment is to the team, so that they can measure against their best approximation of their rate of work. It may also be used by the product owner or other stakeholders to assess the trend of performance. With all this in mind, here are some general guidelines to keep in mind.

  • It’s the trend that matters, not a single data point: people may at first obsess over a single sprint where a team misses its commitment or wildly over delivers. Be sure to remember that the trend tells you what’s going on, not one data point. Make sure people don’t get too excited or disappointed over one sprint. The point of frequent iterations is to lower the stakes and allow for some failure. However, if the trend points to a bad pattern like stagnant performance, declining velocity or wild gyrations in performance, then there is probably something you need to investigate to understand what’s going on.
  • Distinguish between commitments that can be missed verse ones that can’t: Agile projects are designed to allow for failure early in order to improve long term performance. Thus, missing one sprint commitment is not a crisis, but missing a release deadline for a project that had a hard date very well may be. Make sure people can differentiate between commitments made for purposes of baselining and pushing the team from commitments that are critical to project success. While circumstances vary, I can tell you that most commitments would fall into the first category. Sometimes this may also involve creating dual commitments “we commit to the business they will have these features, and we are committing to ourselves to do our best in delivering these additional ones as well this sprint”.
  • Make sure you have an opportunity to adjust up or down: sometimes it will become clear early on in a sprint that something is not going to happen or that things are going spectacularly well. In these cases, its best to acknowledge reality and make sure you have an option to bring in more work, or adjust your commitment based on the reality of the circumstances. Generally speaking, I would say that a mid-sprint adjustment should consist of removing committed stories from a sprint or adding additional ones to those already committed. You don’t want to go into a complete replanning exercises where you are both swapping some out and bringing others in. Also, if you do adjust the commitment, it should be a discrete thing that happens, as opposed to being a floating decision that is continually adjusted.
  • Talk to the team about the implications of team commitment: remember, we’re doing this to learn and to build predictability. We want to make sure that people understand our goals and if we are finding ourselves managing commitments to other goals, it is better to surface those issues and confront them.

So ultimately we come to the conclusion that it’s not necessarily bad if in a particular sprint you are missing your commitment and seeing work flow over to the next sprint. However, if this is a consistent pattern then we need to figure out what’s going on. Even in these cases, I wouldn’t necessarily classify it as a bad thing, but rather a valuable tell to understand more about your project.

Thanks to everyone who participated in the survey and I look forward to hearing from more people in our community about their experiences using Agile techniques and practices.