Cambodia, Phnom Penn, the water festival: Martin Harris

Probably one of the most common mistakes in Software Development is to allow Estimates to become Commitments.  I am sure you know the following scenario all too well.  The development team is called into a meeting room and asked the following question.  We (the management team) have had a look at the estimates, and your tasks on average are taking longer. The insinuation is that the development team is, stupid or perhaps lazy.  Worse still, an individual is called in because the stats show their work is “Behind Schedule” as judged by the estimates.  The problem is none of this though, the problem is believing that estimates are anything other than an educated guess.

The most likely outcome of this is a dissatisfied manager requesting for more hours to be worked.  This pressure normally results in dissatisfied team members and a drop in morale.  Its likely outcome a drop in productivity.  Extreme cases result in high turnover of staff as they leave in search of more enlightened projects.  In addition developers drop quality to meet the deadline.  This code is unmaintainable in the future as corners have been cut just to get it working.  So the initial surge in productivity results in slower progress ongoing.  Watch the defect rates, your teams will spend more time fixing than producing new work.

In actual fact what does the business require of our Software Development services that has lead to the belief in estimates?  We need to know when something will be delivered.  In some cases we demand that at all cost something will be delivered.  The book Peopleware by DeMarco and Lister describes this as The Phony Deadline.  Poor delivery is the result of picking a phony deadline.  Yes you got something, but it might not work quite as expected.

I still want that delivery date, what can be done?

Have it you shall, but not straight away.  Now I have spent the last few paragraphs showing how estimates poison the team and reduce product quality.  In the next section lets look at the relationship between our team and the sponsors.

A collection of estimates can be used to provide the paying customer with an inaccurate delivery date.  So given that the average customer has problems with the definition lets re-brand estimates as guesses, educated or otherwise.  There are two important things that a software development team needs to provide the business.

1. The contents of a delivery.
2. A delivery date.

There are only three variables in delivery, time, cost and scope.  Cost is most often set in stone at this stage, scope can be negotiated and time has an awful habit of not sticking to the rules.  The trick is to use our guesses to address the content of the delivery instead of the go live date.  For delivery date we will record story velocity over the first few tasks and use that to extrapolate the delivery date.  We will carry on tracking velocity and the cone of uncertanty will get tighter, leading in turn to a more accurate date.  Commitments can be made on that date once you move into the cone and the variance diminishes.  This can be problematic to the business at first because the date is non existent at the start, and as you begin to track reports will vary.  This will settle down, especially if you try to keep other variables consistent.  So stop mucking about with the team makeup and the iteration size, concentrate on tracking the work accurately.  Once you have a few releases over, you will find that velocity is a much better way to work out delivery dates.

The business I currently work in uses techniques like this in many financial metrics.  Take a look at how interest rates are set for a year.  Obviously its impossible to know what will happen to interest rates over the course of a year.  We might start at 2% and rise to 2.5% or perhaps not.  News on the economy gives some indication in the short term as to what might happen to the rates.  These news clips cause the market to react and the closer we get to the end of the year, the more likely we are to be able to guess the final rate across the year.

So what is so bad about using story velocity metrics to gain more accurate estimates of how many stories a team can complete in a delivery cycle?  To further improve things we might also consider smaller delivery cycles and standardizing story and task sizes as much as possible.

Estimates guesses still have value don’t they?

So where do the guesses come in?  Lets use a relative estimation system instead of a time based one.  In scrum these are known as story points.  Please do read that link it is probably the best description I have ever come across.  Many thanks to the authors.   The idea behind point-based estimation is to agree that at the beginning we have much uncertainty and ambiguity.  Even if we spent extra time on analysis of the problem, we would still be uncertain and much ambiguity would remain.  Points are relative to each other and are all about size of stories over time.  This is much easier to deal with as a developer.  People are comparators, we do that all the time.  This makes us much better at saying if one task is bigger than another.  Especially if we have done similar stories before.  So points are a weighted system to grade stories into a set of different sises.

Now we need some kind of system to help us standardize the size of the boxes.  In scrum a technique knows as planning poker helps with this.  Planning poker gives us a set of cards representing the relative weight of a story.  Normally 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.  When estimating your thinking goes something like,

Mmm well I have done something a bit like this before, that was a 20 but this is a bit more complex, now is it a 40 well that’s double…and this feels a bit bigger but not double.  So I will plump for a 20.

So as you see the numbers are important as the weighting is designed to help grade the story into standard size boxes.  The other important thing is the whole team takes part in the planning so you get a graded average.  This has a side effect, the team members start to appreciate the effort involved across the full spectrum of work.

So then, that delivery date?

If your able to try and run an iteration or two before giving a delivery date.  Track how many stories you can complete in an iteration and use that to project forward and arrive at a date.  Explain to the business that you will review this date with them on a regular basis and that it will get more accurate as velocity settles down.  A little like the speculation over the next interest rate announcement.  One problem is the initial project stories are often very different from latter ones.  Usually due to building and setting up initial architecture and development environment.

Another idea at the initial stage is to break out a random selection of stories into tasks and estimate / guess those.  Calculate an estimated velocity and explain to the business that you can’t commit to this date and once more accurate statistics come in you will review the new date with them.

So finally your left with no fixed date.  The honest thing to do is to explain how consistent velociy will ultimatly give a better reporting picture This is going to be a sticking point I assure you.  In the past it might have been easy to just give a date to the business.  Chuck in some contingency for good measure.  This is a very bad practice indeed.  If you do miss that deadline you loose the customers confidence.  If you manage the politics better by de-scoping your just going to erode that confidence slower.  At first explaining your system will give them a date that gets more accurate the nearer you get might not go down that well.  I can assure you though that once you get more accurate velocity and that date moves around less the business will gain a profound confidence in the system.  After all soon your dates will be the best ones they have ever had.