Friday, July 15, 2011

Story points: Who gets the Credit?

How getting caught up in the accounting can make us miss the point

My cell phone rang and it was my Agile coaching compadre on the other end of the line, exasperated. Uh oh, time for an Agile intervention.

He had a team that took on 10 points of user stories in a sprint, but only finished 3 points. Now they were planning for the second sprint, and they were starting in a hole with work to complete on the 7 unfinished story points, plus another 10 points of work they were taking. They were trying to keep their average velocity at 10 points per sprint. I asked him what they were going to do about the credit for the 7 story points that spanned the sprints?

"They're going to get credit for them in sprint 2, since that's when they completed the work." Well, he couldn't give them credit for the points in sprint 1, since they weren't completed. That was the right answer there. I asked how much of the work was left over for the stories. "About 10% left, all testing" was his answer. Hmmm…OK. Something was bothering me about that. The majority of the work on these points was done in sprint 1, but they weren't completed in sprint 1, so the credit couldn't go there. But to get full credit for 7 story points in sprint 2, when only 10% of the work had to be completed, wasn't striking me as kosher either. What about partial credit in each sprint…90% credit (6.3 points) in sprint 1, and 10% credit (0.7 points) in sprint 2? Well that seemed like ridiculous mathematical gymnastics, and besides, it would send the wrong message to the team: that it's OK to NOT finish work in a sprint. 

This team was indeed in a box. They had already completed most of the work (and wound new code deep into the existing code base) for those 7 story points. They started all of them in motion at the same time in sprint 1, too, (the Scrum Master should have advised against this) which had limited their flexibility to move some back to the product backlog. So now, it had to be completed.

We continued debating the issue and trying to decide where the points should go. They had to go somewhere, didn't they? And then it hit me.

Those 7 points go nowhere. 

No credit. But they DO have to complete the work. "Well, that's an answer that everyone will hate" was his response. They probably will, but its tough love for the Agile team. And here is why I think it's the right thing to do.

What are we measuring with story points and level of effort? First off, it's NOT "time tracking." It's not meant to be a measure of how the team spent their time. What we are measuring is business value delivered. Stories are worth nothing to the business if they are not completed. We want teams to start a sprint entering into a commitment with the Product Owner that they are taking on work, and will finish it in the sprint. Of course, there are times during a sprint when work takes longer than expected and teams can't finish everything they committed to, but that's when the Scrum Master facilitates communication with the Product Owner to move the lowest priority not started items back to the product backlog, ensuring that whatever stays in the sprint can get to "done." I covered this in a previous blog post.

You honor the commitment, but story point credit and velocity has predictive value in measuring how much work the team starts and completes. Since this was not the case with this work, no credit is given. Would everyone (team, Scrum Master, Product Owner) hate this solution? Sure, but it makes for a great retrospective topic, and a lesson learned for the future.

So how do you, as a Scrum Master or Agile team lead, avoid having this happen in your teams? Here are a couple of tips:

  • Use solid velocity measurements in sound planning: Scrum Masters should use velocity as a rolling average, not a single number, and in concert with good capacity planning (vacations, holidays, other commitments, other drag factors) help keep the team from "biting off more than they can chew" in their commitment in sprint planning. This is precisely why I feel you don't get credit for partially completed stories at all…it provides no predictive value.
  • Minimize WIP: The fewer number of stories a team has in flight at any one time, the greater their flexibility to adjust and move not started stories around without having wasted effort and having to unwind code from the codebase.
  • Inspect and adapt daily: No matter what, keep the daily standup sacrosanct and effective. It remains the team and Scrum Master's primary channel for surfacing and mitigating potential problems before they become real issues.
  • Practice "tough love" servant leadership: Remember, a Scrum Master is not a manager of the team, they are the coach and protector of the process framework. The coach does not take the field; he/she observes, advises, supports, and puts the team in a position to succeed. And by practicing tough love like in the example here, a Scrum Master helps the team, and him/her self, learn a valuable lesson from a mistake they are unlikely to repeat in the future.
As always, I welcome your comments.



  1. "What we are measuring is business value delivered." ... No. Its Effort. Not the same.

    1. You can put in a hell of effort without ever finishing. That is why you are wrong. Would you grant credit to a marathon runner if he/she quits in the last mile? Surely not, even if the effort was in. That is why you are wrong. The story point must measure the business value delivered.

    2. Correct, the whole reason for using story points is to get away from estimating in terms of effort (hours, days, etc). The customer cares about business value, not your effort. Otherwise you could just bill them for your time without delivering any usable software.

    3. Hours, days is a measure of time and not effort. This blog entry refers to story points and they describe effort and not business value. There could be one (relatively) simple user story of few story points which gives enormous value to a customer (like e.g. SMS service in GSM network vs. data services with all their adaptation functions - don't confuse with GPRS, LTE and the like).

  2. To my mind story points is indeed a measure of effort (NOT time) and not business value. The team estimates story points against how easy or difficult they think the story will be to implement, not how much worth it has. Business value is a something different, and ROI can be calculated by dividing the business value by the effort.

  3. I agree the story points is a measure of effort not business value. A story can have high value, and can take a low level of effort to complete. Likewise, a story may have a low to mid level business value, but with high effort.

    If story points represented business value, then if teams only worked on stories with high points because of their desire to deliver higher value stories, but those stories took little effort to complete, then teams would either have (1) really high velocities or (2) would probably finish sprints earlier than anticipated. Higher business value does not equate higher effort, and neither does the inverse. Thus, that's why we refer to story point estimations as "relative sizing". We're estimating the effort to complete a story relative to other stories, and not the business value relative to the value of other stories. That makes no sense at all.

    And with the comment above, "The customer cares about business value, and not your effort.", while that's true, customers probably care less even more about story points.

  4. Pffft... so wrong. Just defer the points to the next sprint. They get credit for them then. The average velocity comes out eventually.

  5. This comment has been removed by the author.

  6. In my opinion, points should go to the sprint where the story was finished. Saying that "the customer cares about business value, and not your effort" is an invalid argument, because when the team finish the story in the second sprint, they are delivering business value.

    Simply trashing these story points makes harder for the team to estimate their velocity as explained here: