Mar 9th, 2021
Changing Perception
Part 2: The Estimate Myth
Written by: Jesse LaDousa, Chief Executive Officer
Last week I wrote about beginning the difficult process of rebuilding confidence. IT has a long-created reputation of missing deadlines, under delivering, and being difficult to work with. This pattern has created mistrust in many organizations between the business and IT groups. I wrote about creating a partnership to help with rebuilding trust between the two sides. There are many ways in which we can accomplish this.
One of the largest areas of friction on most projects is surrounding estimates. To estimate is to: “roughly calculate or judge the value, number, quantity, or extent of”. All projects must first produce a plan. From that plan, we can begin the process of estimating the work and target a delivery date. We use the information we have at that time, historical references to similar projects, our understanding of the team’s capacity and velocity, the budget we are allotted, and any deadlines that could be imposed. We take all this information at a single point in time and produce a “best guess” estimate for when (and what) we can deliver.
Too often, following this initial estimate, the outputs (numbers/dates/features) are set in stone. We want to call this the final estimate that shall be inherently right for the duration of the project – a.k.a The Estimate Myth.
No one would argue that we should strive to deliver on our commitments with high quality and precision, but we must not forget that we produced that estimate at a single point in time with only the information available. New information is going to be coming at us every day. Changes in the priority of requirements will occur frequently and new requirements will arise as we continue to learn. Some tasks will be harder and take longer, while others will be easier and take less time. Efficiencies will be identified by the team to increase velocity and slip ups will occur that will slow that velocity down.
One of the reasons that the Agile methodology works so well is because it gives us the ability to react quickly to the above-mentioned items. As a team (business partners included), we can talk through requested changes and identify how to best handle them within the current or upcoming sprint.
I believe one of the biggest responsibilities for any team is to take this discussion one step further. We MUST assess the impact of the requested change against the plan (sprint and release plan). We must be fully transparent with the requestor and show them how the change will adjust the duration and/or cost of the release. For too long, we have simply taken these changes on as a team and then pushed the delivery date without enough discussion. If we stop and have that discussion with our partners, we may find that the change isn’t high enough priority to take on right away. At the very least, we can decide as a team to make the change and accept its impact(s).
What we must never forget is that estimates are just that; they cannot be set in stone.