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:

This entry was posted in Agile / Lean, Fairly Good Practice. Bookmark the permalink.

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

  1. shaunakinney says:

    Smaller stories and smaller groups work. Great article!

    I have a hunch that repetition helps, too. There are a variety of distractions or staff members come and go. By repeating short topics, maybe even with an update or revision to the conclusion of the story, team members are more likely to ‘hear’ the message.

    Communicating ‘in reverse’ is another idea — set listeners’ expectations by stating why you are telling a story before you start the story. End the story by restating why you told the story.

    As for smaller stories, I think it’s a compound cultural evolution – technology, sound bites, smart phones have all trained us to a shorter attention span!

    Communicating in a small group is more of a discussion. In small groups, our natural behavior can include looking team members in the eyes, speaking with a conversational rather than authoritarian voice and asking how the individuals would work with the goal or message.

    Final observation, I have noticed that smaller groups help the various personalities that make up a team find their voice. A brilliant and shy personality is more likely to speak up in a group of 3 than a group of 30. In contrast, a brilliant and strong personality is less likely to hijack the leadership of a project in a meeting group of 3. And, the personalities in the middle keep the conversation moving.

  2. Corinna,

    Keep up the great work! You keep me thinking and growing.

    I enjoy following your articles and was connected with you through an article at http://www.culturesync.net . Your article is on my mind, because I was in the process of researching and summarizing a customer training and customer service idea. I have a couple web based projects where just-in-time communication, webinars, conference calls and self-service communication need to be more concise and purposeful. Each small group wants just enough information to complete a task, but doesn’t want to sift-n-sort through long training calls or big help forums.

    I find the first small audience that needs to be addressed is the staff responding to the customers. A small, sometimes overlapping group of staff updates the product descriptions and web content — they need to hear some of what the customer sales staff heard! I believe there is a final small group — not considered before that WANTS to be part of the discussion — a small following of loyal customers. These customers champion the service and products, offer ideas and refer the company onto friends.

    Here’s another written documentation article — a tangent that loosely relates to your post above. I think you might find the ideas in this source harmonious with your ideas here.
    http://www.stc.org/education/online-education/recorded-seminars/item/applying-progressive-information-disclosure

  3. shaunakinney says:

    Reblogged this on Helping Tech People Communicate and commented:
    Communicating with staff and vendors is best done in small groups with frequent, short stories. Thank you Corinna for the observations on how to keep teams and projects discussing and meeting efficiently.

Leave a reply to Corinna Cancel reply