Adding contingency
Product estimating is hard, it’s really really hard.
To be put in a position to estimate something, and then potentially be held accountable for it is not a comfortable position to be in. In order to help to ‘safe guard’, or reduce the risk of being wrong people will add contingency to estimates. It’s not uncommon, and we see this in every industry from software development to building construction.
Although we might feel that this can increase our chances of hitting a deadline, and superficially improve accuracy; there is a problem with this scenario. Estimating and communicating that a new feature takes 5 story points, then bumping it up to 20 and hoping it will be easily completed in that time.
Below I will explain what it is and how we can mitigate it. I really believe it is the responsibility of the Product Manager to help to protect the team in estimating. We need to ensure that it is done and communicated in the best way possible.
Buying a car
To outline the issue, think of this scenario.
You want to buy a car. The first thing you do is to research the price. Often with cars they have quite a large pricing range, so let’s take for example 30,000 to 90,000. That is obviously quite a large range, especially even before you add all the extras, packages etc. The website will tell you that there is the perfect car for your needs and budget (which hopefully for us is closer to the cheaper end).
What if the car manufacturer had decided to pad their price estimates? What if the first think we saw on the page was ‘Maximum starting price of 90,000’. We would probably close the browser and never return to that page.
Just think about what estimates are, and why we need them. They are an important piece of data to make a decision. Often around prioritising or understanding if a new feature is worth the complexity to develop. In product management, we like to be data driven. In order to make good decisions the data also needs to be good. This is what could happen when we inform stakeholders of padded estimates. Consider a stakeholder being told that a feature that could take 5 story points is being communicated as 20 to be safe. In this case the stakeholder could really make a bad decision.
Mitigating bad information
In order to mitigate this, it is really really important to give context with any estimations. In these scenarios, stakeholders need to be informed that they are padded estimates and the reasons behind it. Inform them of the range, and the ‘terms & conditions’ that come with the estimate.
This would be like rather than informing the stakeholder they can only get a car for 90,000, and them instantly deciding that its not worth it. They are informed that they can get a car between 30,000 and 90,000 – but within that range there are some variables that will help to make the best decision.
Even though we predominantly pad estimates to meet deadlines, my response to that is that you should only pad what is important to the stakeholders. It’s far better to add contingency to the delivery date, rather than each small feature along the course of the project. I am not against adding some small contingency with estimating backlog items, but I feel that allowing stakeholders to make decisions with unpadded estimates (or at least with a small amount). Then allowing them to focus on padding what is important to them, the overall project.
Summary
Not every project or scenario is the same. There are multiple factors to consider like the maturity of the organisation, the type of organisation, maturity of the team, processes in place. But I hope this gives you something for your product toolbox, and something to think about when tackling estimating features or projects.
Social Media
Don’t forget to follow me on social media!
