These articles are aimed at senior management funding Software Developer or IT Professionals attempting to show the ROI benefits of what can sometimes seem counterintuitive.
This ever growing library is provided free of charge and can be found here.
A conversation has recently come up with one of my clients regarding estimates – which follows on nicely from my previous article on the subject.
This conversation focused on how to get the best ROI from estimation work. And roughly followed this thought process:
Estimate never equals Actual
As per the last article, by definition, an estimate will never exactly match the time it actually takes to do it.
There will always be a delta between the two – be that hours, days, weeks, months or even years.
Effort expended on estimates will only increase confidence
The more effort we expend on estimating, the more confidence we can have on that estimate. It is however still no guarantee that the estimate is correct.
Effort is important in this conversation, and I’ll jump back to it later.
But, let’s assume we use very course grained process like t-shirt sizing to estimate a piece of work.
“T-shirt sizing is a way to practice relative sizing. By comparing stories, you can break them into buckets of extra-small, small, medium, large, and extra-large. Estimating in relative buckets is more important than estimating absolute time or effort.” CA.Com
T-shirt sizing doesn’t give us “this job will be done in two weeks”. It looks at the relative size in comparison to other jobs. You can then get an idea of which jobs are small vs large, etc.
In itself, t-shirt sizing does require some effort – but it pushes us to provide a quicker answer than a lot of other methods. And I’ve found that t-shirt sizing is normally enough to get buy-in for a project. If the business expected something to be a small and it comes back an extra-large, then this will normally be enough to shelve the work.
I’d certainly advise an organisation to looking into t-shirt sizing (or similar) as a means to quickly answer the important question of “should we do this?”
And while this alone maybe enough for an organisation, I know some will then push for a delivery date.
Given we know we will never predict that accurately, we are talking about how best to expend further effort to gain confidence – but again I’ll come back to that.
Effort is proportional to size
Small side step at this point. I wanted to introduce the idea that the effort to increase that confidence is relational to our t-shirt size.
Roughly speaking;
This is probably fairly self-obvious – but it still surprises me that some very clever people think that that effort is either “free” or can be same for any size of project.
Best use of that effort
Ok, so if we’ve decided we are going to expend effort attempting to increase our confidence (again, I re-iterate – no amount of time will guarantee that actual size) – how best do we use it?
Traditionally we would have burned a lot of effort documenting and planning. That effort can be considerable - with questionable ROI (I’ve talked about this previously).
Even with that work we are still no closer to seeing that the job can be completed.
But there is another way …
Rather than invest that time in estimating, invest that time in doing.
If you’d normally expend 4 weeks of effort documenting and planning a “large”; then invest that time in taking part of the work and doing it.
This is very much in line with Agile thinking – it allows you to slice the larger job and “have a go”. At the end of that period you can see if that slice is delivering what is expected. You have empirical evidence if that slice has been completed and thus evidence that can be applied to the larger job.
As far as the larger job goes, it is still just a feeling of confidence – but the difference is that you should have working software (part of the whole) rather than paperwork. That working software should allow you to validate that what you have asked for is what you have received. And what you asked for is what you actually need.
Think of it as reviewing the result of any investment – but at such a quick cadence that you are minimising the risk.
If you take a look at my articles on Agile, I give more of an idea of how that works:
But for me fundamentally this comes down to this one line in the Agile Manifesto:
“Working software over comprehensive documentation” Agile Manifesto
The Agile Manifesto see’s greater value in that Working Software than Comprehensive Documentation.
And I do to.