Estimating User Stories
August 13, 2019 by Kim Loomis, Product Owner @ Fathym
Basis for Estimation
One of the biggest misconceptions about story point estimation is the basis for the estimate. A lot of the time, developers, especially new developers, think it is based on hours — how long it will take to develop the thing in question. While that seems reasonable, that’s incorrect.
Let’s say you are asked to develop transportation. There are many different types of transportation. Client A asks you to build a foot scooter. That primarily consists of two wheels, axles, a foot board, a stem, and handlebars. But Client B asks you to build an automobile. That consists of a chassis, tires, wheels, axles, engine, windshield and many more parts.
It’s probably easy to discern that building the automobile will take a lot longer to build than the scooter. That determination, while initially quantified as a measure of time, is really based on complexity. It’s going to take a lot more time, resources, and knowledge to design, develop, test and release the automobile than the scooter.
Complexity is what drives estimates. An estimate for a User Story (US) is an educated guess, not a commitment, not a firm delivery date. It describes the uncertainty and complexity of the US. It is not an expression of hours (time) necessary to deliver the US.
Estimating a User Story
The Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21) can be used for story point estimates. There are other ways to do estimates, but we will focus on Fibonacci in this article.
It is not linear and forces the team members to chose “more or less” as there is no in-between. It forces the team members to provide a relative estimate and not an absolute estimate. It helps group and differentiate the size of tasks.
The scale can also be similar to the Fibonacci sequence (not exact), where each number is generated by taking the sum of the previous two numbers. The benefit is as the numbers grow larger, the gaps between them increase. This accounts for the higher level of uncertainty for larger-sized stories.
Using this scale is beneficial because numbers that are too close to one another are impossible to distinguish as estimates.
When assigning a low amount of points to a US, there is more certainty of the context, difficulties and attributes of that US than when a high number is assigned.
T-Shirt Sizing
Sometimes, it is easier to understand estimating if we equate it something that we regularly “size”, such as clothing. T-shirts are a great example, as a difference between sizes are quite evident, just like you want for stories. You could probably eyeball a group of randomly selected t-shirts and tell the size of each without looking at the tags.
Equating the Fibonacci sequence to “t-shirt” sizes, 1 would be the extra small and easiest US, 2 would be small, 5 would be medium, 13 is large, 21 would be extra large and 40 would be extra extra large.
Points & Meaning
Here is a straight-forward definition of the US sizing.
0 — VERY QUICK TO DELIVER AND NO COMPLEXITY; DONE IN MINUTES
One should be able to deliver many 0’s in a day.
The developer should be thinking: “I know exactly what needs to be done, and it’s going to take me very little time.”
Example: Change color in CSS, fix simple query
1 — QUICK TO DELIVER AND MINIMAL COMPLEXITY; DONE IN AN HOUR
One should be able to deliver a handful of 1’s in a day.
The developer should be thinking: “I know exactly what needs to be done, and it’s going to take me little time.”
Example: add field to a form
2 — QUICK TO DELIVER AND SOME COMPLEXITY; DONE IN MULTIPLE HOURS
One should be able to deliver one 2 comfortably in a day.
The developer should be thinking: “I mostly know what needs to be done, where improvements/changes need to be implemented, and it’s going to take me some time.”
Example: Add parameter to form, validation, storage
3 — MODERATE TIME TO DELIVER, MODERATE COMPLEXITY, POSSIBLE UNKNOWNS; DONE IN ONE OR MORE DAYS
On the order of about a day or more to deliver.
The developer should be thinking: “I have a good idea what needs to be done, and it’s going to take me a bit of time.”
Example: Migrate somewhat complex static CSS into a CSS pre-processor
Of Note: a dev team may generally assign 3 points to an investigatory or research User Story. These type of stories should be time-boxed and the depth of investigation should be defined.
5 — LONGER TIME TO DELIVER, HIGH COMPLEXITY, LIKELY UNKNOWNS; DONE IN MULTIPLE DAYS
On the order of about a week or more to deliver.
The developer should be thinking: “I know what needs to be done at a high level, but there is a good amount of work due to complexity/amount of development, and there are big unknowns we’ll discover as we get into the work.”
Example: Integrate with third-party API for pushing/pulling data, and link to user profiles in platform.
8 — LONG TIME TO DELIVER, HIGH COMPLEXITY, CRITICAL UNKNOWNS; DONE IN A FEW WEEKS
On the order of a couple or more weeks.
The developer should be thinking: “I understand the concept and the goals, but it will take a while to deliver due to amount of work, complexity, and unknowns.”
Example: Overhaul the layout/HTML/CSS/JS of a web application
Of Note: If the dev team estimates an 8, the team should break them into smaller tasks/issues with smaller point values and minimize the complexity. This might require a Spike to architect/remove uncertainty, or be created as an epic with more granular stories within it.
13 — LONG TIME TO DELIVERY, HIGH COMPLEXITY, MANY CRITICAL UNKNOWNS; DONE IN MULTIPLE WEEKS OR MONTHS
On the order of many weeks/month
The developer should be thinking: “I believe I understand the concept and the goals, however, I may have questions, and it will take quite a while to deliver due to amount of work, complexity, and unknowns.”
Example: Migrate application from an outdated data store to new DB technology and ORM
Of Note: Similar to an 8; this should definitely be an epic, and requires discussions around how to accomplish.
At this point in the sequence, as a rule of thumb, anything bigger than a 13 is generally thought to not be able to be done in one 2-week sprint. But if a story is estimated above 13, pay attention — your team is telling you very important information about it! When I see these larger numbers, I know I have not done a good job of writing a user story — it is too vague or too encompassing.
20 or 21 — WAIT A MOMENT!
It’s probably a Feature (many user stories). Definitely examine this and split it up into multiple user stories that are manageable!
40 — WOAH!
It’s probably an Epic (many Features). Definitely examine this and split it up into multiple features and user stories.
100 — STOP AND REGROUP
It’s probably an Initiative or a Theme (many Epics). Definitely examine this and split it up into multiple epics, features, and user stories.
Coffee Cup — TIMEOUT
The coffee cup, or teacup card represents a “coffee break” request. Often, planning meetings can run long, and this is a way for players to request a break to eat, rest, or grab a cup of joe! And if the estimating meetings are running long, you may be trying to accomplish too much at once and should consider breaking up into multiple, smaller meetings.
Question Mark — NEED A LOT MORE INFO
The team should discuss each story before voting, but sometimes a team member really has no idea what to estimate. By using the question mark card they’re saying, “I have absolutely no clue what I should use for an estimate.” In this case the team should discuss the story further and re-vote.
Of Note: As a general rule, if this card is used often it means the team needs to discuss the stories more so every team member understands enough to be able to vote with a story point value.
Infinity symbol — SUPER DUPER HUGE.
Sometimes a story is so large that it won’t fit into even the max “100” value. This may be a story so large and undefined or risky that the team member doesn’t feel comfortable placing any sort of story point value on it. It’s bigger than an Initiative or Theme — maybe it represents one or multiple organizational strategies.
For example, “As a map user, I want a new rendering engine so my maps will appear more quickly.” One or more team members understand that to mean, “Re-write the entire core framework of the application that we just spent the last 5 years creating.”
This type of story either needs clarification (“I didn’t mean re-write the whole core of the app!”) or the story needs to be scaled down into smaller pieces.
Educating Your Team
I recommend story point estimating to be discussed frequently with the team. This is necessary education to help ensure the team works cohesively and everyone estimates with the same understanding of the Fibonacci sequence and the assignment of numbers is consistent. I help new developers understand this during on-boarding. I also remind the team before we start any estimating sessions so it’s fresh in their heads.
Conclusion
Helping your development team to have a shared, well-understood means of estimating user stories is imperative to your project success. It allows the user stories to be achievable — they are not too big/complex. It gives your dev team a common language to communicate with you, especially if you are the Product Owner. It allows you to convey to stakeholders exactly what work will be done by the end of the sprint and allow releases to more smoothly happen.
