Learning to Size (Too Big?) Over Learning to Estimate (How Big?)

When teams are asked to pick up a new piece of work, estimation inevitably comes into play. Determining the size of each item of work is a valuable part of any planning process. If we don’t know the size, it’s challenging to determine how much of a team’s capacity will be consumed by this new work, or how long the work will take to complete.

Anti-Patterns of Estimation

Question Mark IconBut estimation is tricky. Over shorter intervals and with smaller pieces of work, we might get close with our estimates. But as we begin to estimate larger items that will take much longer to complete, our ability to be exact diminishes. There will be more unknown factors than known at the time of estimation. So, we need to be cautious about trying to be exact when estimating any piece of work.

If we accept that we cannot be precise with our estimates, we are wasting valuable time creating the illusion that we are. Teams spend painstaking days or even weeks trying to provide ‘exact’ estimates for work that may take thousands of hours to complete. During this time, no work is being completed. And when work does begin, those estimates inevitably get adjusted based on new information, which leads to still more delays.

When teams provide estimates that become promises, it can create a demoralizing work environment. In addition to the work stoppage involved with re-estimation, leadership typically wants to know why the estimates were incorrect. The team is then forced to justify the need to change estimates that were relied on to determine a hard date for delivery. All of this takes time which could be better spent completing the work.

A Different Approach to Estimating

Box_Hand_Truck_Medium_black_coralOne way to avoid this vicious circle is to use relative estimation with timeboxes of work.

As noted above, we are much better at estimating smaller, more near-term work items, and even those won’t be ‘exact.’ Any estimation is our best guess at the time-to-completion based on what we think we know. If we acknowledge that this is only our best guess, it becomes more important to identify what we are guessing.

Rather than trying to guesstimate x number of hours, we should be looking at the upcoming timebox (for instance, a two-week sprint) and taking our best guess at whether the item of work will fit within that timebox or not. If an item is too big to fit in the timebox, is there a way to break it down into smaller parts that still add value, and that the teams can complete in the timebox?

If you and your team are genuinely trying to follow an iterative delivery process, using relative estimation in this way should allow you to identify the next most important item that the team can reasonably complete, allowing work to move forward.

For a deeper understanding of relative sizing, check out this article on sizing Epics.

A Practical Example

Many years ago, I used to work for a county public works department, and my team’s job was to provide land survey information for the engineers to create improvement designs for neighborhood water drainage systems. Sometimes our teams were dispatched to an area to determine reactively why a particular property was flooded. Sometimes we were sent out to proactively get measurements used in designs for a new neighborhood.

For the new neighborhood development plans, it was more important to get a series of precise measurements to help the engineers design a good drainage plan. This measurement took many hours, even days, to complete. But, precision was important: the more precise the measurements, the better chance the engineer’s design would succeed and less chance people’s homes would flood.

For the reactive work, we did not need to be precise. We simply needed to know which way the water was supposed to go, where it was going, and what was causing the issue. To see where the ground was higher to allow the water to flow in the desired direction. To get this answer, only a few measurements had to be taken to describe the current situation and allow the engineers to begin designing a solution. These measurements could be completed within an hour, so the engineers could get to work on the resolution.

Next time your team is attempting to estimate a piece of upcoming work, try asking is it too big to fit in our next timebox of work? If it’s not too big, you have the information you need to proceed, and it won’t have taken you days or weeks to get to that answer. Sometimes we just need to know which way the water is supposed to go or what will and won’t fit.

Agile Product Development

Learn More
Duane Kenney, Product Coach
Duane Kenney, Product Coach