Why I like “Number of completed stories” as a metric

… or Small stories kick ass!

In his superb video explaining the role of the Product Owner Henrik Kniberg chooses “Number of completed stories” to measure the teams capacity (velocity). He mentions story points, but chooses a less widespread measure. Why did he choose it? Don’t know. I only know that I would make the same choice:

Any metric can be gamed. Story points are especially easy to game, as the amounts are only meaningful within one team. And it takes just one ill-timed “Why isn’t the velocity going up?” to kick-off story point inflation.

But hey, can’t “Number of completed stories” be gamed just as easily? The team just has to make the stories smaller.

Why, yes. Precisely! It’s a metric I want teams to game!

In my experience it’s difficult for “fresh” agile teams to cut stories down. It’s a skill that grows with practise. People not accustomed to splitting stories into nice vertical slices tend to think it’s not possible. And they often don’t see the value in it, so they don’t really try.

Pointing out the value I see doesn’t necessarily help, although small stories…

  • … are more thought-through
  • … have less open questions
  • … have a lower probability to turn out way bigger than expected
  • … contain less uncertainty and bad surprises
  • … have a higher chance of being completed in one sprint
  • … are more focused on value-adding functionality
  • … easier to talk about

Pointing out that “small” is even in the INVEST acronym that good stories try to adhere to doesn’t help either 😉

Usually teams need to work with a few bloated as well as bite-sized stories to experience the difference and witness the advantages of the latter over the former.

[Clarification: What do I mean, when I say “small”? Well, I’m used to 4-7 people dev teams and 2-week sprints. In this setting I consider a story “small” if it can be accomplished:

  • by at most a 1/3 of the team
  • in at most a third of the sprint time.

If these parameters change, so might my definition.]

Anyway, I feel that knowing they’ll be measured in stories gives teams an incentive to try and split stories. If the team doesn’t game the metric / doesn’t learn how to bite-size stories, I get an accurate velocity. That’s fine, too. But I’ll prefer leaner, clearer stories and a learning team anytime.

What if a team takes it to far? Cutting stories down into meaningless bits? Well, a story is still supposed to add business value, isn’t it? So, if the team can’t resist, let “Adds business value: Yes/No” and the PO be your safety net.

From what I’ve seen, stories that are too small are significantly rarer than stories that are too big. And the too small ones are much less of a problem.

What’s your experience?

Related Article:

Published