Improving the Value and Accuracy of Estimation
6 December, 2017
At my previous company, I had an engineer who was very hesitant to provide estimates. When pushed for estimates, the numbers would come back with broad ranges such as "two days to two months, I don't know". After a number of 1:1's with my engineer, I found out that she had been burnt a few times before when she had provided an optimistic estimate. However, she felt uncomfortable giving padded (i.e. doubled) estimates because they seemed arbitrary. It became clear that the primary issue she was facing was that she was unsure about how to deal with the unknowns and risks within the estimate, and didn't feel that an estimate was the place to voice those concerns. She invariably wanted time to research the problem space, resolve open issues and then come back with the estimate. The project management team didn't want to split each work item into a "research" and a "delivery" phase. This tension resulted in a typical estimation being overly broad and difficult to include in a plan.
To resolve this issue, we recast the estimation exercise as a discovery tool, rather than a project management tool. When asked for an estimate, I would ask her to grab a piece of paper and write down her rough estimate range. If she felt it was too broad of an estimate, I asked her to work through both the high and the low sides of the estimate as described below. To provide structure around the lower side of the estimate, I asked her to list out the items that she thought would cause her optimistic estimate to be missed. These would be a mix of unknowns, risks, and issues. For the upper side of the estimate, I asked her to consider what actions she could take to ensure that we didn't get close to the pessimistic estimate. These actions would generally be mitigations, contingencies and understanding unknowns. Sometimes these lists had a fairly good overlap - the same risks that would cause a miss in terms of an optimistic deadline generally had mitigations or contingencies. Generally, these two lists could be fairly easily discussed and understood within 10-15 minutes. This allowed the shape of the estimate to become considerably improved, with the information that the engineer already knew. Of course, there were occasional big unknowns or issues that had a material impact on the task. These would be floated to the project management as Proof of Concepts or Feasibility checks, helping the project management team come up with a more achievable and detailed plan. The act of recasting the estimation effort as an engineering discovery opportunity helped my engineer to get through her resistance, so that she was comfortable providing estimates. It also allowed her to improve on the accuracy of her estimations. After a few months of doing this consistently, my engineer found that she could quickly think through a problem and could come up with a reasonable estimation on the spot, or could at least give a ballpark estimation with a set of caveats that would need to be resolved before a final estimate could be given.
Moving estimation from being a project management task to an engineering discovery task goes a long way to helping engineers engage in estimation. The approached used with my engineer, is very similar to the approach taken with traditional planning poker. You get a range of estimations and work at both sides of the extremes. The act of discussing the outliers - and discovering the insights that help place engineers at the extreme of their engineering estimates is similar to the single person effort that my engineer followed. A lot of engineers split product and process work into two distinct buckets. In reality, the work item is needed for both buckets. If it cast appropriately, the simple act of estimation can help scratch the engineer's itch in terms of them being able to find and fix problems. Finding ways to cast a less preferred collection of tasks to provide value for a preferred collection of tasks helps engineers engage, and adds value at the same time.
Himanshu Gahlot, Director of Engineering at Lambda School, shares how he used his own learnings to support his direct reports and help them grow in their careers.
Director of Engineering at Lambda School
Pete Murray, Principal Software Engineer at Electronic Arts, discusses what makes one a great engineering leader and singles out creating opportunities and motivating engineers as two key characteristics.
Principal Software Engineer at Electronic Arts
Marian Kamenistak, VP of Engineering at Mews, discusses how constant delays are usually caused by things other than inaccurate estimates.
VP of Engineering at Mews
Lloyd Holman, Head of Engineering at By Miles, shares some tips on how to manage an engineer’s career development as he highlights the importance of an individualized approach.
Head Of Engineering at By Miles
Shailvi Wakhlu, Head of Analytics at Komodo Health, explains why prioritizing happiness is all about rational choices and how her happiness framework helps her evaluate if some decision would bring her happiness or not.
Head of Analytics at Komodo Health
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.