Using story count instead of story points in sprint planning

Story Counting is a valid technique for planning. Martin Fowler has a good article on the subject. Joshua Kerievsky from Industrial Logic wrote a post on the experience migrating from points to counts.

I haven't worked with a lot of teams that use this technique, but it is important to put forth a good effort in decomposition. Although the effect of very small stories versus large stories may cancel out, my limited experience tells me that if you try to make them right-sized and focus on small deliverable or demonstrable units of work, you'll have a better experience.

Thanks Thomas,

Nice links, and I believe your idea about right-sizing sounds very reasonable. 

If the method is effective there is no objection to using it. Story points arent mandatory, more they aren't even part of the Scrum at all.

It is just the technique used by some teams

It's a reasonable enough approach, as long as there is sufficient liquidity on the board to render a usable "average".

Building in liquidity, should it be absent, is a skill. When Product Backlog items are broken down clumsily they may become too task-like, reducing transparency over value, and the Product Owner may then find it difficult to order them.

Perhaps the biggest problem I find with story counting idea is that it might let the team skip analysis of the stories. Analysis and discussion is a natural part of the size estimation. However, if we just blindly take the next 10 stories, it does not necessarily happen. Then, without proper understanding of the sprint content, sprint goal might be easier to miss, leading to many other nasty side effects.

I have worked with teams that used the number of stories for Sprint Planning and forecasting.  Using flow metrics like throughput and cycle time and techniques like Monte Carlo Analysis you can get a pretty clear understanding of "what is possible".  The links that @Thomas provided are great! (Thanks, I have not seen those).  I also recommend two books by Daniel S. Vacanti. Actionable Agile Metrics for Predictability and When Will It Be Done are both good books to help you to understand how to use flow metrics. These helped more than one team that I worked with that struggled with Story Points or just didn't like the process of providing them. 

Perharps you should try it, because it perfectly OK, and publish the result?

In my opinion, as long as the concept of "measurement" is understood clearly, teams should be free to pick their units of measurement, whether it is story points or number of stories. 

And measurement is nothing but obtaining the magnitude of a quantity relative to an agreed standard. So what needs to be ensured is:

- The "standard" or a reference is defined for a team

- and the standard is consistently referred 

Thanks Daniel,

Regarding flow metrics, I am applying those based on Mik Kersten's book Project to Product, and those are based on issue counting. So that is certainly a synergy that could be leveraged.

br, pertti