This episode is a wrap-up for a mini-series looking at estimation in software development - recapping the guidelines I provided in Episode 189 and providing some additional tips that didn't have a home elsewhere in the series.
Or listen at:
Published: Wed, 05 Mar 2025 01:00:00 GMT
Links
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
This episode is a wrap-up for a mini-series looking at estimation in software development.
I started the mini-series back in episode 189 by providing the following guidelines:
1. Don't invest in estimates unless there are clear demonstratable value in having them.
2. Agree what a valuable estimate looks like. This will likely be a desirable level of accuracy and precision for an estimate.
3. Provide the team with training and time to develop their estimation skills
4. Correct data on points 1 to 3 and regularly review if you have the correct balance
Subsequent episodes have taken a deeper dive into the specific aspects for estimation in software development, and while long-term listeners may find an amount of repetition across the series, I want each episode to be understandable in its own right, as much as practical, to be self-contained advice.
In this episode I wanted to provide a wrap-up, recapping those guidelines and providing some additional tips that didn't have a home elsewhere in the series.
So, let's recap those guidelines;
- Don't invest in estimates unless there are clear demonstrable value in having them.
I say this because it's often the case we do estimation because we think we should do. It's always been done, it's only professional etc. Any number of long-held beliefs.
I'm asking you to question that.
Often, estimates are not providing the value that you would want or expect. If they are not providing value, then you have two options - improve them or stop using them. Constantly churning out low-value estimates simply because it's expected is a waste of effort, a source of organisational dysfunction and creates dangerously dysfunctional environments.
- Agree what a valuable estimate looks like. This will likely be a desirable level of accuracy and precision for an estimate.
How can you possibly know if you are getting valuable estimates unless you can agree, as an organisation, what that means? How do you measure if it is providing value?
Simply ticking a box in a software development process is not providing value.
And this conversation needs to be had across the organisation. It needs to be valuable to all stakeholders. Otherwise, again, it becomes a source of distrust. I suspect this conversation will be the eye-opener.
Normally, I find that the further from the work, the higher the expectation on the accuracy and the predictability.
A delivery team could sensibly provide an estimate that they feel they have 50-70% confidence in. Yet, when it reaches the C-suite, there is an expectation of it being 100% - a dead certainty.
The difference of a few organisational levels going from a 50-50 guess to a commitment is a source of much mistrust.
- Provide the team with training and time to develop their estimation skills.
It's like any skill, it has to be practiced and refined to obtain a good level of proficiency.
We can't get an oil paint set for Christmas and expect to be exhibiting in the Louvre by New Year.
Certainly you can't expect to be receiving valuable estimates without investing.
- Collect data on points 1-3 and regularly review if you have the correct balance
Like many things, there are no silver bullets here. Much of it is in the "it depends" category.
And where there is uncertainty, how do we handle it? We measure. We make adjustments. We repeat.
What works now may be wrong tomorrow, thus we need to be constantly measuring and adjusting to get the best balance that we can.
OK, so now on to the random pieces of advice that didn't really sit anywhere else.
- Have a process
If you are doing something different every time you estimate, it becomes difficult to know what works and what doesn't. Rather, follow a process. Make small changes on regular occurrence, and measure the impact of that small change, and adjust the process based on it.
- Use checklists
Checklists are great. They can help us make sure we are working through the process in the expected sequence.
They can also be used to prompt to ask "do we need to consider X"?
For example, maybe some work needs a security audit. Forgetting to estimate that can be quite impactful. But asking the question for each piece of work can be no longer than 30 seconds as we ask "do we need a security audit?" and everyone around the room agrees it doesn't.
- Expect to be inaccurate
We'd all like our estimates to be highly valuable, with great accuracy and precision.
However, that is not easy to achieve.
Thus, make sure that everybody up and down the organisation has realistic expectations. Consider how this is communicated, always aiming for trust and transparency.
- If the team changes, then expect the numbers to change.
It may seem obvious, the forming-storming-norming process, but like the process, if the team is inconsistent, then you can't expect consistency in the work, and thus, consistency in the estimation.
- Consider defining archetypes
An archetype is a standard type of work package that can have a standard estimate. Think about this as a menu with a price list.
For example, maybe you expect a new webpage will take 1 week, an emailer to take 3 weeks. Thus, if the work is made up of 4 webpages and an emailer, you can calculate your estimate as 7 weeks.
This approach, while unlikely to be very accurate, can be useful in large organizations that are trying to quickly achieve coarse-grained estimates without going into detail.
I'd expect you will likely need a centralized estimation function to put this into place initially.
In the closing of this mini-series, I would like to remind you of Eisenhower's quote "Plans are useless, but planning is indispensable"
It's a reminder that the act of planning provides more value than having a fixed plan. The act of planning illustrates the importance of flexible thinking in the face of change.
In the same way, the value is in the estimating, not the estimate.
Thank you for taking the time to listen to this podcast, and hopefully the entirety of this mini-series. I hope you've gained value from it and I'll be really interested to hear where you feel it's helped, or indeed where you disagree. It'd be great to get that feedback to include in future episodes.
Thank you again, and look forward to speaking to you again next week.