My company is still very much in its Agile infancy, and we still have a lot of questions and confusion around project planning and estimation. I originally put this post together for our knowledge base so there are some fairly specific statements, but I thought it was generic enough to send out in to the wild for feedback. What are your thoughts? How do your Agile teams use Story Points? What other estimation techniques do you use?
Story Points are used to rate the size and/or complexity of work relatively (rather than exactly) within a project. They are a very common tool used in Agile project estimation.
Why Story Points?
Humans are not very good at estimating things in exact, quantitative terms. Asking someone How long will it take? is essentially asking them to predict the future (which most of us are also not very good at). Typically, such quantitative questions are very difficult to answer; however, humans are very good at estimating things relatively (or qualitatively). Estimating with Story Points gives us the ability to separate the size (qualitative) of the work from the duration (quantitative).
If you presented me with a list of animals (say a lion, mouse, dog, and elephant) and asked me how tall each one is, I’d have to ask a bunch of questions:
- A male or female elephant?
- African or Indian elephant?
- Adult/adolescent/child lion?
- Do you want that in feet, meters, inches, miles, hands, …?
- What breed of dog?
Even if you answer all these, I highly doubt I know the average height in millimeters of an adult male African elephant off the top of my head, so I’d have to make my best guess (because in this scenario, Google doesn’t exist (ohcrap)). Then I can probably use that guess to estimate the heights of the other animals. But then what if my initial guess for the elephant was wrong? That might completely throw off all my other estimates, and I’d have to go re-estimate all the other animals as well.
That’s a lot of work to get you an answer to a seemingly simple question!
Conversely, if you present me with the same list of animals and simply ask me to rate them by height, I can very easily come up with:
Elephant > Lion > Dog > Mouse
I don’t have to ask any of the questions I did previously, and I (probably) don’t even have to ask Google. You’ve got an almost immediate answer of how these objects relate to each other.
Story Points give us that same simplistic capability of ranking work relatively rather than assigning it an exact value.
Story Points Don’t Tell the Whole Story
Alright, great – it’s very easy for us to size things relatively, but customers don’t ask “how big is this project?” or “how complex is this task?” They want to know How long will it take? (which of course they’re actually translating one step further to How much will it cost?) Velocity is the concept that lets us derive duration from size. A team’s Velocity is the measurement of how much work (Story Points) they can complete in a certain period of time. To answer the client’s primary question of How long will it take?, we first estimate the project’s total scope in Story Points, then we estimate the team’s Velocity in Story Points per
x can be any unit of time. This is usually a Sprint or Iteration, but could be days or weeks or months, depending on the team and project structure.
From there, we just have some very simple math (gasp) to do to derive our client’s answer. We just need the following data points:
- Total scope of the project, in Story Points
- Estimated Team Velocity
- Length of time of an “iteration”
- Total hours dedicated to the project per week
How long will this project take?
Our team estimated the entire backlog at 100 Story Points, and we estimate the team’s velocity to be 10 Story Points per Sprint, each Sprint is two weeks long, and we have five team members working full time on the project.
100 Story Points / 10 Story Points per Sprint = 10 Sprints
10 Sprints x 2 weeks per Sprint = 20 weeks
5 resources x 32 hours per week x 20 weeks = 3200 hours
We can very quickly give our client an answer of project length, in hours, that is derived from simple relative estimates. The only real SWAG that we might have here is our estimation of the team velocity, and there are plenty of strategies for estimating that fairly accurately as well; everything else is derived with logic and math.
What if we’re wrong about the size of one of our Issues? Going back to the example of animal heights, if my initial guess on the height of an elephant was wrong, but I based all my other estimates off that, I would have to go back and re-evaluate all my heights for each other animal. What if our brilliant artist finished that marketing flyer we thought was an 8 quicker than we finished most of our 2s and 3s? The short answer: it doesn’t matter! In all likelihood, some of those 3s and 5s will take longer than the others as well, and it should balance out over the life of the project. No re-estimation needed here!
What if we were wrong about Velocity? Do we have to go back and re-estimate all of our Issues? Not at all! Using Story Points, we separated the size of the project from the duration. Being wrong about the rate at which the team finishes work does not change the amount of work the team has to do. We simply re-evaluate our Velocity number and plug that back in to the math above to derive the remaining project duration.
How to Story Point
Most teams utilize a standard set of Story Point values to rate the size of the work to be done. This set can be seen in the Planning Poker deck of cards that we have. The standard values are:
We can split these values into three sets:
- Values 1 – 8 are Issue Sizes (for primary Issue types)
- Values 13 – 100 are Epic Sizes (for Epics only)
- The other values are used in specific, rarer situations
As the values increase, so does the size/complexity of the Issue we’re estimating. An Issue with a size of 2 is twice as complex as one with a size of 1. An Issue with a size of 8 is more complex than one with a size of 3. The team should strive to size their backlog relatively to the other work in the same backlog.
Note, too, that the gaps between successive values also increase, which is very significant. This indicates that the larger and larger the scope of our work gets, the more uncertainty there will be. The further to the right we move on the scale, the larger the scope of the work, so the more questions, variables, and unknowns there are. When there is that much uncertainty, it’s way too difficult to guess at the difference between say a 40 and a 42. It’s easier to illustrate or imagine the difference between 20 and 40 (twice as large!) than the difference between 99 and 100 (1% larger?).
We use the values 1 – 8 to assign sizes to primary Issues (Stories, Bugs, Improvements, etc). If the team believes that an Issue requires a larger estimate than 8, then that is a good indication that the Issue should either be upgraded to an Epic or it should be split into multiple Issues.
We use the values 13 – 100 to assign sizes specifically to Epics.
The Zero-Point Issue
Why would we rate something that requires any amount of work as a zero? Usually, the team should use the zero when they feel that the work to be done is so trivial that they do not want it to inflate their velocity. We use the team’s velocity as the baseline for Sprint commitments, so if that gets inflated unnecessarily by trivial work, we may be forcing the team into larger commitments later in the project that they cannot achieve. You typically do not have many work items that are this small, so the zero should be used sparingly.
The ? Issue
Very simply, the ? means that the team does not have enough information to size the Issue. If an Issue gets assigned a ? for an estimate, the team should either discuss further at that time, or provide the Product Owner with the questions that they need answered offline in order to provide an estimate.
The Infinity Issue
An Issue given an Infinity sizing is essentially deemed “impossible” by the team. Whether it’s due to technical limitations or the laws of physics, there is some insurmountable obstacle to the team completing this work. This should be extremely rare as it’s very hard to find completely impossible tasks, especially in the software industry. If you start seeing a lot of these in your backlog, you probably have a completely unreasonable project or an insane product owner. Seek help immediately.
How NOT to Story Point
Story Points Do Not Equal Time
Story Points should never be equated to time; they are strictly an estimate of size. Saying that “1 Story Point = 2 hours” completely de-values the Story Point. It removes the entire relative aspect of the Story Point, which is its sole purpose and primary advantage. While there may be a fairly strong correlation where the more complex tasks will take more time, Story Points to Time is never a 1:1 relationship.
Not on Sub-tasks
There is no need to put Story Points on sub-tasks. Sub-tasks are small, well-known, detailed tasks that should be small enough for the team to estimate in hours.
Totals Don’t Need to Match
If an Epic has been assigned a Story Point value, the Story Points for Issues inside the Epic do not need to add up exactly to the Epic value. It’s OK for an Epic of size 20 to contain Stories of
8 + 5 + 5 = 18 or
8 + 5 + 1 + 8 + 3 = 25.
No Partial Credit
Do not take partial credit of Story Points for an Issue that rolls across Sprints. Single primary Issues should be sized appropriately so that they can be completed in a single Sprint. If we get part of the way through an Issue that was estimated as an 8, it is too difficult to answer the question of “how much did we get done?” Was it 40%? 75%? It’s just easier to take an all-or-nothing approach. Over the course of the project, the team’s average velocity will stabilize and balance this out.