# Velocity calculation based on number of user stories completed in a sprint

In one of the projects, the velocity calculation is done based on the number of user stories that the team is delivering in each sprint.

They are using story points to size but still the velocity is determined by the total number of stories delivered and not based on the story points.

The customer wanted to track based on this to ensure we are in line with the release deadline that has been already set for the project.

How to handle this?

• Is the customer or the team tracking based on stories completed? Also, if the release deadline is set, is the scope flexible? Or is this a waterfall project with agile buzzwords sprinkled on top?
– Erik
Mar 7, 2019 at 6:54
• Unless all stories are exactly the same size, tracking stories completed is not inherently useful data. Mar 7, 2019 at 7:56
• @Erik Scope is also flexible; in the sense they do some additional user stories inside of a sprint. The release deadlines are defined up front and the development delivery happens in iterations. Mar 7, 2019 at 9:37

You need to first understand to what extent the story count is helpful and we do this with standard deviation. If we look at the average story size across a release and the standard deviation is low, you will find that the trends created between story size-based velocity or count based velocity are identical. If the standard deviation is high, they will trend differently. If you're not a big math fan, there is an easy visual way to do this. On the same graph (2 different y-axis scales) plot both of the velocities. Do the lines look the same? If so, you can use either. If not, stick with story size, not count.

There is a fairly large "noestimates" movement that finds a lot of success in right-sizing all stories so they are approximately the same size and then they only look at count. They don't have to be exactly the same. To give a concrete (if hypothetical) rule, a team using point with an average velocity of 40 would probably want most stories around a 3 with a small number of them at a 1 or 5 before they could drop the story points. (This is a deeply flawed example, don't actually use it to implement, just trying to give something concrete.

Now, we should also talk about that last bit about being in line for a present delivery date. From you comments, it sounds like scope and time are fixed, which is almost always problematic. Regardless of what metric you are using, any less-than-desirable picture the forecast paints must be used to manage the backlog, not the team, or you are going to get a lot of dysfunctional behavior and probably lose visibility into your progress.

If you have stories of different sizes, you will need to track velocity based on that sizing, whether it's story points or any other metric.

There is nothing you can do to fix a totally broken metric of stories per sprint when they aren't the same size. Throw it away and start over. If you can, generate past velocities for the new metric based on your old stories.

• This has not been true in my experience. I've seen many teams succeed with story count as opposed to story points. In fact, the whole no estimates movement is based on those types of successes. It may or may not be done well in this case, but it is certainly possible . Mar 7, 2019 at 8:44
• Having 19 Stories of 1 point and one story of 20 points, a metric that says "half the stories are completed" say exactly nothing about the ability to complete the other half in the same time. So yeah, any project can succeed with any metric. I have been in project where the PM simply lied and made up colorful charts to get customers to pay, regardless of numbers. But if you want to provide numbers that are mathematically sound for forecasts, number of stories is about as valuable as gut-feeling. Some people have a great gut-feeling. Doesn't mean it's a great method. Mar 7, 2019 at 9:30
• A million upvotes for this - this is a broken metric and offers no value whatsoever. Mar 7, 2019 at 10:50
• @Daniel: In the no estimates movement, everything must be refined until it is all about the same size. When you reach that point, you could just as well say that every story is 1 SP. The pitfall of blindly counting stories (without assuring they are equally sized) is that you count how many apples and melons fit into one basket. Mar 8, 2019 at 11:39