(Or, How To Make Meaningful Estimates For Software Products, Part 2)
Last week I left you hanging. In How To Make Meaningful Estimates For Software Products I basically said that estimates don’t work for software projects. That’s still true.
But the fact that software estimates don’t work doesn’t mean that features don’t get completed and delivered. They do get finished, you just can’t predict with accuracy when that will happen. So, how do you make software delivery predictions if you have terrible software estimates?
How can you make software delivery predictions without estimates?
So the question arises – can we get to any degree of predictability, despite that?
Here are ways you can approach predictability, even in a world where estimates are impossible, and you can use them in combination:
- Don’t ship until it’s finished – that is, make the prediction about the quality and the scope, but don’t predict the time
- Ship on a regular basis, including only what’s finished – that is predict the time and the quality, but not the scope
- Ship partial features – predict the time and the quality, and accept partial scope
- Ship tiny features – only ship features you can estimate reliably, which means (remember this from last week’s post) they are not interesting
Mitigating the software estimates problem itself
And there are some mitigations for the fact that estimates don’t work. The most obvious is the one that Steve Johnson (@sjohnson717) mentioned in a comment on last week’s post:
- Estimate by comparison – “this feature seems about as big as that feature, which took us four weeks to implement”
The smaller the feature, the better this works, of course, because uncertainty grows with the value of the feature.
But that’s not all!
I have more thoughts on estimates and product planning predictability in my next post.