We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

Reframing Estimates

Deadlines
Agile / Scrum

30 September, 2020

Nael El Shawwa, former VP of Engineering at Shutterstock, explains why reframing estimates is necessary and how that resonates with the very nature of the engineering work.

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.

Related stories

The Quick Fix to a Slow Team: A Consultant’s Perspective
30 September

Peter Berg, Founder and CTO at Forward, describes how he helped ramp up a slow-moving team by applying his simple, yet expert approach.

Team processes
Delegate
Productivity
Agile / Scrum
Peter Berg

Peter Berg

Founder / CTO at Forward

The Hidden Value of Agile Processes
30 September

Brian Guthrie, VP of Engineering at Meetup, shares how he learned the hard way that many Agile processes he eliminated had their second-order effects that the team was benefiting from greatly.

Agile / Scrum
Brian Guthrie

Brian Guthrie

VP of Engineering at Meetup

Demystifying Story Points
30 September

Nael El Shawwa, former VP of Engineering of Shutterstock, dissects the mystery behind assigning story points to tickets emphasizing that estimates should always be relative.

Agile / Scrum
Deadlines
Nael El Shawwa

Nael El Shawwa

Former VP of Engineering at Shutterstock

Reframing Estimates
30 September

Nael El Shawwa, former VP of Engineering at Shutterstock, explains why reframing estimates is necessary and how that resonates with the very nature of the engineering work.

Deadlines
Agile / Scrum
Nael El Shawwa

Nael El Shawwa

Former VP of Engineering at Shutterstock

Don’t Let Yourself Be Held Hostage by Estimates
14 September

Marian Kamenistak, VP of Engineering at Mews, discusses how constant delays are usually caused by things other than inaccurate estimates.

Deadlines
Prioritization
Marian Kamenistak

Marian Kamenistak

VP of Engineering at Mews

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.