Estimation
Introduction
"It is better to be roughly right than precisely wrong."
-- John Maynard Keynes
Accurately estimating the time and effort required to complete a task is one of the hardest things to do as a developer. Everyone has experienced a task where their initial estimate was way off. Sometimes everything goes smoothly and you finish early. Other times, you run into some obscure issue that has you searching Stack Overflow for hours on end and setting up meetings with senior developers to get help. Sometimes you might even finish the implementation only to find out that your solution can't scale to the require data volume and you have to start over.
In practice, consistently accurate estimates just don't happen. There are too many unknowns and too many variables that can change. However, that doesn't mean that estimation is useless. Estimation is still a valuable tool for planning and prioritizing work. It helps teams set expectations and communicate progress. It also helps identify when a task is taking longer than expected so that the team can adjust and find a solution.
Estimation is often unavoidable. Clients want to know how long a project will take and how much it will cost. Managers need to plan resources and set deadlines. Developers need to know how much time to allocate to a task. While estimation is never perfect, it is still a valuable tool for planning and prioritizing work. Even a rough estimate is better than no estimate at all, and there are many methods that can help improve the accuracy of estimates.
Estimate Accuracy
Estimates are never perfect. Even the best developers will be wrong more often than they are right. So why is it so hard to estimate accurately? There are many reasons:
- Unknowns: There are always unknowns when starting a new task. You might not know the full requirements, the best approach, or the potential pitfalls. You might not know how long it will take to debug an issue or how long it will take to test a feature.
- Dependencies: Tasks are rarely isolated. They often depend on other tasks being completed first. If one task takes longer than expected, it can throw off the entire schedule.
- Complexity: Some tasks are more complex than others. They might require more research, more testing, or more collaboration with other team members. The more complex a task is, the harder it is to estimate.
- Optimism: Developers are often optimistic about how long a task will take. They might underestimate the time required to complete a task or overestimate their own abilities. This can lead to overly optimistic estimates that are hard to meet.
- External Factors: There are many external factors that can affect how long a task takes. You might get pulled into a meeting, have to deal with an urgent bug, or get interrupted by a colleague.
- Scope Creep: Requirements can change over time. What starts as a simple task can quickly grow in complexity as new requirements are added. Scope creep can make it hard to estimate how long a task will take.
- Pressure: Developers are often under pressure to meet deadlines. They might feel pressured to give an estimate that is shorter than they think is realistic, or to pad their estimate to give themselves some breathing room.
Every task we face as a developer is unique. We're never solving the same problem twice. This makes it hard to estimate how long a task will take.
I'm sure you've run into this with your own projects. You start out with a rough estimate of how long a task will take. Then you run into some issue or dependency that you didn't anticipate. You end up spending hours or days where you seem to make no progress at all. Your original estimate is totally off, and you're left scrambling to meet a deadline. In other cases you might finish a task early and wonder why you ever thought it would take so long.
Cone of Uncertainty
There is a concept in project management called the "Cone of Uncertainty", originally described by Steve McConnell in his book Rapid Development. The cone represents the range of possible estimates for a task at different stages of the project. As you move from the start of a project to the end, the cone narrows, and the estimate becomes more accurate. At the start of a project, the cone is wide, and the estimate is uncertain. As you gather more information and make progress on the project, the cone narrows, and the estimate becomes more accurate.
If we try to estimate a task at the start of a project, we are likely to be wrong. The error in our estimate is likely to be large, off by a factor of as much as 4x. As we make progress on the project and gather more information, our estimate becomes more accurate. The error in our estimate decreases, and we are more likely to be right.
To help mitigate this, we focus on breaking down tasks into smaller, more manageable pieces and short time frames. This allows us to gather more information and make progress on the project, which in turn helps us make more accurate estimates.
An amusing variant of the Cone of Uncertainty is the "Wormhole of Reality". Our estimates never really converge to accurate values. Instead I've found that estimates near the end of a project are less accurate than ones near the middle.
As we get closer to the end of the project, we start to uncover subtle bugs, edge cases, and performance issues that we didn't anticipate. No matter how well we think we understand the requirements, there are always surprises waiting for us that won't be uncovered until we have real data to work with.
Relative Estimation
One way to improve the accuracy of estimates is to use relative estimation. Instead of estimating how long a task will take in hours or days, you estimate how long it will take relative to other tasks. For example, you might estimate that one task is twice as complex as another task, or that one task is half as complex as another task. This can help you make more accurate estimates by comparing tasks to each other and using that comparison to guide your estimate.
This has the added benefit of making it easier to estimate tasks that are very different from each other. It also consistently provides a more accurate estimate than trying to estimate tasks in hours or days.
Rules For Estimation
There are a few rules that can help improve the accuracy of estimates:
- Speed Over Precision: It's better to be roughly right than precisely wrong. Don't spend too much time trying to come up with a perfect estimate. Instead, focus on getting a rough estimate quickly and adjusting it as you gather more information. Keep in mind that the estimate itself doesn't bring any value to the project, it's the work that does.
- Use Collaborative Techniques: Estimation is more accurate when done collaboratively. Get input from other team members, especially those with more experience. Start with a range of estimates and work towards a consensus.
- Use Relative Units: Avoid using real time units like hours or days. Estimates are more accurate when done by comparing tasks against each other. The relative complexity is easier, more accurate, and just as useful.
Assigning Estimates
The exact approach for assigning estimates will vary depending on the team and the project. The exact values used are less important than the process of assigning them. The goal is to get a rough idea of how long a task will take and to use that estimate to plan and prioritize work.
This estimate should be a collaborative task. It should involve the entire team, not just the developer working on the task. A common approach is to have each team member assign an estimate independently and then discuss the differences. This can help identify any misunderstandings or unknowns and lead to a more accurate estimate. Avoid arguing over the exact value of an estimate, whether something is a 3 or a 5 is less important than the fact that it's more complex than a 1. Just assign a value and move on.
If someone has a much lower estimate than the rest of the team, it might be a sign that they have misunderstood the task or perhaps have expertise that the rest of the team doesn't. If someone has a much higher estimate, it might be a sign that they are overly pessimistic or that they have identified a potential issue that the rest of the team hasn't. In either case, it's worth discussing the differences and trying to come to a consensus.
As for the values assigned, there are many different approaches. Some teams use story points, others use t-shirt sizing, and others use hours.
Story Points
Story points are the most common approach to assigning estimates in Agile development. Story points are a relative measure of the complexity of a task. They are not tied to any specific unit of time, like hours or days. Instead, they are used to compare tasks against each other and to help the team plan and prioritize work.
Story points are usually assigned using a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.). This is based on the idea that difference in difficulty is relative. After the first few numbers, the next number is about 60% larger than the previous one. Ensuring that the perceived difference in difficulty is consistent.
Weber's Law states that the difference in difficulty between two tasks is perceived as the same if the ratio of their difficulties is the same. Consider two visually identical objects, one weighing 1 kg and the other weighing 2 kg. It would be able to easily tell the difference between the two. Based on this, we might assume that differences of 1 kg are easy to tell apart. However, if we compare a 20 kg object to a 21 kg object, the heavier object is much harder to identify.
Story points are assigned based on the relative complexity of a task compared to other tasks in the backlog. When first adopting story points, the team will need to establish a baseline. This is usually done by assigning a value to a few tasks that are representative of the work the team does. Once the baseline is established, the team can use it to assign story points to new tasks.
The team will then track how many story points they complete in each sprint. This can help them estimate how many story points they can complete in future sprints and how long it will take to complete the project.
T-Shirt Sizing
T-shirt sizing is another common approach to assigning estimates. It is similar to story points in that it is a relative measure of the complexity of a task. However, instead of using a Fibonacci sequence, it uses t-shirt sizes (XS, S, M, L, XL, XXL, etc.).
It is often used by teams that are new to Agile development or that find story points too rigid. It is a simpler approach that can be easier to understand and use. The sizes are difficult to map to time units, which can actually be a benefit. It forces the team to focus on the relative complexity of a task rather than trying to map it to a specific amount of time.
I found t-shirt sizing to be a bit too vague for my liking. It's hard to compare tasks that are very different from each other. It's also harder to track progress and estimate how long a project will take.
Hours
Some teams persist in using real time units like hours or days to assign estimates. This tends to lead to pointlessly precise estimates that are no more accurate than story points or t-shirt sizing. It also makes it harder to compare tasks against each other and to track progress.
I would recommend avoiding this approach. It's better to use story points or t-shirt sizing to assign estimates. The estimates are just as helpful for planning and prioritizing work, and they tend to be more accurate and easier to use.
You should also avoid the temptation to map story points or t-shirt sizes to hours. This defeats the purpose of using them. They are meant to be a relative measure of complexity, not a precise measure of time.
Conclusion
Accurately estimating a task is extremely hard. So hard, in fact, that it's almost impossible. There are too many unknowns and too many variables that can change. However, that doesn't mean that estimation is useless. It is still a valuable tool for planning and prioritizing work. It helps teams set expectations and communicate progress. It also helps identify when a task is taking longer than expected so that the team can adjust and find a solution.
When I was first starting out as a developer, I struggled a lot with estimation. I wasn't used to creating estimates, and I didn't have enough experience to understand the sorts of issues that could come up. As a result my estimates were often way off. I would often underestimate how long a task would take and end up working late to meet a deadline.
I used two main tactics to improve my estimation skills. First, I focused on breaking down tasks into smaller, more manageable pieces and short time frames. Shorter tasks are easier to estimate and track, and they help you gather more information and make progress on the project. Second, I spent time tracking how long tasks took and comparing them to my estimates. This helped me identify where I was going wrong and refine my estimates based on that feedback.