This is an old revision of the document!
Table of Contents
What Can We Do To Improve Our Point Based Estimates?
Or “How do we improve our point based estimates and resultant velocity?”
Backgound
We focus on making story points a true measure of the relative size of the work, and velocity as the true capacity of the team to complete requirements to done.
Most organizations settle on a team-by-team Story Point based approach to estimate work. These estimates are used to understand how much the team can deliver in a Sprint. The capacity to deliver working code, called the team velocity is determined by summing up the individual estimates of User Stories that are Done in a Sprint.
We come to rely on this information for a number of uses. For example it helps us plan and understand how teams are doing. A number of teams have reported issues in both calculating and using Story Points. The following approaches were pulled together from 2 primary sources:
- We gathered up this information from the Scrum Teams. Review of the numbers raised a number of questions. The subsequent discussion highlighted both issues and potential solutions to those issues.
- A number of teams reported that velocity in release sprints is different to production sprints which means that historical velocity cannot be easily used to determine likely release date or that defects there is a difference in the size of the story when you compare defects versus new work. Again subsequent discussion of the issue with Scrum Masters highlighted issues and potential solutions.
These pages is a summary of what was discovered on the approaches Scrum Teams have used to improve their estimation process.
What is the Purpose of Estimation?
We need to remind ourselves why it is we estimate. Let's face it, estimation is mostly about planning and forecasting. There is a huge amount of baggage in most organizations associated with the process of estimation. There are also legitimate questions the business has:
- When we will get this capability?
- How much will it cost to get this capability?
- Are we making progress to delivering this capability?
- What capabilities are coming up?
From the business perspective, the main reason for estimates is to provide data to the business (through the Product Owner / Manager) to understand, manage, and forecast plans. They are trying to make sure that, for a given capacity for the organization (enterprise, program, or team), we make trade-off decisions about how to best use that capacity based on the strategy we have and the need for self-investment, and then understand progress against these decisions. A secondary reason is to help the organization understand their capacity so they do not over-commit; so they can establish a sustainable pace.
Agile requires that we provide the business (through the Product Owner / Product Manager) with good enough data, that we work to improve the estimates when they do not provide the data required. In other words, when we say “make estimation work” what we mean is that the business can easily plan using the estimates and velocity and can make informed business decisions. If the business cannot make it work, it is up to the team / team-of-teams to help fix the problem.
The agile approach to estimation stresses speed, full team involvement, and information that is accurate enough for the purpose intended, not pure precision. This is aimed at reducing the burden of estimation, while still providing the data needed.
Want to Know More?
What Are the Characteristics of a Good Estimate?
Estimates need to reflect reality. Some basic characteristics of what we need from estimates include:
- The estimates consistently reflect the capacity of the Team to deliver.
- The estimates consistently reflect the size of the work no matter what kind of work it is. For example, it should not matter that we are estimating a new feature or defects.
- They are truly relative in that, on a Team by Team basis, an 8 is an 8, and an 8 is about 4 times a 2 no matter the source.
- Estimation data allows the use of ranges of estimates to help understand the risk profile of the work. A simple example of this is when the Product Owner uses best, average and worst velocities to understand what is likely to happen with their plan.
It is worth saying again:
The estimates consistently reflect the capacity of the Team to deliver.
They must be based on reality.
What is the Basis of Our Estimating Process?
The basis of the estimating process is “Team based relative size estimates” or “Story Point estimation” to estimate User Stories (the need). This means:
- We do relative size estimates (how big something is in relation to something else), not duration estimates (how long something takes).
- We use a team based approach to estimation such as planning poker or affinity (or triangulation) estimation
- We have the people (in other words “the Team”) doing the work doing the estimates
- We use the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) for estimating
- All data we collect can and should be used to understand what and how we are doing so that we can get better.
- The estimation process is refined. Estimations are revisited to see if they are accurate and precise enough.
Relative Estimates
If two work items are the same size, should they always have the same estimate?
It is worth delving into the notion of a relative size estimate for a moment. Most traditional estimates are based on duration (“it will take about 20 hours”), and that leads to a whole bunch of problems (see What Are The Problems with Estimation? for more information). But it is worse than that. If you have two pieces of work to do, both of which you think will take about 20 hours to complete, but the first piece of work is straight forward, while the second is in an area where there is a traditionally a lot of problems, should these items have the same estimate? No, you'll probably want to put some level of buffer in place to offer a more realistic estimate for the second piece of work. This is another reason to move away from pure, absolute time based estimates.
One thing that often confuses people who are used to traditional task based estimates is that the resultant estimate is a Team's view of how big this item is. When we say the estimate is a “3”, we are really saying that the Team's view of this piece of work is that it is a “3”. In particular, it is not a single Team member's view. When starting, many Teams fall into the trap of saying “There are design, implementation, and testing components of this piece of work. George will do the design so what do you think the estimate is for the design piece … Jenny will implement, so what do you think the estimate for the implementation piece is …” and then just sum up the results. In Agile the unit of execution is the “Team” and so the estimates indicate the size of work for the Team not the individuals on the Team. Sure the time to “design” and “implement” are part of that. But to deliver the value represented by the Story the Team might, for example, want to pair implementation and testing as they do the design to improve the design. Or the Team might find that testing might need an “all hands on deck” approach to assure quality. What we are estimating is the Team's ability to deliver value.
In Agile the unit of execution is the “Team” and so the estimates indicate the size of work for the Team not the individuals on the Team.
For more information on the basis of the process see Planning Poker for Estimates from Mike Cohn. Affinity mapping is based on Play, Pass, or Move approach.
Want to Know More?
What Estimation Practices Can We Try?
Here is a list, in no particular order of things that someone has tried or suggested as a way of improving something about the estimation process:
~~LINKBACK~~ ~~DISCUSSION~~