July 23, 2014

Agile Coaching Blog

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.


About Brian Bozzuto

Brian Bozzuto is a Senior Consultant and Agile Coach at BigVisible Solutions. With an extensive background in large financial service companies, he has worked as a developer, analyst, project manager, and coach. His current focus is working directly with teams as they adopt Agile and Scrum practices. He has a broad range of experience using various frameworks including Scrum, Six Sigma, and CMM as well as being a Certified Scrum Practitioner (CSP) and Project Management Professional (PMP). Brian has worked on numerous large integration projects involving enterprise portals and other web technologies. He has worked, in various roles, at Fidelity Investments, Investor's Bank & Trust, Bank of America, and Fleet Bank.


  1. Thanks Brian for your insights. I am glad to see this topic as it relates to what I am focused on right now. I find a team that plans well, delivers well. The sprint planning meeting’s function is fundamentally about “knowledge sharing” aka collaboration. So while I agree with your insights about team commitment as it reinforces the “team” aspects of collaboration, you make a couple statement that make me *un*comfortable.

    It seems counterproductive to me to say things like “…simply due away with the idea of making a plan for a discrete point of time” and “…most Agile practices discourage tracking actual time on individual stories or tasks”. While I admit I may not be up on the latest trends of the modern Agile thinkers, it seems to me to miss the point altogether if planning is a critical part of your company’s ability for create innovative, market driven products that are complex and require a large development effort (2 or more teams working many months).

    I would have preferred your post did not mix questioning the efficacy of “team commitment” with the efficacy of “team planning”! Team planning is a necessity and should not be confused with the importance of helping a team become more responsive to change by improving collaboration, which is what Agile is *really* all about. As the old adage goes, “You cannot improve what you don’t track.”

  2. I’d love to write more about this for now, because I think you bring up a very good point. As much as we would like to break apart planning from a commitment, it is for all intents and purposes, impossible. Once a plan is communicated, people are held to it. My favorite simple example of the manager asking in passing, “how much do time do you think it would take to build X” frequently becomes a commitment.

    Indeed, because these are so intertwined, you can’t do a planning exercise without taking into account commitment. This is the crux of the challenge that faces most teams. I’ll have to write more about this, but in the short term I would say, plan on the shortest term possible, and use forecasting based on empirical results for longer term questions about “will it be done by…” or “how much time to complete…”

  3. My team has an issue with the concept of a Sprint Goal. The Scrum Guide is kind of nebulous with its guidance on exactly what this means. It gives an example that a Sprint Goal could be a milestone in a larger Production Release. But what else can it mean. It seems to be distinct from that of a commitment but similar. Do you have an example of a specific Sprint Goal other than a committed Sprint Backlog?

  4. Hi Joe, thanks for this question, it really got me thinking. In fact, it got me writing and my latest blog post talks directly to your question of how else to use sprint goals beyond just aggregating what fit into the sprint. I hope you enjoy it!



  1. [...] recent question about sprint goals got me thinking about the lean startup concept known as “validated learning” and how [...]