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 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 the question arises – can we get to any degree of predictability, despite that?
There are a few different ways you can approach predictability, 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
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.
I have more thoughts on estimates and product planning predictability in my next post.