Don’t Let Yourself Be Held Hostage by Estimates

Problem

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!

Actions taken

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.

Lessons learned

• 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.