Mark Needham

I had my first opportunity to participate in release plan estimation over the last couple of weeks. I’ve done estimation before but never at such a high level.

When doing this it appeared clear that there were two situations that we were trying to avoid:

Under estimating

Under estimating is where we predict that the amount of time taken to complete a piece of work will be less than it actually is.

This can happen for a variety of reasons, including:

• We make some invalid assumptions – e.g. we assume integration with a 3rd party will be easy and then encounter unforeseen problems when we try to do it.
• Not considering all the edge cases – at the time of estimation we may not have all the acceptance criteria which could mean that some scenarios are not considered when estimating.

If we do end up underestimating the size of work problems will eventually manifest. Although the business may be happy with you to start with, eventually either they are going to be very unhappy when these aren’t met. The most likely outcome then is that the team is going to end up on a death march to meet the original estimates, probably resulting in resignations after the project reaches completion.

The key to handling the situation where we realise we have under estimated a piece of work is to inform the business about the situation as quickly as possible. Waiting until the delivery date before saying anything is pointless.

Over estimating

This is where we predict that the amount of time taken to complete a piece of work with be greater than it actually is.

Unlike under estimating the effects of over estimating are likely to be felt immediately.

For example, you may end up with the business being unable to afford to do the project if the estimates are too far removed from what they are expecting. As I mentioned earlier this up front transparency may in fact be in the best interests of the client even if it doesn’t seem it at the time.

Alternatively estimates may be challenged and pressure applied for them to be reduced. If they were actually accurate in the first place and the over estimation is only a perception then we may now have the problem that the new estimates are in fact under estimated.

If we reach the end of the piece of work and realise that we have finished earlier than expected due to over estimating then it may actually prove to be a good thing. We can then go and add more testing around our code, refactor code to make it more maintainable or whatever else the business sees as a valuable use of this unexpected free time.

So what should we do?

Clearly it is important to try and avoid under or over estimating, but from my experience it is often better to err on the side of caution when making estimates. The natural tendency for software developers is to underestimate how long it takes to do something. It nearly always takes longer to do something than you expect it to.

In terms of concrete things that we can do to try and avoid either of the above situations from happening:

• Estimate original velocity by taking cards without their point/ideal day estimates on them and get the developers to predict what they can complete in an iteration – average the point/ideal day totals to come up with an expected velocity
• Review this velocity after a couple of iterations to see if it’s actually accurate – communicate a changed velocity with the business
• Make sure the requirements are clear and that the developers understand exactly what is required to complete each story

Obviously even after doing all these things it is possible to get an original estimate wrong. That’s how it needs to be communicated though; it is an estimate, not a guarantee and it could end up being too high or too low.

I touched earlier on the transparency of agile and I’ve been thinking about some of the ways that we track/report information in agile projects.

In all the projects I’ve been involved in the data being tracked almost exclusively referred to development time. One of the advantages of having continuous analysis/development/testing is that we are able to reduce the time spent on the System Integration and User Acceptance Testing phases of the project.

In a typical waterfall project most bugs would be found in these two stages of a project, and they would typically be fairly lengthy affairs.

The idea behind several of the agile practices is that the number of bugs/defects in the code base will be significantly lower than you would experience with a more traditional approach. Therefore the amount of time reserved SIT and UAT can be significantly reduced.

From what I’ve seen this is not always pointed out. It is almost like it is considered implicit in the fact that we are using an agile approach to software delivery and does not need to be explicitly stated.

I am now starting to believe that it does, and more than that – it should be actively pointed out as a benefit of using an agile approach.

We should be pointing out that ‘Yes, it may take longer to produce the code than would be possible if we just coded it straight out with no testing but the total time from the first line of code being written until the time it’s production ready will be less’. We should also point out that the benefits of our approach will only increase as more code is written and the practices practiced come into their own.

I’m not sure what the best way of doing this would be – perhaps it could be something as simple as including estimates of how long SIT/UAT will take as part of a release plan and then including these on the burn up chart.

Or is there another tool available to do this?

One of the key ideas behind agile software development is providing information as early as possible to allow the business to best make decisions.

There are a variety of ways that this is done including the use of burn up charts, estimates of scope and velocity for example. This data is compiled to try and give an accurate idea of how long a project is likely to take so that the business can work out early on whether the value it adds is worth the expected cost.

I strongly believe in this approach, certainly favouring it over other approaches that I used before working at ThoughtWorks. However, over the last couple of months I have started to wonder whether providing the business with this information so straight up actually works against you.

I believe the way that the information is viewed is different depending on when it is provided.

For example, if you have a piece of work which is due to take 12 weeks and you work out after 3 weeks that based on the current velocity it is likely to take 14 weeks you are in a weaker position than if you keep this information to yourself and then ask for another two weeks when you get to the 12 week mark.

From the business’ perspective I suppose it makes sense – if after 3 weeks you’re already 2 weeks behind then who knows how far you will be behind after 14 weeks.

I am not suggesting that it’s better to hold back this information but surely there has to be a better way to present it because from what I’ve seen the baseline figure is what’s looked at and the details are ignored.

Nor am I advocating that we under estimate on purpose to get the baseline figure lower. Clearly you will end up ruining your delivery reputation if you consistently over promise and under deliver.

The driver behind the agile approach is to always add business value, and while as a developer I would prefer to try and provide something to the client, as Mark points out, it has become clear to me that maybe sometimes cancellation is the best way of doing this.