Reframing Estimates

Problem

Estimation is one of the most challenging skills for any engineer or manager to master. While estimation is almost impossible to pinpoint and is often much of a guess, it is a fundamental part of software project management. In more favorable cases, you will have around 50 percent of the information needed and will be expected to come up with a date that others will expect to be 100 percent accurate.

The future, however, is inherently unpredictable and any present action will impact how the future will unravel. Without a comprehensive understanding of the engineering work -- that includes a myriad of variables and countless unknowns --, it will be hard to grasp all the difficulties of coming up with estimates. Moreover, non-technical managers often tend to downplay someone’s engineering competencies by their (in)ability to come up with precise estimates.

The key problem is that estimates are produced at the moment when you have the least amount of information about the problem space. As we work the problem and the solution we are gaining valuable knowledge that is relevant to our estimate. But alas, the reality is and the root of this challenge is that estimates can be perceived as promises and any change can be perceived negatively.

Actions taken

Understanding what and how estimates work should precede any further action. Estimates are a quantified evaluation of the effort needed to complete a task with multiple variables and in the midst of the realm of uncertainties. As you are becoming more familiar with the context and requirements, you will be able to more accurately produce estimates. For example, if the PlatoHQ engineering team already built 30 landing pages for an email campaign, their estimates for the 31st landing page will be probably correct. But if the technology stack or the team would change, emerging unknowns would affect the accuracy of estimation.

My approach would be to reframe estimates in terms of budgets. Rather than producing an estimate to a solution you should develop an understanding of when this solution ceases to be valuable. This becomes the basis for your budget. This exercise requires a transparent collaboration between various stakeholders to understand how much time we are willing to spend producing a viable iteration of the solution. From here on the variable that is within the team’s control is what we spend this budget on - in other words, the scope of the solution. Time is fixed, and quality of course is also fixed. As we progress through the various iterations of building, the goal is to maximize the value we are able to unlock given the time constraint. This approach is predicated on an unwavering belief amongst the team that for a specific problem there are multiple acceptable solutions. Our job is to unearth one or more of these acceptable solutions within the time constraint allocated.

Lessons learned

• When you reframe estimates as budgets you will have to force the conversation on tradeoffs to happen early on. This is great and increases your chance of shipping on time and on budget.
• Pick a consistent budget for your work -- whatever makes sense for your organization -- and stick with it. For example, every release should take six weeks and no more than six weeks.
• Like everything this requires practice. You may still occasionally struggle to deliver on time, but even in this situation, this presents a golden learning opportunity. From here we can self reflect as a team to understand what trade-off did we miss and how could we have identified that we wouldn’t make it earlier in the process.