Estimating is an informed assessment of an uncertain event. All project work operates in the presence of Uncertainty. Estimating means developing probabilistic confidence intervals for the possible outcomes of that work in the presence of uncertainty.
The numbers we use on projects come in two types
- Ordinal measures tell us the relative difference between items.
- Cardinal measures is a number that says how many of something there are, such as one, two, three, four, five.
Story points are Ordinal numbers, Stories are Cardinal numbers. Story Points are relative measures of effort. They are not duration or cost. Story Points are measures of relative effort [1]
Story Points are arbitrary measures used by Scrum teams to determine the Relative (Ordinal) effort of the work. They tell the team how hard a story is, from it’s perceive complexity, risk, unknowns – each related to effort. These Relative (Ordinal) measures are the antithesis of Business Management measures of work planning and accomplishments, which are in Hours and their rated dollars for the direct labor needed to produce the outcome (assuming no material cost).
Story Points don't tell us the duration or cost of this relative effort. Story Points dont' tell us the absolute effort to performance the work. They aren’t normalized across work efforts, across teams, or across the program. Story Point effort estimates are not Calibrated across the project, but rather are developed for the work at hand. The calibrated units of measure for Story Points – can and will change – change as the program progresses.
Business operated in units of dollars and duration for the work needed to produce the needed capabilities in exchange of those dollars and time. Business does not operate in units of Story Points.
The killer question is what is a Story Point Worth to those paying for the work? Agile teams rarely produce comparable calibrated Story Points for dissimilar or even similar work. This is a key difference between Business estimates and Agile estimating. Most businesses have an external Basis of Estimate process to calibrate the cost and duration of planned work. Business teams working on different parts of the project, with different assessments of Effort, different story point values, and different project costs result in dissimilar units of measure for a Story Point.
When Agile teams have different approaches to applying Story Points, the physical effort can still be calculated for each team, and rolled up to the Total Story Point count for the project for an individual Feature Physical Percent Complete.
The program level budget can flowed down to the planned Work in the Product Backlog and connected with the Total Story Point count built bottom up from the Agile Planning process.
From there, all Physical Percent Complete calculations remain the same - units of Story Points and Dollars
With the proper application of Story Points, at the agile estimating level, the Business can produce a Cardinal estimate the cost of the work with some simple rules:
- If there is a single team doing the Story Point estimates, and that single team remains intact during the Sprints, and their cost remains intact during the period of performance, and that team has a know capacity for work measured in story points from past performance, then the Story Points can be converted to Dollars for the Business.
- If any of these conditions is not true, the Story Point estimate (relative effort) is no longer valid for the business.
Measuring The Project with Stories and Their Completon Rate
There is a conjecyure that measuring Stories is better than measuring Story Points. Here's the simple answer to that conjecture
This can only be valid if the Stories are statistically similar enough that their individuals variances (range of actual effort versus the estimated effort) in the collection of Stories is de minimis. That is the Stories are statistically identical.
If this is not the case, then uses Stories rather than Story Points as the measure of effort and conversation of those measures into units meaningful to the business is a fools errand. It violates the principles of statistical process control since the unit of measures of plan and progress itself has statistical variance unaccounted for the the data received is bogus.
If you don't have statistically identical relative efforts for all stories, never use Stories, Only use Story Points.
As well, a second caution is the false assumption that the future is always like the past. I got a book for Christmas Fool Proof, Greg Ip and our false belief that the future will be like the past. On any non-trivial project this is never the case, so making the assumptions that all stories are of the same size turns us into the fool in Fool Proof.
[1] Scrum + Engineering Practices: Experiences of Three Microsoft Teams, Laurie Williams North Carolina University, Gabe Brown, Adam Meltzer, Nachiappan Nagappan, Microsoft Corporation
