How effective are your estimations?
One of the things I’ve been pondering recently is around estimations. If you’re not familiar with estimations – it’s a step in the agile process, before development starts, where a group of developers will discuss a story and assign a point value to the card. This point value is meaningless by itself, but is very useful when comparing different stories. For example, a 4-point story should – on average – take twice as long as a 2-point story.
Making estimations effective
There are a number of techniques we use for increasing the effectiveness of estimations. From the top of my head, these include
- Using an estimation scale, such as 1,2,4,8,16… or 1,2,3,5,8,13…
- Estimating by complexity instead of time
- Doing estimations as a team (although this can be difficult and costly on large teams)
All of these techniques (and many others) can help to make estimations accurate and effective. This adds tremendous value to business owners since they get an idea of how costly a feature would be to implement. Different features can therefore be compared from a cost perspective and prioritized accordingly. There are other benefits as well – for example, the team’s velocity (the number of points completed during an iteration) is very useful from a project management perspective.
The hidden cost
A team using all of these techniques can be very effective at estimating the cost of a single story, but I believe there is often a maintenance cost that we don’t take into consideration. By maintenance I’m not referring to fixing bugs or having to make changes to the code in future (althought these are important considerations) – I’m referring to how a story impacts future stories.
It is quite possible for a story to have a low cost in terms of implementation (for example, it might only take a week or two to implement), but at the same time to have a massive cost in terms of impact on future stories. On my current project I can think of quite a few features which didn’t really have a high cost in terms of implementation, but because so many other features had to take this feature into consideration – either in terms of having to make code changes or doing data migrations – it ended up having a massive cost on future features.
It’s very difficult to give an example here, but any feature that had to be slightly modified several times to accomodate new features is a good candidate.
Measuring the hidden cost
It’s obviously very difficult to estimate or measure this hidden cost. How can we estimate how a feature will impact future stories before we have even implemented this feature and before we even know what future stories will look like?
I don’t think we will ever have great confidence in estimating this type of cost. It’s not like we’re going to come up with some magic technique that will perfectly predict both future stories and how they will be impacted.
The only way I know of to address this cost is to involve developers early in the analysis process. Preferably this would be in the initial discussion between the business owner and business analysts. Even better, this could be part of a checklist for discussion in this step of the process.
In Summary
I think it’s important to keep in mind the main purpose of estimation – allowing business users to be able to predict the cost of features. Users don’t care about story points. If a story has the potential to slow down future features we should enable business users to measture this cost.
Happy coding.