Plato Elevate Winter Summit has been announced (Dec 7th-8th)


Back to resources

Reframing Estimates

Agile / Scrum

30 September, 2020

Nael El Shawwa
Nael El Shawwa

Head of Engineering at Perpetua

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.


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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

Working From the Ground Up

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, uprooted an entire product and built it back up again with the help of his team.

Toxic Atmospheres
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

How to Build a Software Team from the Ground Up

12 November

Deepesh Makkar, Sr Director of Engineering at SunPower Corporation, shares his experience transitioning his organization from contractors to a 50/50 split of full-time employees and international vendors.

Cross-Functional Collaboration
Agile / Scrum
Deepesh Makkar

Deepesh Makkar

Sr Director of Engineering at SunPower Corporation

Succeeding as the First Product Hire in a Startup

2 November

Priyanka Naik, AVP of Product and Technology at J.P. Morgan, shares her plan to bring a product to execution as the first product hire in a startup.

Goal Setting
Priyanka Naik

Priyanka Naik

AVP - Product and Technology at JP Morgan

Choosing the Perfect Implementation of Agile

25 October

Shubhro Roy, Engineering Manager at Box, stresses the importance of the holistic nature of Agile methodology; picking and choosing à la carte may cause more problems than it solves.

Goal Setting
New Manager
Agile / Scrum
Shubhro Roy

Shubhro Roy

Engineering Manager at box

You're a great engineer.
Become a great engineering leader.

Plato ( 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.