In our previous article on estimation, we concluded that time-based estimates is a bad idea and must be avoided at all costs. That approach involves too much guesswork that results in imprecise numbers and leads to harmful pressure on the team. Here, we offer story points as a more viable unit of measurement and make a case for them over estimating in hours or days.
Making the case for Relative Sizing
Be clear about what you’re asking
The inherent inaccuracy of time-based estimates is what tilts the balance in favour of story points. The question that kicks off the time estimation process—”How long will this take?”—actually comprises of sub-questions like “How big is this task?” and “How fast can it be done?”. We disregard the compound nature of the question and attempt to derive a combined answer. However, this answer is based in speculation and results in inaccuracy.
Answer one question at a time
The correct approach is to break down this bigger question into its components and answer each sub-question independently, while being mindful of conditions that can impact the response. The response to “How big is our user story?” is dependent on the functional, logical, or technical complexity of the job. And the response to the question “How fast can it be done?” will be dependent on the team members’ skills, experience and exposure to relevant technologies and domains as well as on several factors that make up the environment in which the team will operate.
The right–and relative–answer
Story points are a response to only the first of the sub-questions: “How big is a user story?”. Having said that, even this question is not straightforward and getting the answer right is hard. The pragmatic way is to refrain from an absolute response, and instead answer the question relatively.
Here’s an example from the physical world to illustrate this line of thinking. If you were given an item, say a TV remote, and asked how big it is, it would be difficult to reply with a precise numerical value. However, if you were asked how big the remote is as compared to a pen or as compared to a TV, then answering becomes easier and it’s accurate too.
That’s exactly what story points do—gauge the size of a user story in comparison or in relation to other stories in the project. They do not try to pin down an absolute and independent number for the size of a story. Estimation done this way involves very little guesswork, results in accuracy, and consequently leads to better results for the team.
The process
Before we explore the advantages of story points, here’s a quick overview of the process. Story point estimation is also known as Relative Sizing or T-shirt Sizing—both very apt names.
How to size?
- Story point estimation begins with picking up one batch of stories in your backlog.
- Look through them and identify the smallest in that batch.
- Label that as “Small.”
- With that as the benchmark, pick up the next story. Is it of similar size? Is it twice the size? If it’s similar in size, then that’s also a Small. If it’s twice the size, it becomes a “Medium,” which is your next size.
- Move on to the next story and do a similar comparison. If it’s twice the Medium, you’ve got a “Large.”
Once you have a few reference stories in each of these three sizes, the process becomes easy to repeat with confidence. Each story in your backlog is allotted a size by comparing it to the reference stories in each of the 3 sizes. If a story seems enormous, you could break it down into two stories that are still independent and valuable. And voila! You’ve completed Relative Sizing for the entire backlog!
How to count?
Once you’ve finished with bucketing and sizing, you do the math, i.e., convert the S, M, L sizes into numbers. While determining the size, you already used a scale of multiplied by two.
That way:
Small = 1 point
Medium = 2 points
Large = 4 points
Then add up the story points to get the complete picture of the backlog. For example, you can conclude that this backlog is made up 20 Smalls, 40 Mediums, and 20 Larges. They add up to 180 points, which is the total of all the story sizes. This number (180 points) provides you the scope of the entire project.
Limit number of sizes to maximise gains
In order to leverage these intrinsic advantages, it’s imperative to limit the number of size options. We advocate using just 3 sizes and go to a max of 4 sizes if you can’t avoid it. Any more than that and you’ve created unnecessary complexity. Not only will you reduce the probability of getting it right, but you will also take longer to agree on the size. With just three sizes, speed, accuracy, collaboration—and consensus—are very easy to achieve.
The benefits
There are many reasons that make story point estimation an effective approach. This relative sizing process is:
Fast: What you’re essentially doing here is comparing the story in hand with an already-sized set of stories. If it feels roughly similar in size, then that’s a Small too. Or then call it Medium or Large depending on how the complexity compares to your first Small. This process can be wrapped up quickly. To give you a reference, we have seen teams size up 100+ stories in a couple of hours.
Collaborative: This process is best done collaboratively by multiple developers and other team members. During sizing, each team takes the opportunity to think about functional complexity, the kind of code they’d need to write, etc. Then they all make a guess about the size of the story. There could be differences of opinion regarding the size to assign. But that can be resolved quickly by asking team members to discuss and clarify their underlying assumptions.
Accurate: Given that your primary task is to carry out the relative comparison of one story to an established standard, you can’t go wrong! Moreover, if you limit the size options, you have taken necessary precaution to eliminate further error resulting from excess choice.
Independent of team composition: Given that we are attempting to only answer “How big is the story”, we do not need to factor in things like who is going to be on the team and how skilled and experienced they are. This makes the story points you come up with completely independent of the team composition, which is often an unknown at these early stages of a project.
Consistent, with no need for re-estimation: The eventual pace of the project—faster or slower than planned—has no impact on the sizing of a story, which is our foundation for estimation. Factors relating to the team or the environment have no bearing on the story size, and consequently the estimation process—contrary to what happens in time-based estimation.
The only reason for a story size to change is the exceptional and rare situation of core functional or technical assumptions changing. In such a scenario, it is more efficient to trash the older story, create a new one, and estimate that one instead of re-estimating the older story. This emphasises that story sizes remain consistent over the lifecycle of a project, and teams do not need to engage in the laborious effort—and pressure—of re-estimation.
There is no estimation involved here at all!
In fact, this objective process does not involve guesswork or approximation at all. You are simply evaluating the size of a story against an established and limited baseline. It’s highly unlikely that you will go wrong.
Estimation, therefore, is misleading terminology in this context. Story Sizing, Relative Sizing or T-shirt Sizing are more appropriate terms for this process.
With “How big?” answered – what’s next?
You’ve now satisfactorily answered the “How big” question with story sizes and points. They’ve given you a good grip on the scope of the project. Now you’ll want to think about how fast you can tackle that scope—the second of those sub-questions we started out with. That’s the next milestone in this journey of estimation and planning. We’ll cover that in our next write-up, so watch this space!