Don’t Let Yourself Be Held Hostage by Estimates
14 September, 2020
Oftentimes I would hear stakeholders or PMs complaining that the engineering team repeatedly fails to complete their work on time. They would push even harder on deadlines assuming that that would help. In reality, it only creates additional tension that helps no one. They would also try to add artificial buffers which further complicates the problem.
However, estimates themselves are rarely a problem and constant delays are usually caused by things other than inaccurate estimates. Therefore, don’t let yourself be held hostage by estimates!
I tried to underline that estimates shouldn’t be understood as commitments, but should be interpreted more broadly to include the value of the development process and shouldn’t be exposed and discussed outside of software development.
If a team repeatedly fails to deliver on time, it is believed that their estimates are imprecise or inaccurate. Only using the right insights could help us establish what the problem is really about. I would typically find out that the delivery system is not functioning properly. Namely, during a sprint planning, a team would commit to a number of issues to be implemented, but a great number of unplanned things -- from bugs to different types of blockers -- would emerge that couldn’t be anticipated. The solution would be to identify possible unplanned or ad hoc issues and clearly define under which circumstances they could interrupt the implementation of the planned activities. That would include defining all of those unplanned issues; for example, what would constitute a blocker, etc. If a team has to deal with a few ad hoc issues monthly, things would likely go according to a plan. But, if the unplanned issues constitute up to 20-30 percent of the output that would cause serious problems and consequently delays.
Also, PMs and tech leads should have a clear insight into the type of work a team is completing; for example, how many features or bugs they were working on, how much support they offered or helped with customers, etc. If you have a comprehensive insight, you could adjust your expected ratio and incorporate that into the next sprint planning. This approach would help with estimates since it would provide guarantees for the output as included in the roadmap.
If the team and a PM would act transparently and inform stakeholders regularly on the status of the features, the result would be understanding and support. If we would notice at any point in time that the possibility of a delay increases, we should immediately inform stakeholders about it. The worst-case scenario would be to keep the information about possible delays till the very delivery day.
Another thing I encountered was a lack of communication between product and engineering. Product would usually hand over the requirements and engineering would deliver on those. Not only that it is rather a Waterfall-ish approach, but it hinders the productivity of engineering. Instead, product and engineering should have an opportunity to design things together, which would additionally help engineers understand the complexity and all edge cases and thus increases the possibility that the estimates would be correct.
Only after those other issues are addressed I would look at the accuracy of estimates. We could create a matrix that reveals the variation or differentiation of estimates. If the variation is high, then the team is clearly not making estimates right. To fix that we could implement the estimation checklist that identifies what should be part of estimates -- code review, QA, deployment, etc. and it should not only include the implantation but design as well.
- Most of the time, estimates are not the problem. The problem is, however, that engineering acts as a black box. Specifically, in the case of under-estimated work, I ask engineers to update the stakeholders promptly.
- It is not the estimates that matter the most, but whether a PM has chosen the right features a team should be working on and that would benefit customers and bring us the most revenue. Therefore, instead of focusing on estimates, we should focus on prioritization.
Michael Vanhoutte, Chief Architect at Aprimo, discusses why it is important to establish that a problem you are trying to solve is the right one and how the engineering obsession with ‘fixing the problems’ can lead us astray.
Chief Architect at Aprimo
Alvaro Moya, VP of Engineering at Wefox, explains how to spot key issues when joining a new company and what actions should be undertaken to solve those issues.
VP of Engineering at Wefox
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.
Nael El Shawwa
Former VP of Engineering at Shutterstock
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.
Nael El Shawwa
Former VP of Engineering at Shutterstock
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
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.