Estimations and being Agile

There are quite a lot of information in the web about how to  estimate tasks in an Agile environments – They are all based on dividing the task to small features and using a statistical technique to estimate the time. But these are quite complex and take allot of resources from the team, and at the end of the day are not exact anyway. Are we wasting our time? Could there be another way?

We already know that we will never really know how long the task will take until we finish it and that we are always estimating anyway. That is why in Agile-Processes we have two estimations – one is a highlight of what can go in a release and the other is per iteration. Still when management asks a simple question – How long will it take to add a feature – the team is stunned and requires several hours to try to understand the domain and come up with an answer that is not exact anyway.

In many companies, it is considered most important to be on time. Soo important that everyone is afraid to be late. Because of this when asked – When can you finish a feature, we will do one of the following:

1. Say: We need to know EXACTLY what user stories are included in this feature so that we can have a planning session to give you the answer.

2. Guestimate and add a huge buffer – make sure that there will be no way that we will be late.

Both are bad for the company – the first requires us to do an up-front ‘design’ in order to get the estimate – wasting time, as we might not even implement the feature. The other gives wrong numbers and might lead to the company making the wrong choice.

Estimating and Event Driven

I wrote before about Improving Agile Development by Event-Driven Management. This is going to be a third option.

3. Understand that it is alright to be late as long as you raise the event early enough. Once we reach that understanding we can be more agile and waste less. We can give the management an estimation – one that we really think is correct (we should still reduce the known features to smaller one- but we will still have many unknowns) , and down the line, the moment that we understand the we won’t be on time – raise the event – and tell the management so – as early as possible to allow the company to deal with it. 

Just like the meeting in the previous post, if we are to meet someone in an foreign location, we can still set up a time, work backwards to see more or less when we have to leave and try to get there on time.
Many things can happen on the way, but as long as you tell the other party that you are going to be late as early as possible. It should still be ok.

So we can waste less time in the estimation/planning/release meetings, do a simple estimation and get on to do the work. If we understand that we are not going to make it on time – simply inform everyone.

Doing this allows us to have to courage to give the estimation that we believe without requiring all the information. It also allows us to make a mistake and be late – as long as we communicate this on time.