Counting Stories

A few weeks ago, we started measuring our development performance in a new way. We simply count the number of completed stories (stories with business value only) and track this number over time. We are firm believers in the psychological effect called “You get what you measure”, i.e. when you start to measure some metric and make it very visible, it will converge to the desired value over time. To achieve this effect and to help us focus on the story pace, we have installed monitors in our team room that display our current pace at all times.

One of our team monitors showing the number of stories closed so far the current week (week 38). The number 5 is the current weekly goal.

One of our team monitors showing the number of stories closed so far the current week (week 38). The number 5 is the current weekly goal.

Just counting the number of stories without using story points or any kind of estimation may seem like a crude strategy, but we think it will have some really nice benefits and we are excited and anxious to evaluate the experiment over time.

A sceptic may react to this strategy by saying: That’s silly, you just have to make less work in each story and you will get a higher score!

This is very true. And also very advantageous! It creates a win-win situation in which we get the story pace metric for tracking purposes, and a mechanism/incentive to decrease the size of our stories. Smaller stories provide a better flow, more frequent feedback, and less waste. (To name just a few benefits)

So, how long can we rely on this mechanism? Well, if we are successful at decreasing the story size continually, the number of stories per unit of time will increase. Eventually, the overhead of switching between stories will become too costly (percentage-wise). To achieve an even higher story pace at this point, we will have to focus on our tools and processes to reduce the overhead. As a result, we go from win-win to win-win-win: By introducing the story pace metric, we get the metric itself, an incentive to create smaller stories, and finally a mechanism that incentivises us to streamline our process and our tools.

This advantageous spiral may – in theory – go on forever. However, some kind of practical equilibrium will probably settle after a few cycles. At this point we will have become experts at slicing our stories into super thin slices and and also at streamlining/automating our process. We will have a nice high throughput of quality work, but we will also have something that may be even more desirable than a high pace: A predictable pace. Our product owners are going to love us! (Even more…)

All of the above is of course only our theory/hypothesis. We are looking forward to the coming months to see if we can pull it off in practice!


  1. Interesting idea. But I think it guides in the wrong direction.

    You have a current system, and then you want to build a better system that is more valuable. But the cost of getting there should be minimized.

    Since all stories cost 1, but with unknown value: I am afraid you will maximize cost and getting an unknown value. It may yield many features that are easy to implement, but maybe not so valuable.

    I think the key is to measure the value you create. Like adoption rate of the new feature. Or something else that measures the impact of the implemented story. An unused story should score 0, or even get a negative number.

    Or did I miss something?

    1. Thanks for commenting. Your idea is interesting too, and I hope you will find a way to experiment with it. I think it is really important to treat all ideas as hypotheses and then confirm or dismiss them using experiment in the real world.
      Having said that, the hypothesis described above is not just taken out of the blue. We have many iterations of other experiments behind us that have led us in the direction of the Counting Stories experiment.

      Regarding measuring value: I think this is just a matter of where you put you boundary. Around the development teams or around the entire organisation.
      Our development teams are involved in creating all stories but our product owners have the final say of what is important and not. Consequently, the development teams can consider every story “valuable” since they come from the PO backlog.
      It’s another “story” (no pun intended…) when a feature reaches the end user. There, it will need to be analysed for e.g. utility and usage, which brings us to another great feature of tiny stories: You get very rapid feedback. If you deploy something that did not turn out so well, it’s not a mega project to pull it back or improve it.

  2. Hello,

    First of all thank you for sharing this nice article!!

    Some months have passed since you introduced this concept and I got curios. Is it working good?

    Also, the articles mention that only stories with User Value are included. I am wondering what your approach towards Technical Debt is. I am writing my Master Thesis at Chalmers on the topic and seems that the trend is to make those “chores” first-class citizens in backlogs (e.g. visible for both developers / product owners ). I understand that those monitors only show a part of the picture and I also believe that you follow the mentioned guideline in your internal boards. However, doesn’t it force developers to delay maintenance activities in order to get a higher score and hence increasing the debt interest?

    Thank you for the answer. I am really looking forward to it.
    Have a great day,


    1. Hi Marcello.
      Thanks for commenting on my post. I haven’t made any updates to it because a team re-organization disrupted the experiment somewhat. As a result of the re-org, we had to reset the test results and start from scratch, in a sense. However, we are still using story count as the main metric for our teams. The subjective experience is very good so far. Hopefully we will be able to post a more detailed follow-up sometime in the future…

      You are right, our strategy gives the teams a incentive to neglect technical debt, but only in the short term!! This is a very important aspect. If a team would focus only on stories with customer value (we call them “PO-stories”), the team performance would decrease in the medium and long term due to more bugs, and more maintenance.
      Also, the teams are committed to never decrease the long term story count (long term being a 30-day-ish average), in order to achieve predictability for product owners. Consequently, we don’t want short bursts of high performance. Sometimes it’s better to be predictable than being fast! Ask any product owner trying to set a long-term roadmap…
      I hope this answers your question.

Leave a Reply