The development of software, using other peoples money (OPM) means - or should mean - that those providing the money have an expectation to know How Much Money, along with When well you be done spending that money and provide me the Measurable Value (Effectiveness and Performance) I bought with that money?
This paradigm is at the core of any business process of developing software.
Story points were invented to bridge the need to answer these questions between the business and development team using a method for writing software that would later be called agile.
These developers started with a very good concept that wasn’t there before: The story. The book eXtreme Programming Explained is a good place to see this history.
So What can Story Points tell Us?
First, let's see what a Story Point represent? Here's one of several definitions
- A story point is an abstract measure of effort required to implement a user story. In simple terms, it is a number that tells the team about the difficulty level of the story. The difficulty could be related to complexities, risks, and efforts involved.
- 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. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.
Here are some benefits to using Story Points for estimating from Maarten Dalmijn's Medium post. (My comments in italics)
- Quickly estimate issues. Estimation is relative to already completed Product Backlog Items. This is faster than estimating without any reference.
- Using the completed items is the creation of a Reference Class. Reference Class Forecasting is a well-established process, see Bent Flyvbjerg's take on this topic From Nobel Prize to Project Management: Getting Risks Right
- Estimate without giving a specific time commitment. When estimating in hours you make a precise time commitment. Estimating in Story Points prevents giving an exact commitment. Nobody knows exactly how many hours you are appointing to a specific issue.
- Many story point user misuse SPs as a time estimate. A 3 point story will take 3 times longer than a 1 point story
- This cannot be the case since SPs are Ordinal numbers with no scale
- Same problem for cost, complexity, and risk
- Embrace the uncertainty that comes with estimation. Story Points specify an unknown time range. Selecting from a specific Fibonacci-like sequence of Story Points allows the capture of uncertainty.
- Yes all software development has uncertainty. Aleatory and Espitemic
- But Story Points are Ordinal and may be able to represent the Relative uncertainty. But uncertainty produces risk and risk impacts cost, schedule, and technical performance, and those measures are Cardinal
- Accurate enough to plan sprints ahead. This allows to better manage the time expectations of stakeholders for future work.
- Who gets to define the needed accuracy (and precision) for the estimates of the Sprint?
- Usually, those paying do. NOT the developers
Maarten goes on to shows some common mistakes, so read the Medium post about those
So Here's the Core Problem
Story Points can be useful is having a discussion about the Relative measure between Stories.
When we measure the relative differences, we're using Ordinal Numbers. An Ordinal Number tells the position of something in a list. For example, the 1st, 2nd, 3rd, 4th position. For a Software Story, we can assign an order in the list based on some discussion of what we perceive as effort, difficulty, complexity, or some other vague nebulous assessment.
This is a useful assessment, when we're missing that actual information about the effort, difficulty, or complexity of the development of the code the implements the story.
The other number used in the development of software is a Cardinal number. This number says how many of something there are. 1, 2, 3, 4 for example.
- 4 hours
- The value of the McCabe Cyclomatic Complexity metric
- The value of Halstead's software metric
- Card's Branching complexity
- Chapin's Data access complexity
- Elshof's Data flow complexity
- McClure's Decisional complexity metric
Now to the Problem
First Story Points ...
So here's a simple story about Ordinal numbers of Story Points
If we ARE using story points, they need to be Calibrated. This calibration means assigning a Cardinal value to the Ordinal number.
THEN maintaining that assignment long enough to be useful to the decision makers. This MUST be across the Sprint. And it would be very useful to maintain this assignment across the Feature consisting of many Stories for several Sprints.
And of course, we can't do math with these Ordinal values, by adding, averaging, and any math operations with Story Points, since they have attribute assigned to an entity.
When Story Points are used in the mathematics of software development, that is when people use the number of points in arithmetic they are committing a Category Error. This is because they have attributed a property to the number that doesn't have a property. If we say this apple is bigger than that apple, and I've assigned a 1 to the smaller Apple and a 3 to the larger Apple, then the 1 and the 3 have an attribute of the size of Apples.
When Story Points don't have an assigned attribute and they are used to make comparisons, that's the category error. For the Apple example, we can see that the two Apples, one bigger than the other, have a relative size attribute
Here's a good example of a Category Error
So, in the End, Story Points are Useful
SPs are useful, but use them correctly, but remember
And to use them properly we must ...
- Use them to assess the relative differences between stories
- With this information - relative measures - develop the assessments of cost, duration, complexity.
- There are many tools and processes for developing these numbers
Start with Troy Magennis's book Forecasting and Simulating Software Development Projects, then download his tools for managing an agile project with actual measures.
Bibliography
- Velocity and Story Points - They Don't Add Up!
- Software Complexity Measurement using Multiple Criteria
- Software Metric
- Understanding Software Through Numbers
- Software Complexity Metrics in General and in the Context of ISO 26262: Software Verification Requirements
- A Unified Metric of Software Complexity: Measuring Productivity, Quality, and Value
and about 85,000 other papers, articles, and books on measuring software complexity, cost, duration, and other attributes used to answer those pesky questions - how long will this take and how much will this cost?
So take Samuel Johnson advice, and do some homework
"Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it." "Much is due to those who first broke the way to knowledge, and left only to their successors the task of smoothing it."
