The best estimation guidance I have so far

I believe in estimation of software projects because I’ve found it works well when you do it for the right reasons. I know estimation is a controversial topic so I thought I’d add my own opinion to the chorus of voices advocating the pro side. My only disclaimer is that my experience is entirely based on startups so this may not apply to larger companies or other industries.

Relative Estimates

First and foremost I never give exact timelines in estimation. I’d rather use some abstract buckets (e.g. t-shirt sizes, points, types of hot dogs.. don’t ask..) over asking an engineer to give me a specific hour or day estimate. People are very bad at absolute estimations. If you ask someone to estimate anything, they’ll usually get it wrong unless they have very specific previous knowledge. But if you’re given relative sizes it makes it much easier to estimate.

Let’s look at an example. I live in Brooklyn and I want to estimate the length of the Brooklyn Bridge in feet. Since I have no idea how long the bridge is I’ll swag it (scientific wild-ass guess). I’ll wait while you take a shot at it. Ready? Ok so the bridge is about a mile and a mile is roughly five-thousand feet so let’s say that’s my current best estimate. Before I tell you if you’re right (no cheating by looking this up) let me give you some more information. The Brooklyn Bridge is shorter than the Williamsburg Bridge which is seven-thousand three-hundred and eight feet and it’s longer than the George Washington Bridge which is four-thousand seven-hundred and sixty feet (I’m using words rather than numbers so it doesn’t draw your eye while reading this). So now that we have a relative size let’s take another shot at this! I’ll take the average of those two bridges and guess that the Brooklyn Bridge is six-thousand and thirty-four feet. That’s much much closer! What if I told you that the Manhattan Bridge was longer than the Brooklyn Bridge but shorter than the Williamsburg Bridge? Would you guess the average which is six-thousand six-hundred and seventy-one? That’s also pretty close to the real number (see the bottom of this post for the actual numbers!). Because we have relative sizes and accurate prior knowledge, we can apply those values to our new estimates and get near accurate results.

How can you apply this to software engineering? Well Ally and Bob both built widgets last month and now Conrad needs to build a widget. Ally, Bob and Conrad all estimate the relative effort of building a third widget. Ally says it’ll be a medium task and Bob says it’ll be a large task. They talk it over and decide that given their experiences this widget should also be considered a medium task. Most medium tasks on the engineering team take 2-3 days and thus a relative timeline is communicated to the product manager, Deloris. Relatives sizes work well when looked at in aggregate. That means on average the tasks will be accurate to their estimation. Some tasks will be overestimated and some under-estimated but the roadmap timelines will ultimately be close to what happens in practice.

Scope

Our story doesn’t end with estimation. Deloris is now going to take the estimate and decide whether the value of the widget is worth the approximate estimate. Deloris also has another card to play. She’ll ask the engineering team whether there are ways to reduce scope. Ally mentions that one of the hardest parts of building a widget is the phalange (especially the left phalange which is very tricky) and without it the task would be small. Deloris agrees and the task spec is updated to reflect the new requirements. Deloris can also decide that the phalange is too important to cut. Having the trade-off made explicit is a goal of estimation. There are other ways to expose the trade-offs without estimation but with estimation it becomes a natural part of the conversation.

The Conversation

The conversation before and during the session is where estimation really shines. If the team is only going through the motions to slap a size on each task or rushing through the session because there are too many tasks to estimate then you’re missing an important part of the exercise. You can start by talking through the different parts of the task and trying to find hidden complexities that change the effort calculation but avoid trying to plan out the entire feature. It’s enough that you understand the requirements and have a sense of possible solutions rather than mentally building out the feature in the session. Planning everything out will take too long and won’t be as exhaustive as one might expect because the engineers aren’t actually sitting in front of code with the ability to try ideas and see additional issues.

Once you have a good understanding and an estimate, the product manager can actually probe the estimate with questions to see where scope can be cut or requirements can be changed to lower the estimate. It’s important that this is done collaboratively rather than accusatory so that engineers don’t feel obligated to lower their estimates against their judgement.

Commitment

Finally the act of estimation means that every engineer on the team is committing that they understand the goal of the task and they believe it’s within reason to be worked on. Giving the engineers time to reflect on what work will soon end up in the sprint and whether it’s a reasonable task creates psychological safety on the team. Obviously they still have the ability to discover new information that will change the effort of a task but in most cases that won’t happen if you’ve followed a good estimation process. Keep in mind that there are many factors that influence estimation:

• Bad Assumptions
• Anchoring
• Presentation
• Dominating personalities
• Peer-Pressure
• Optimism
• Varied skill sets

Pay attention to team dynamics in every estimation and try to head off any of the above issues. Many of these factors will pop up outside estimation as well but won’t be as noticeable.

When execution is consistently and significantly different than the estimates it can impact team morale. Projects are rushed which leads to bugs and more time is spent planning in the future and retrospecting what went wrong. That’s why it’s not only valuable for engineer’s happiness but it can impact productivity and perception of the team.

Summary

How to estimate

• Estimate your tasks relative to each other
• Time limit conversations
• Use a small number of values (S, M, L, XL or 1,2,4,8)
• Don't use time estimates.. or even infer time estimates
• Re-calibrate your estimation values periodically with real examples
• Have a strong transparent culture that encourages engineers to raise their hand when a task balloon

The act of estimating

• We're not good at estimating in absolutes but we are good at comparing things.
• When asked to make decisions with incomplete information we rely too much on the information we do have.
• When people of different experience estimate, we tend to follow a leader ("anchor") that biases our estimate.
• People of different skill levels will have vastly different estimates.
• Our motivations have a significant influence on our estimates.
• The presentation of information can change our estimates.

(These are the values for the example above)

• Williamsburg bridge - 7,308′
• Manhattan bridge - 6,855’
• Brooklyn bridge - ‎6,016’
• George Washington Bridge - 4,760′