A Common Scenario

During a Sprint Review, the team demonstrates the working software, or Product Increment, that they successfully delivered for the Sprint.  The stakeholders provide all their feedback for consideration during future Sprints.   In this scenario, the team is feeling pretty good, the feedback was mostly positive with a thumb’s up from more than one stakeholder when suddenly the Product Owner (or manager) raises a hand and says something like:

Unfortunately, the team did not deliver all the Story Points they committed to in Sprint Planning so this is a failed Sprint.   Why wasn’t the team able to deliver on their commitment?

You can actually feel the excitement and energy of the team leave the room.   They look around at each other, hang their heads, and the blame game starts.   Ever happened to you?

Let’s look a little closer

Was there a failure?   And if yes, where is it, or is it possible there is even more than one failure.

Failed Sprint?   Hmm, what exactly would that look like?  The team did deliver working software and received feedback which will be incorporated into upcoming work.   So the team learned something using a discovery event (Sprint Review).   Was that a failure?   Doesn’t sound like it.

Was the failure made in Sprint Planning by the team selecting too much work?   

And what about the word “commitment” in this scenario?   Is the team really committing to deliver a fixed amount of work when we absolutely know there are unknowns to be uncovered once the work commences?

For this example, let’s assume the team has an average velocity of 50 Story Points and the team planned 49 points for this sprint and delivered 44 Story Points.

First let’s examine Sprint Planning and see if we can find a failure there.   Typically teams that are using Story Points for estimation will also use something called “average velocity”.  This is to help them estimate how much work they can complete in an upcoming Sprint.   The idea is that you count the number of Story Points completed over, for example, the last 5 Sprints to arrive at an “average velocity” (number of Story Points completed / number of Sprints).   This average is then used as a target value for the upcoming Sprint (perhaps adjusted a bit based on anticipated capacity such as adjusting down if a team member or two will be on vacation for part of the Sprint).    With an average velocity of 50 and 49 Story Points brought into the Sprint everything seems fine here, no failures.

So now we’re down the word “commitment”, is that appropriate in this situation?   When in doubt, I always coach people to look to the Scrum Guide where we find these descriptions regarding Sprint Planning:

The Development Team works to forecast the functionality that will be developed during the Sprint. 

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal


That’s curious, several mentions of a “forecast” but no mention of a “commitment”.   Could the expectation that the team is making a commitment be a factor in describing the sprint as a “failure”?   Certainly looks like it’s a contender!   

The definitions

  • Commitment: an agreement or pledge to do something in the future
  • Forecast: to indicate as likely to occur

There’s a huge difference in expectation if we change the wording from agreement/pledge to “likely”.  So I think we’re on to something here.

However, there’s something else going on as well.  And it also has to do with Sprint Planning.  Figure it out yet?   

It’s in the usage of an average to predict the future (whether or not we are using a pledge or something that is only “likely”).

If the team uses an average velocity as their target it means that, quite simply, about half the time they will not hit that value – by definition!   That’s how averages work! See the image below for an example where the team completes both more and less than the average which is very typical of teams.

A Failure of Understanding

So while I would also state that it’s a failure to use the word “commitment”, and its associated connotations, when “forecast” should be used, I feel the greatest failure is a lack of understanding basic math principles.  Failed Sprint?  No.   In reality, it is a failure of understanding. (see note below)

This failure of understanding is too frequently used as a stick against teams to punish or chastise them. Which is really unfair since the misunderstanding is not theirs!   These abuses can certainly demoralize the team and is likely to lead to a worse situation where the team will game the system by purposefully overstating the Story Point estimates of new work and/or sandbag the amount of work they bring into a Sprint.   This causes them to consistently deliver *less* so they can “hit their numbers” and not face the wrath of managers who do not understand math.   

This misuse of Story Points is what I term the “Weaponization of Story Points” with a subtitle of “method #492 to demoralize a team”.

There is however, another potential coachable moment in our scenario.   If the team is carrying over one story then I would do nothing.   If the team is carrying over more than one story then let’s talk – but that’s another article for another day.

(Visited 15 times, 1 visits today)

Leave A Comment

Your email address will not be published. Required fields are marked *