Why estimate in software?
— Tim "Agile Otter" Ottinger (@tottinge) July 14, 2015
Following the twitter hashtag #NoEstimates there are some breakthroughs and the message above is a good example of that. Estimating is often just guessing as in software we often build products -that have to communicate to other products- that we simply never build before. How can you properly ever estimate accurately something you never build before!?
You can’t but experience helps to give an estimate nevertheless. An estimate is what it says. It’s not a promise. It can be wrong. Everybody who does estimation does so with a package of experience.
In my experience for some new software feature we are often asked ‘How long do you think it will take? One sprint? Two? Five?’
#NoEstimates The larger the product we are going to build the less accurate the estimate on that will be.
— Melle Koning (@MelleKoning) July 19, 2015
How much time will it take? That is extremely hard to predict and the best conclusion experience tells us is as vague as the above tweet. The contrary is also true: ‘The smaller the product we are going to build the closer the estimate will reach reality.’
The sad story here is that long planning phases, like half a year, looking at the inaccuracy of estimates on that time scale are rather silly at best.
What does an estimate do?
An estimate leads to expectations, always. I truly believe that the more we practice estimation the better we become at it, as long as we take the full software delivery process into account and as long as we estimate only one sprint ahead. Estimation should, if you really want to give one, include the notion of putting this stuff live.
#NoEstimates, Why not estimate development time?
Also, only estimating development as in coding and testing, and leaving out an estimate on getting software live into production is really a waste of estimation. A waste? Yes, a waste. Why, you ask? Your Product Owner might even state: “Do not bother estimating delivery, you don’t have to do that”. Really? Sure, but when do you consider the product done, as in done-done than?
Estimates are only useful in a continuous delivery environment
Because experience teaches us that software is not truly done unless it proves to be done in the production environment. Too often the team I work in faced having to ‘fix’ a previous, long forgotten, product, because the product was only feature-switched ON numerous sprints after the team thought it was done. That is, the team had proven the product to behave as expected on the staging environment, fully regression tested, fully integration tested with the collaborating external products. And then it is switched on in the live environment. And the ‘production version’ of the external product behaves slightly differently. Or the ‘OK’ message received on staging did actually not mean all was OK. And our product does not work and we have to place a ‘hot fix’.
As developers we should take getting products into production into account
When an estimate is asked, we are not asked about when our coding plus testing will be done. We are asked when the product works in the live environment.
Estimating: Stop Trying Harder http://t.co/mLnX2MvHCA
— Tim "Agile Otter" Ottinger (@tottinge) July 17, 2015
As GeePawHill puts it estimation, stop trying harder
Change your business model so you don’t have to reliably predict the state of your software more than a month ahead. There are myriad ways to make this happen.
Estimations that try to reliably predict furter ahead than a month are a waste of time.
What way forward?
One way to more reliably predict is to chop work in smaller chunks that you WILL put into production, as in switching it on -maybe just for a small percentage of your customers-, instead of putting your work in some delivery queue, bound to be bounced back to your desk when finally the product is put to the ‘live test’.
A ‘delivery queue’ can take many forms. It can be some delivery team. Only delivering on wednesdays. That queue can also revolve around a ‘big release product package’ for which all features are switched OFF until some arbitrarily deadline. A product containing so many changes to be ‘feature switched’ at once’ that the risk putting that live is just assuring it bounces back as hotfixing work.
Babysitting to live
So how to solve #NoEstimates? Search for ways to put work into production every short sprint. Be transparent about all the work that needs to be done. Do take in stories to put products live and also (how to) monitor, how the product behaves. It is the product of the team. Better ‘estimate’ the full work, in small chunks, than ‘deliver’ unfinished work to costly queues.
To be clear: the primary measure of a scrum team's success is working software. Buggy code and useless features aren't working software.
— Jeff Nall (@jeffmnall) November 13, 2013
— Jason Gorman (only, more indoors than usual) (@jasongorman) August 1, 2015