This article is the third part of a series. The first article is on Agile Planning poker, the second is on User Stories, and this third article is focused on Story Points.
Have you ever heard of “Le Grand K”? This is the nickname given to the cylinder of dense metal that has served as the standard of measurement around the globe for well over a century. Made of platinum-iridium, this object has been the single source of truth for the kilogram since the time of Thomas Edison. Historically things were measured by hands or arms lengths, but seeing that each person’s dimensions are different, these were more approximations than measurements. It wasn’t until 1668 that a standardized system was proposed, and even still it took over 100 years before the french took on the task of creating phistical objects to solidify standard measurements. This practice continued until 2019 when the last physical standard was retired in favor of more scientific forms of measurement.
In contrast to physical measurement standards, the standardization of time has been around much longer. The Babylonians are believed to have created the first sundial with the ancient Egyptians establishing the standard of a year. These measurements have been refined through the centuries and today we can not only measure time precisely, we can even measure the precise impact of gravity on any unit of time.
As citizens of the 21st century we have lived our entire lives with an understanding of measurement as a universal standard and I’ll bet that very few of us have ever questioned whether the inch on your ruler is exactly an inch or whether an hour as measured by your smartphone is actually equivalent to an hour. This is because we have been taught the measurement is precise and that to measure something you must first quantify it and then compare it to a standard unit of measurement. While this may be true in some regards I’m going to challenge that belief in this article as we dive into the details of agile Story Pointing.
What is a Story Point
In many agile frameworks, namely Scrum and it’s many adaptations, a Story Point is a relative measurement of a chunk of work. These chunks of work are generally called User Stories. By ‘relative’ I mean that the Story Point value of one story should be relative to the Story Point value of another. In other words, if one story is twice as complex and time consuming as another story, then it should have approximately twice the Story Point value.
Let’s talk about the different types of story point scales before we get much further. There are three main types:
Arbitrary Objects
Some teams choose to use arbitrary objects like Tshirt Sizes in order to help the team step away from the mental connection between a numeric number and an hour estimate. Though this can be helpful for new teams, a good team leader will translate these arbitrary objects into relative numeric values when the team finishes. The purpose for this is because statistics and tracking of a collection of arbitrary objects is much more difficult and quite limited compared to the flexibility of a numeric system. For example, figuring out how many User Stories a team can handle in a week given that they all have Story Point values of “Large-Tshirt”, is a lot more difficult than knowing that a team can generally handle 45 story points every 5 days.
Sequential numbers
For those that want to use numeric Story Points, the seemingly logical option is to use a sequential grouping of numbers such as 1,2,3,4,5 or even 1 to 10 for a wider range. These options are perfectly acceptable but tend to create a little too much discussion around varying opinions. For example, if we are using a 1 to 10 scale and the first User Story was rated by the team as a 4, then a story that is close to twice as complex could easily be rated as a 7, 8, or 9 by different team members. Since the agile Planning Poker exercise strives for unity through discussion, this close rating requires the team to talk it over and settle on a unified number even though all three are pretty close to the same thing.
Fibonacci
My personal favorite of the options is to use the numeric Fibonacci sequence. Also known as the golden ratio, this pattern of numbers allows us to have finer detail while at the small end of the scale while recognizing our inability to be highly accurate as the numbers get larger. The Fibonacci pattern is created by adding two numbers, then taking the new number and adding it to the previous number. For example, 1+1 = 2, 2+1 = 3, 3+2 = 5, 5+3 = 8, etc. The most common numbers for Story Point estimating with the Fibonacci sequence are 1, 2, 3, 5, 8, 13, and 21. As you can see, this method seeks general consensus as the numbers get larger. In other words there is no discussion around whether or not a User Story should be a 12, 13, or 14 with this method. Since 13 is the only option in that range, the team comes to this number naturally in unison.
Why do we need Story Points
You may be asking yourself why we need story points at all. If the goal is a standardized, numeric range, can’t we simply estimate hours instead? Bottom line is yes you can, but there are inherent issues with this that Story Points were created to solve. Here are the main ones:
Optimism Bias
Traditional Waterfall Project Management has been the methodology of choice for nearly a century now (Read our History of Project Management article for more details). This concept is based on breaking work into tasks and then estimating all tasks based on the time needed to complete them. All of these estimates are then collected and imputed into a gantt chart or other tool that plots out the total time it will take to complete the given project. In theory this is perfect, just as math is perfect. In practice however, there are too many unknown variables that are missed during estimation thus leading to numerous adjustments to the plan along the way, with so many adjustments, the final outcome never ends up being the same as the plan, negating much of the value of the plan in the first place. This phenomenon is known as the “Planning Fallacy”
The planning fallacy is a phenomenon in which predictions about how much time will be needed to complete a future task display an optimism bias and underestimate the time needed.
Agile Project Management, on the other hand, attempts to account for this Optimism Bias by establishing a relative measurement vs a standardized measurement. Though we can not seem to get rid of our bias, we can account for it always being present. Instead of estimating in hours that we know will be wrong, we can estimate in relative Story Points and then through statistical analysis establish a baseline for a team and thus create more accurate predictions then are possible with traditional methods.
Statistical Trending
As a relative measurement the hardest part is consistency. Centuries ago, measuring things by how many ‘hands’ they were was of course relitive based on the individual’s proportions. If this relative measurement was inaccurate though, why was it used for melania across the globe as an accepted measurement technique? The answer is that in lue of having a definitive measurement standard, using something that was statistically similar was close enough for estimation. When someone said their horse, for instance, was 14 hands tall, it was generally understood and gave a good estimation of the horse’s height. The reason this measurement technique worked for estimation purposes is because human hands are statistically similar. Through statistics we know that the average mails hand is 7.6 inches, but we don’t need that level of precision for estimation purposes because most hands are within a low standard deviation from the mean.
The advantage of measuring a physical object is that you can be more precise than an estimate with a standardized unit of measurement. Chunks of work, or User Stories, that have not been completed however are another matter altogether. Even if we attempt to attribute the standardized measurement of an hour to the estimate, we will inevitably be wrong because the work is yet to be fully defined and completed. The beauty of a Story Point is that it too is an estimate that is not directly tied to a standardized unit of time, then a Story Point of 5 could represent two hours or it could represent two days, both of which are acceptible. The important part is to ensure a story that is a little more than twice as complex is given close to twice the story points, Using sequential numbers this would be a 10-11, using fibonacci numbers this would be a 13. By estimating using Story Points the team is focused on estimating complexity relative to other User Stories and thus, when we get enough stories completed we can establish a statistical trend that can then be accurately related to hours or days. Just as you need to measure thousands of hands before finding out the average size, you also must let a team estimate and accomplish a handful of stories before being able to establish a statistical trend. In the end this type of estimating is far more accurate because it removes the optimism bias.
Universality over Skill level
Another key advantage of utilizing Story Points for estimating is that it establishes a standard that is not tied to a users skill level. Think of it this way. A skilled runner can complete a mile in 5 minutes but it would take a new runner 10 minutes to run the same distance. Did the measurement of a mile change? Of course not, only the time it took to complete it.
When you estimate with hours you are assigning work to a specific individual based on their skill level. This type of assignment mentality is quintessential Waterfall Project Management. In Agile, the team is responsible for the work regardless of who picks up the next story. To facilitate this, we need to measure the size of the work, much like the mile, rather than the time it will take to complete that work. This is a different way of thinking about measuring work for many people but the bottom line is that by universalizing measurements of work into units rather than focusing on time as the unit we are able to get a better statistical trend over time while avoiding the inherent optimism bias of the team.
Should Story Points be Standardized
We started off this article discussing the history of standardized measurements. The standardization of the inch, meter, leter, and minute revolutionized science and allowed us to step into new eras of precision around measuring various objects. As an Agile organization grows they are faced with the same predicament about how to measure and standardize their own set of measurements. Often, this leads to the question of whether or not they should attempt to standardize Story Points across teams, the question is whether or not 5 Story Points in one team should be the same as 5 Story Points in another. Though the intent here is noble, the practice often negates the benefits of using Story Points.
There are currently two ways this is generally attempted, first is the idea of creating example stories or baseline stories that all teams use as their relative point of reference. The other option is to attribute hours or days to Story Points and ask that all teams use this standard. Though there are advantages to this when coordinating major large scale endeavors, this adds a layer of unneeded complexity without the inherent benefits of abstractiving estimates from time.
A better solution is to let each team work indipendently utilizing story points as they were intended. That is, as an estimation technique that can be statistically trended to provide accurate projections. The larger organization can then use the accurate projections from each team as a way to unify and coordinate the initiative.
Note that some Frameworks such as SAFe (The Scaled Agile Framework) advocate for story point standardization and they provide some compelling arguments for this practice that are worthy of debate. You can read more about SAFe here.
Other Story Pointing Rules
So far we have talked a lot about story points and how they work. In this next section we will briefly hit on some of the top questions that arise when utilizing Story Points, and the associated best practices.
Always go up
It is inevitable, especially when using the fibonacci sequence of numbers, that a team or team member will want to rate something higher than X but lower than Y. It is important to coach your team that in these cases they should always go up. This does not mean that they should inflate their estimation each time, but simply that when there is a tie in their mind, they should always error on the side of the larger number.
Roll over story points if a story is not done
Oftentimes a User Story will get started but not completed in a given iteration. Teams want credit for their work and so they ask to split the story up or to get credit in the first sprint since it is “almost done”. Let me encourage you to stand strong on this one and set a precedent that if a story is not completed in a sprint then the team does not get the story points until the following sprint. This is important because statistics need consistency and by standardizing this rule you are providing statistical consistency and establishing a physiological forcing function for the team that will push them to get a story completed rather than letting it bleed into the next sprint. If your statistical numbers seem to go up and down significantly each sprint, consider breaking the stories into smaller chunks upfront rather than giving into the desire to give credit for work half done.
Everyone needs to give an estimate
This one is so important. When giving Story Point estimations or ratings, everyone on the team needs to estimate every story. In a perfect world your team is made up of well rounded individuals who can take on any task, in reality our teams are made up of humans who have strengths and weaknesses, often these strengths are defined by job titles. Though a QA will fill out-of-place rating a development task, or a marketing person might fill out-of-place rating a salesperson’s task, it is critical that everyone on a defined term estimate every story. This builds empathy across disciplines and creates better team comradery over time. The exception to this rule would be management, if a manager is not embedded with a team, they should not participate in the estimation exercise.
Don’t re estimate after a story is completed
From time to time a User Story ends up being smaller or larger than expected. This can lead to the question of re-estimating when the work is completed. In general I would say that this is a bad habit to get into but when the difference is drastic, leaving those numbers in the statistics can cause problems. For situations when the work is more than 75% larger or smaller then estimated you can estimate, or even better, remove the estimate all together. The decision as to which method you use will depend on how your organization tracks and reports on effort at the management level. When possible, try not to reestimate.
Summary
In summary, Story Points are a relative unit of measurement that provides clear benefits when estimating something as abstract as knowledge work that is yet to be defined or completed. The standardization of measurements has revolutionized our world but is limited to measuring things that currently exist such as a physical object or a historical event. Attributing standardized measurements to future events is little more than a prediction and thus should to be based on statistical trending instead gut impulse. Story Points give us this ability and are the primary unit of measurement in Agile Project Management.
Leave A Comment