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.
Marian Kamenistak, VP of Engineering at Mews, outlines key recommendations and resources to make learning an integral part of the engineering role and knowledge sharing across the company a steady practice.
VP of Engineering at Mews
Sabeen Syed, Senior Engineering Manager at HashiCorp, shares her efforts to single-handedly establish an in-house mentorship program.
Senior Engineering Manager at HashiCorp
Dmitry Nekrasovski, Senior Manager of Product Design at HashiCorp, shares how he helped his design team level up by applying a simple, three-step approach.
Senior Manager, Product Design at HashiCorp
Roy Pereira, CEO at Zoom.ai Inc., shares how to deal with a junior engineer who -- for whatever reason -- is resolute on rewriting the code without a more profound understanding of the implications of their proposal.
CEO at Zoom.ai Inc.
Jack Kora, VP of Engineering at dscout, shares how he helped one of his reports to overcome interpersonal conflict in the workplace and gain confidence.
VP of Engineering at dscout
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.