There's a popular meme on social media that goes
...just count the number of stories, instead of Story Points that's all you need to estimate a software development project.
That's an OK idea if several things are in place.
But first Story Points are Ordinal numbers, and without knowing what a SP is worth, any estimates using them is meaningless.
Is a 10 Story Point Story worth an hour's effort? 30 minutes effort? 3 days of effort?
What is a Story Point worth in some cardinal measure meaningful to those paying you for your work? If you spent 32 hours developing the capabilities provided by the story, is it worth that effort times some multiplier? How can you have an answer to that question to some degree of accuracy and precision before spending your customer's money?
Because the balance sheet of the business you're working for doesn't have a column for Ordinal Values, Story Points, counted Stories. The values found in that balance sheet are money and hours.
And before we move on let's get definitions straight
In statistics, there are four data measurement scales: nominal, ordinal, interval, and ratio. These are ways to sub-categorize different types of data. These are called Estimators. Not estimates, but the representation of a value that comes from a statistical distribution or a probabilistic process (a stochastic process):
- Nominal is a label of something without a quantitative value. A telephone. number, a player on a team, a zip code. Nominal numbers do not show quantity or rank.
- Ordinal is the order of the value (ordinal and order) The order of the value is what is important, but the difference between the ordinal values is not really known. It might be good to know that item #4 is better than #3 or #2, but we don’t know–and cannot quantify–how much better #4 is from #3 or #2. The other common Ordinal Value is the old Sears, Good, Better, Best. Statistically, the central tendency of ordinal data is to use the mode or median value of the frequents count of the number of good, better, best occurrences. The mean can not be determined from an ordinal set.
- Cardinal is a number denoting quantity rather than an order or size. $10 is a Cardinal number. You weigh 190 pounds is a Cardinal number. 167 days duration is a Cardinal number, 8 puppies and 14 friends are cardinal numbers.
So Now to the Problem of Story Points
What we measure matters because it guides what we do - Joseph E. Stiglitz, Professor at Columbia University, Chief Economist at Roosevly Institue
Story points are measures used in agile software development.
Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant.
Story Points are estimates of effort influenced by the amount of work, complexity, risk, and uncertainty. †
A 10 Story Point story may be less work effort, complexity, risk, or uncertain than a 20 Story Point story. But what does that means in time, money, the effectiveness of the story, technical performance of the story, probability of the risk impact on cost, schedule, and technical performance?
The raw value of the story point is unimportant since that assignment is a relative value compared to other stories with story points. †
† Mike Cohn's Mountain Goat Blog is a good place to start learning about agile without all the nuanced blather of someone trying to sell you a method, tool, or consulting services.
For story points to be useful in business, they need to be calibrated to the Ordinal units of measure used by those paying for the work when making decisions ― Dollars, Hours, and engineering measures of performance and effectiveness and other business or technical values. That calibration turns the ordinal number into a cardinal number.
But the killer problem is that calibration has to hold across multiple work boundaries and across multiple teams performing the work. My 20 point story may not be your 20 point story. My 20 point story may change to a 15 point story once I start work. My 20 point story may morph into a 10 point story because I now understand a different meaning is a single (1) story point - I've recalibrated what a single story point is worth.
If you and I say our stories range from 10 to 30 story points in work, complexity, risk, and uncertainty someone else on our project may have a different definition of what 10 story points means to them. It could be higher or lower work, complexity, risk, and uncertainty.
One Conjectured Solution is to Count Stories, Rather Than Story Points
OK, fine, but now we have another problem.
Counting stories is Cardinal. There are 16 stories in our current Release Plan. What's the measure of the work, complexity, risk, and uncertainty of each story? Are they the same, similar, or even in the same ballpark. Will those measures remain constant during the project
There are those that suggest we get the average story size. Here's the fallacy of that.
- Those making that conjecture appear to have never read Sam Savage's The Flaw of Averages or Darrell Huff's How to Lie with Statistics.
Let's assume for now each story is somehow different in work effort, complexity, risk, and uncertainty. This would be a safe assumption since to assume otherwise would mean all those stories are the same story.
Here are some previous blogs to speak to this variability of software development
So Now to the Actual Question
If we count stories, instead of using story points, what impact on the statistical properties of the work effort, complexity, risk, and uncertainty of EACH story and the COLLECTION of stories does the variability of those attributes have?
When the stories are pulled from the backlog and placed in the Sprint, they may or may not have dependencies between them.
Let's look at an example where there are no dependencies, so when we're done with one story we can start work on another with no concern about which story comes first or last.
In this model, the uncertainties - both reducible and irreducible - impact the duration of the work, no matter how that work was estimated. In SPs, Hours, of Hog's Heads, those uncertainties are always present.
And of course, the units of measure for that work, needed by those paying for the work, are hours and dollars. Speaking in Stories or Story Points is of little use to those signing the check to pay for the work.
So Why All This Fuss Over Story Points Versus Story Counts?
Good question
Neither story points nor counting stories does anything to inform the Estimate to Complete or Estimate at Completion in units of meaning to the decision-makers. IF those measures are not calibrated against hours and dollars.
This is an immutable principle of managerial finance
Your paycheck doesn't have Stories or Story Points in amount field it has dollars. Your time card doesn't have Stories or Story Points in the field you enter at the end of every day in many domains where time cards are used.
Project planning and performance is measured in cost, schedule, and technical performance all of which are Cardinal Numbers
Counting Stories Provides No Actionable Information
Without a unit of measure meaningful to the decision-maker, the management of any work efforts is OPEN LOOP, and there is no measure of physical percent complete toward the goal
- Story Points don't provide a measure of physical percent complete since they have no physical unit of measure
- Counting stories only provide value if you know the statistical properties of the stories - the Most Likely duration, effort, risk, complexity, and the Variance of that Most Likely value. Then you can develop an Estimate to Complete and an Estimate at Completion
