This post will tell you how you estimate on Agile projects.
The first thing to understand is that estimates are used differently.
On a predictive project:
- Estimates are absolutes, usually measured in hours, days, weeks, or months.
- Estimates are summed, taking into account dependencies between tasks, resource leveling, etc. until you have a total duration for the project. This longest path through the schedule is also your starting critical path.
- The purpose of estimating is to build a schedule, budget, and resource plan.
- Estimation is front-loaded and often estimates are only revised when a project a) starts a new stage or b) fails to meet its plan and is re-planned.
On an Agile project:
- Estimates are relative with no absolute measure (t-shirt sizes, story points, etc.)
- Estimates are not comparable across teams. Every team may estimate the same work differently based on how they apply relative sizes, and also what development standards they are working to (their “Definition of Done”)
- Estimates are primarily used for capacity planning – either to help the team bring the right amount of work into a sprint during sprint planning, or for release planning or road-mapping.
- Estimates can also be used to size a whole project as part of business casing.
- Estimation is a regular event.
How much estimating is enough?
As much as you have to and no more. No matter how many hours you put into estimating, your estimates will still be estimates, and they will never be 100% accurate. In fact, based on real world evidence from Todd Little and Tom DeMarco, your estimates will usually not be right even 50% of the time!
When do I estimate?
Agile started in the product development space, not the project space, and this impacts a lot of discussion around planning and estimation.
If you are running as a funded product development team, or as part of a fully funded value-stream (which is common in SAFe scaled Agile) then estimation is really just about capacity planning. You want to ensure you don’t bring too much work into a sprint, and you want to roughly forecast how much work a team might get through during a funding period.
Some product-based teams simply don’t estimate at all. They may simply count how many stories they generally get through in a sprint. For this to work their level of Agile maturity is usually pretty high and stories are small and uniform enough that this simple approach is sufficient. There’s parts of the Agile community that are anti-estimation or even anti-project (just google “#noestimates” or “#noprojects”).
If you are a project and do have to justify your funding then estimation is still a “thing”. Likewise, if you are managing a portfolio, then estimates provide useful input into that process. If you are managing a portfolio, you should also have a look at Cost of Delay as that is one of the best ways of prioritising work.
Estimates are also useful on an ongoing basis to progressively manage capacity as you learn more about what you are building.
What on earth are story points?
The easiest and most common form of estimating uses story points. Story points are based on the Fibonacci scale. The normal scale is a progression where each number is the sum of the previous two numbers. Agile teams use a slightly modified scale: 1, 2, 3, 5, 8, 13, 20, 40, 60, 100 where the larger numbers are used to show big areas of scope that are currently not well understood.
As you can see from the diagram below where the size of each box is sized precisely relative to other boxes, something that is 2 points is very different in scale from something that is 13 points or 21 points. Even an 8 point story is enormous in comparison to a 2 point story.
The most important aspect of the Fibonacci scale is that it is used to control for risk and uncertainty.
A piece of work sized at 3 story points is quite manageable and most teams would deliver a 3-pointer in a few days. However a 13-pointer is massive, and generally its not advised for a team to bring a piece of work this large into a sprint. It is simply too large and contains too much risk.
You can think of your Backlog (an Agile Product Breakdown Structure) as a mix of different sized pieces of work, where you are continually taking smaller pieces out to do, breaking down bigger pieces as you learn more. All work that is currently understood part of the project is sized, be it a fairly accurate 2 points, or a best guess 21 points.
Work gets done in priority order, and you are continually using what you learn through delivery to refine future pieces of work, adding and removing work as you go. Progress is typically shown through a Burn-up or Burn-down.
Because estimates are relative you don’t need to constantly readjust a plan.
If a 5-pointer took three days, you can just work with a heuristic that says an 8-pointer will probably take about a week (or 8/5*3 days if you want to be really picky). You can use this value for all your 5-point stories, that’s the benefit of relative estimation. By the same token a 13-pointer is likely to be in the region of two weeks ( or 7.8 days to be precise).
Story points estimates are not supposed to be accurate. The whole purpose of story points is to control for likely variation in duration of tasks through the “risk premium” attached to larger stories.
The team can use its average velocity (the average number of points it has done in the last three sprints) to determine how much work it takes into the next sprint, and the simplest way to forecast end date is a calculation of points remaining divided by average velocity.
So what happens if there is more work than I have time or budget for?
There will always be more work than you have time or budget for, just as requirements will change through the project no matter how much time you spend collecting them.
The advantage of an Agile approach is that work is cut in such a way that your client will always have something that delivers value, and you deliver the most important requirements first. So, when you get to that inevitable point in the project where time and money is running short, its a much easier conversation.
This is a complex area and will be the subject of a later post.
Great, so how do I estimate?
Two commonly used techniques are Planning Poker and Relative Estimation.
Planning Poker is a structured process that is useful for getting everyone’s opinion about the size of a piece of work without group-think.
- The Product Owner or customer will read out a story to the team
- The team will then ask any clarifying questions required
- Then all team members choose a card with the number of points they estimate and place it on the table at the same time
- If there are differences in estimates team members discuss their reason, especially if their estimate was particularly high or particularly low
- The team then repeats the process until consensus is reached
Relative Estimation also uses a Fibonacci scale, but is conducted differently:
- A story is sized quickly in relation to a story the team has recently completed, the basic question being “is this bigger or smaller than my reference story?”. This can be done using planning poker cards, or simply through discussion
- Usually you’d use something recent that was a 3-pointer or 5-pointer as a reference story as most stories will be within an order of magnitude of this
- If the team is brand new and doesn’t have reference stories you can use bucket estimation to get the relativities of one or more sprints worth of stories, where it is simply ordering them smallest to largest, and then assigning them to roughly ‘good enough’ sizing buckets.
- The advantage of relative sizing over planning poker is that it is much faster. You could bucket size a large number of stories, or even a project, in half a day to a day with the team.
Never waste more time than you need to on estimation. Remember an estimate will never be 100% accurate, no matter how long you spend estimating. Knowledge comes from doing.
Its the process of working together as a team and establishing over time what an 8-pointer means in your context (your way of working, your constraints, toolsets, etc.). After this, the teams average velocity over time gives you a reasonable ability to forecast.