Agile estimation
Agile estimation is a way of buying knowledge (cost, time, scope, and so on). All estimating has a cost, not only in terms of the actual time spent estimating, but also in the form of time not spent building new features. But if having the additional knowledge will lead to better decisions, then the investment in acquiring that knowledge is a good thing to do.
When does estimation happen in Scrum?
Scrum teams create estimates at two different times and at two different levels. One time when teams estimate is in sprint planning, when they estimate at the sprint backlog level. Estimates for the sprint backlog are absolute and expressed in time.
A second time when teams estimate is during a story-writing workshop or during regular product backlog refinement meeting when they are estimating at the product backlog level. Product backlog estimates are relative and expressed in an abstract unit.
Why do teams estimate the product backlog?
Estimating the product backlog is an integral part of planning agile projects. Agile teams estimate the product backlog for at least four reasons:
- To create credibility with stakeholders,
- To ensure teams stop and think about how to solve the problems put forth in the product backlog,
- To help product owners prioritize, and
- To give organizations insights about delivery that they need to make decisions and to plan.
Do agile projects have to estimate?
Though estimation isn’t required on agile projects, it’s rare when a project doesn’t benefit from at least some estimation.
Too many teams bog down in estimation and spend too much time estimating, trying to arrive at perfect estimates. It’s helpful to remind teams that the estimates agile teams assign to product backlog items only must be accurate enough that
- The product backlog can be prioritized. It is impossible to fully prioritize a set of items without knowing at least their relative cost
- The business can make high-level forecasts about how much will be done by when
- The business can make tradeoff decisions between scope and schedule
Teams typically can achieve these goals at the product backlog level with approximate, relative estimates.
Relative estimation & product backlogs
Relative estimation is a way of gauging the size of something by comparing it against another, similar item. Relative estimating removes questions of differing skills or experience from the estimation equation.
For example, two people might have different answers when asked how long it would take each of them to run a certain distance. But both can agree they would each take twice as long to run a longer distance uphill.
The same goes for the work needed to do a certain task by your most-experienced team member versus your newest one. They might both complete the tasks at different rates, but they can agree that certain work would take either of them twice as long as another.
Relative estimation is also helpful because people struggle to estimate work they haven’t done before. With relative estimation, a team doesn’t have to precisely estimate how long a given product backlog item will take. Instead, the team only has to match it to other similarly sized items.
For example, I am considering buying a new car this weekend. I know I can get a Toyota or Honda for a reasonable cost, I don’t know exactly how much they are, but I’d classify them as moderate. A Ferrari is much more expensive, I’d classify it as opulent!
Because I'm planning to spend a moderate amount of money, I don’t need to know the precise cost of the Honda to put it on my short list of cars. I also don’t need to know the exact cost of the Ferrari to know I won’t be considering it far exceeds my budget range.
I only have to be able to decide, “Does this car belong in a moderate bucket with Hondas and Toyotas? In a luxury bucket with Mercedes and BMWs? Or perhaps with a Ferrari and Lamborghini in the opulent bucket?”
Relative estimation saves time by removing the pressure to be perfect or overly precise. Removing pressure also helps engage team members in the process.
Estimating with story points
Estimating with story points is one of the most popular methods for agile estimation.
Story points are used to estimate the product backlog. Story points can inform velocity-driven sprint planning but story points are not a useful unit for estimating tasks during capacity-driven sprint planning.
Unlike traditional estimation methods, which try to guess the absolute time an item might take, story points estimate relative effort.
Effort is essentially the person-days (or hours) required to do something. In this way, effort is about time—how long it will take to do something.
To arrive at a relative effort estimate, this information is then compared against existing estimates, either a sample story or one the team has worked on in the past: Is the effort to deliver this piece of work about the same as a set of similar stories. Is it bigger? Twice as big? Four times as big? Is it smaller? Half the size? Even smaller?
3 factors to consider when estimating relative effort
Teams consider three factors when arriving at relative estimates of effort: 1) the amount of work to do, 2) the complexity of the work, and 3) how much risk and uncertainty is associated with that work. Let’s look at an example of relative estimation with story points, and how each of these factors might affect our estimate.
1. Amount of work
Suppose you and I are to walk to a building. We agree that it will take 1 walking point to get there. That doesn’t mean 1 minute, 1 mile, or even 1 kilometer. We just call it 1 walking point. We could have called it 2, 5, 10, or a million, but let’s call it 1.
What’s nice about calling this 1 walking point is that you and I can agree on that estimate, even though you are going to walk there while I hobble over there on crutches. Clearly you can get there much faster than I can. Yet using walking points, we can agree to call it 1 point. The amount of work to do is the same for both of us, even if we would do it at much different speeds.
Next, we point to another building and agree that walking to it will take 2 points. That is, we both think it will take us twice the amount of work to get to the other building as to the first building.
2. Complexity
Let’s add a third building. This building is physically the same distance as the 2-point building. So we are tempted to call it a 2. However, separating us from that building is a narrow walkway across a deep chasm filled with boiling lava. The walkway is just wide enough that we can traverse it if we’re extremely careful. But—one misstep, and we fall into the lava.
Even though this third building is the same physical distance as the building we previously estimated as 2 walking points, we decide to put a higher estimate on walking to this building because of the extra complexity in getting to it. We give it 4 walking points.
The higher estimate reflects the fact that either of us would have to walk more slowly and deliberately across that walkway to avoid falling into the lava. We account how long it will take in terms of both the amount of work and also the extra complexity.
Complexity influences an estimate, but only to the extent that extra complexity affects the effort involved in doing the work. Walking to the 1-point building while singing “Gangnam Style” is probably more complex that walking there without singing. But the extra complexity of singing won’t affect the amount of time it takes me to walk there, so my estimate in this case would remain 1.
3. Risk and uncertainty
Risk and uncertainty affect estimates similarly. Suppose a fourth building is also physically the same distance as the building we called a 2. But in walking to that building we must cross some train tracks. And the train crosses at completely unpredictable times.
There is extra uncertainty in walking to that building—sometimes we get there in 2 points. Other times we get stuck waiting for the train to pass and it takes longer. On average, we might decide to estimate this building as a 3.
So, story points are about effort—the time required to do something. Risk, uncertainty, and complexity are factors that may influence the effort involved.
Not only is relative estimating more accurate, teams can do it more quickly. With relative estimating, the team does not need to think of all of the sub-steps, then estimate each, and then add them up. They only need to find something similar and use the same estimate.
Agile story points scale
Relative estimating techniques use a scale of numbers that reinforces the abstract nature of the estimates. An example story point scale might be a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20) or a simple doubling of numbers (1, 2, 4, 8, 16, 32…). These numbers work for two reasons: they are not overly precise and they are just far enough apart to be distinct (Weber’s law).
In essence, Weber’s Law states that we only notice a difference when it reaches a certain percentage: the just-noticeable difference. A light bulb doesn’t appear brighter to humans until it is about twice as bright. In the same way, the difference in two object’s weight isn’t discernable until it reaches a certain threshold.
Both the Fibonacci series and doubling are effective estimation scales because the difference between the numbers is just enough to be noticeable. Weber’s law doesn’t hold up at the extremes, which is why 40 and 100 work as story point estimates as well.
The modified Fibonacci sequence that we recommend came about because some estimates, like 21, implied a precision that the team didn’t intend. Stakeholders saw an estimate of 21 and were impressed that it was exactly 21, rather than being rounded to 20 or even 25. When we stopped estimating items as 21 and used 20 instead, stakeholders no longer had that mistaken assumption.
Who, when & how to estimate user stories
To understand how to estimate user stories, it’s helpful to understand three factors related to agile estimating.
- First, teams need to know who should be involved in agile estimation at the product backlog level.
- Next, teams need to know when to estimate the user stories in the product backlog.
- And last, teams need to know how to use story points in a way that ensures every voice is heard.
Who estimates the product backlog in Scrum?
The entire team is encouraged to be involved in story point estimation. That includes the Scrum master, product owner, and developers (team members). Neither the Scrum Master nor product owner should estimate, but they should participate to facilitate discussions and answer questions about the items being estimated.
Sometimes it isn’t possible or practical for every developer to attend (maybe they’re busy with the work of the sprint or maybe the team hasn’t even been formed yet). In those cases, it’s OK to estimate with a subset of the people doing the work. If the team doesn’t exist yet, use a group of people who understand the work well enough to estimate it.
When do agile teams estimate the product backlog?
Agile and Scrum teams estimate the product backlog at two general times in a product’s lifecycle.
The first is following a story-writing workshop, during which team members and stakeholders brainstorm product backlog items to be worked on in the coming period—typically a quarter. The backlog items are typically written in the form of user stories or job stories. (It’s a good idea to include developers when writing stories for the product backlog.)
The team will then estimate just enough of the high-priority product backlog items for decisions to be made. These decisions might concern feasibility, timing, capacity, or all three. Teams estimate in order to answer questions like:
- Is this product feasible? (Will it take too long or cost too much?)
- How much of the product can be delivered by a certain date?
- How many teams do we need to put on this product to ensure it is complete by a certain date?
- What does a MVP look like and how soon could we have it?
The second occasion for agile teams to estimate is as emergent requirements are added to the backlog or as big stories bubble up in priority to be refined and split. This ongoing product backlog maintenance is commonly called product backlog refinement. Refinement happens about once per sprint but some teams do it weekly.
During product backlog refinement, the product owner identifies a set of new or upcoming work that needs to be completed in order to achieve the goals of a product or feature. The team asks questions, splits the work into smaller chunks as needed, and estimates the work compared to known work they’ve already accomplished or to a set of baseline stories.
How do we estimate with story points?
Estimating with story points involves assigning numerical values to stories. Story points allow teams to estimate in relative terms rather than absolute terms. Instead of saying, “This will take five days,” say, “This thing will take about as long as that thing.”
Story points reflect the effort (how long it will take) of completing a particular story, considering the amount of work, the complexity, and the risk or uncertainty involved. Try to keep most estimates, or at least the most important estimates, within about one order of magnitude, such as from 1 to 10. Studies have shown that people estimate best within one order of magnitude.
When estimating a new product backlog (or when multiple teams are working on the same project), it helps to establish a few baseline stories. When estimating an existing backlog, the team can use any of the already-estimated stories for comparison (or in the case of a multi-team project, continue to use the baseline stories).
How to establish baseline stories
Here’s one way to establish baseline stories:
- Start with a 2-point story, one that everyone can agree is small but is not the smallest possible story
- Then find a story that is about twice as big and that team members can agree to call a 5.
Maybe the team doesn’t find good 2- and 5-point stories, but instead finds good 3- and 8-point stories. That’s fine. You want merely to find a pair of stories that span the one order of magnitude that will contain most estimates.
With these initial estimates established, team members can then estimate other items relative to these. Is it smaller? How much smaller? Bigger? How much bigger?
Once the high-priority items are estimated, the team can begin to predict a range of work that can be completed by a certain date. They do this by considering their historic velocity, a range based on the average number of stories a team can complete in an iteration. (This is a general definition. Take time to understand precisely what velocity means for your team.) Since velocity can vary from iteration to iteration, try to look at data from at least five iterations to get a range.
Estimating with planning poker
One fun and engaging way to do this and ensure everyone’s voice is heard is by playing Planning Poker®. The team can use a virtual tool or physical card set for this. Or the team members can just hold up the number of fingers, type a number into a chat window, or find some other way of silently communicating their estimate when prompted.
The product owner starts by reading a user story and answering any questions about it. The answers to these questions might become the acceptance criteria (conditions of satisfaction) for the story. (Splitting stories and adding acceptance criteria are two ways to add details to a story.)
Then all the team members choose a story point estimate that matches the effort involved in delivering the story. All at once, team members reveal their estimates.
If all the estimates match, the number is placed on the story and the team moves on. If the estimates do not match, the team discusses the high and low estimates. They look at the high number to uncover hidden risks, uncertainty, complexity, or work that the other team members might not have considered. They look at the low number to uncover shortcuts or approaches that might help reduce the effort involved.
Then the team members once again choose their estimates. This process continues until the team reaches consensus on a story-point estimate.
Estimating can be difficult, but it doesn’t have to be onerous, contentious, and exhausting. We offer resources and training that can help.
Agile estimating presentation & video
Do you worry that agile projects won't allow for the detailed planning and estimation your business requires? Does your team fear estimates because the numbers might come back to haunt them?
You need to know how agile estimating works and whether the plan's result will be something your team and your business can trust.
In this presentation, agile planning expert Mike Cohn explains how to create useful estimates that teams are comfortable with and management can rely on for decision-making. Explore story points, ideal days, and how to estimate with Planning Poker. Leave with new insight into both short–term iteration and long–term release planning.
Download a PDF Watch the Presentation
Recommended Resources
