A question that comes up frequently in Scrum training is “How do you estimate in Agile and what do Story Points represent?”
In this article I am going to talk about estimation and story points to defuse some myths and give you some practical guidance on how to estimate. I’ll start by sharing five main points:
#1: We do not estimate time
When we look at user stories and we want to come up with an estimate, how big or how small that user story is, how many points it is, we are not talking about time. It’s not about how many days it’s going to take, how many hours it’s going to take, or how many man-hours. That’s all time, we don’t do that.
Instead, when we estimate, we estimate the effort, the amount of work, the complexity, the knowledge or the uncertainty or the combination of all of this that we are going to face when we do the work. Estimates are about the effort, the size of the work item, not the time that it takes.
The level of effort can be expressed as a combination of:
- Amount of work
- Knowledge (do we know how to do the work?)
- Uncertainty (do we have all the necessary info about the work?)
#2: We use relative estimation
What are relative estimates? We start by establishing a baseline: typically we can find the smallest work item in our backlog and we can just call it our baseline and assign it one point. Notice that it doesn’t matter how long it would take to complete it (it’s time). We just know it’s the smallest work item (based on amount of effort) and we call it one point.
Then we are going to compare every other item or user story in the backlog, compared to the baseline (which we established at 1 points before). If the work item or user story has the same level of effort as the baseline then we call it one point. If it is two times the effort of the baseline, two points. If it is five times the effort of the baseline five points. And so on.
So that’s is relative estimation compared to a baseline. And the points basically represent the relative scale compared to the baseline (1x, 2x, 3x, 5x, etc.)
Why we do that? Because this is typically faster and leads to smaller errors in accuracy than if we used absolute estimation (trying to estimate each item on its own without having a baseline as reference at all.)
The baseline is also a sort of a mental anchor. Everybody, every team member, every team over time will develop their own mental anchor for what one point really is. How much work, how much effort is one point. Once you have the baseline, again, you can use relative estimation.
#3: Estimates are wrong
Estimates are always going to be wrong. They’re not exact measures. They are predictions of how much effort it will take us to complete the work when we will do it. Because they’re always in the future, they will be wrong (we can try to make them less wrong with practice, but they still remain wrong).
If we know that they will be wrong, why stress about it? Why argue who is “more right” about an estimate, or who has more experience in doing the work (and presumably, they would be “better” at the estimation of that work)? The estimates are going to be wrong anyway.
So the goal here is to develop a good understanding of what is the work, how much work is there for us to do, what is the level of complexity, the level of knowledge that we have, the level of uncertainty that we may face when we do this work. Once everyone is on the same page in terms of understanding the effort required to do the work, then everybody on the team is going to provide their estimate. And very likely, everybody will have a different idea of what the estimate is.
That’s fine (everyone is right in their own way, and everyone is wrong anyway).
We take the average of the different estimates, and that’s going to be the estimate for the work item. Is the average the right estimate? Of course not, is going to be wrong, but everybody else is also going to be wrong. It doesn’t matter who is an expert, who is not an expert, who has done the work before, who has never done the work before. We all estimate (all the members of the team) and we take the average.
Over time the team will develop that mental anchor I was talking about. A team will develop a more consistent understanding of what one point really is, what five points really are and so on. Over time, the individual estimates will tend to converge as the team develops a shared understanding. And also, the average tends to become more accurate (as measured compared to the error with the “real” effort required to do the work).
#4: How do we represent the estimates in Agile?
There are different ways to represent the estimates. One very intuitive way is to use T-shirt sizing: extra small, small, medium, large, extra large. It’s intuitive, and everybody gets what they mean.
However, it doesn’t allow a team to establish a velocity for the team because the t-shirt sizes cannot be added on top of each other. Because of this limitation, many teams use story points instead.
What are story points? They are just numbers. They are relative numbers, relative estimates between a baseline and the user story you’re trying to estimate. Typically, they follow the Fibonacci series, which is… when you have two numbers, you add them up, and it gives you the next one and so on. And typically we round up very large numbers like 20, 40, 100.
The advantage of story points is that they are numbers, so they can be added at the end of the sprint to calculate velocity. They give you a total amount to work that the team has been able to complete and you have a past performance measure that you can use to establish capacity for the next sprint.
Story points are just numbers. They don’t represent hours, they don’t represent number of people, they don’t represent number of days. They’re just relative estimates between a baseline and the user story you’re trying to estimate. A story point number is going to tell you how much bigger that story is compared to the baseline. One time bigger, so same size. Two times bigger, three times bigger, eight times bigger, 20 times bigger than the baseline. That’s what they represent.
#5: Different techniques to do the estimating
Developers estimate, and when we say Developers we mean the team members who do the work of developing the product. They include software engineers, and also testers, designers, everybody on the team who is doing the work. We want everyone on the team to participate and estimate the user stories, so that we can hear different perspectives and different voices.
- One technique that teams often use is called Planning Poker. Everybody pulls from set of cards with all the different story point numbers and they put up a card to express their own idea for how big that work item is. Very likely different team members will show different cards, so we take the average and that becomes the estimate for the work item. Then we repeat the process to estimate the next one and so on.
- Another technique is called White Elephant. You first create a series of buckets, one bucket for each story point number you are going to use. The first person selects one work item and places it into one of the buckets (representing the estimate they feel is more accurate for them). The next person can either move the previously estimated work item to another bucket (by updating its estimate) or can select another work item and place it in one of the buckets. The process continues until all items have been estimated.