Melle's Blog

#NoEstimates, what is asked from us?

—

by

admin
in

Why estimate in software?

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?’

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’.

IMG_1197.JPG

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.

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.

 

Comments

One response to “#NoEstimates, what is asked from us?”

  1. DevChild Avatar
    DevChild

    When an estimate is requested, I believe it’s more a commitment that is asked than a real timing question. A software engineer understands this and is willing to commit (in most cases) for the things he has under his control (e.g. programming and unit-testing) but for nothing else. The problem I see is that the people asking the estimates usually have a very different understanding of how far the control of these engineers should reach.

    This miscommunication or misunderstanding results in useless estimates over and over again. The #NoEstimates movement seems to be more a debate on how this problem can be solved. Some people question if it is useful to estimate at all if an estimates needs to take into accounts all the unknown unknowns of the project/task.

    I’m not sure that continuous delivery can actually solve this problem. It’s like building a house, you will see it being constructed every day (so it is continues delivery in a sense), this changes nothing, you still need to know in advance how much money you will need for a loan.