This is a well known truth for all doing agile method.
Introduction
I’m doing a migration project right now. My team is great - could be the best I’ve ever worked with. We’re converting a big VB6 application to VB.NET and WPF. And due to different reasons we decided to do this in two phases:
- First migrate everything with a tool and then get it to work again. And write a integration test that assures that the function works as expected
- Rewrite the underlying architecture bit by bit. Since we have integration tests in place we are shield from introducing any big bugs.
OK, the first phase mean that we worked our way through the old code, form by form. It was 265 of them and we created a simple tracking tool in Excel that classified each form as S, M, L or XL (based on size in KB). As we progressed we tracked the time we put in on all the things we did. Finally we could estimate how long time it would take us, and how much of that, that was left.
Of course the usual stuff happened. Two day into phase 1 my project leader (who also is a great guy, that really have adopted agile thinking, but I think he forgot himself :)) asked me “When are you done?”. I hate to being forced to answer that question without any data so I actually put it off for two weeks. But then the question came again… “Now you must know… When are you done?”.
Data gathering
Since I know that this question cannot be answered with any certainty, but rather is a guess, I started to track data that would back that up. Here is our last month day by day - how much time is left to do. (And do remember that this is a great team, that update this calculation several times every day):
Analysis
From this we can see that:
- when we first started to track time left (that took a few days) we guess that we had about 670 hours left.
- just a few days later we started to discover how hard this was… and our estimate boomed to 2108 hours left.
- then it rolled along for a few weeks. We didn’t add that much but no time was reduced also. Everybody we’re here. No people sick. It just stayed up in the 2100-range with a peak of 2268 at 2010-10-25.
- Then all of a sudden it started to fall. Why? Well we started to remove things that we didn’t had to do (not used anymore), we could reuse code we already written, we got better on doing this etc.
- And now (2010-11-12) we’re at 602 hours left.
I wouldn’t be to surprised if the hours will rise some and fall some during the days left. I am quite sure that it wont be a steady line down to zero from today.
Conclusion
When I was asked “When are you done?” I would have answered “In 670 hours” if I’ve used the data we had at hand. This was wrong. But (and this may come as a surprise) if I answered that question two weeks later I would have answered “In 2074 hours” and I’d also be wrong…. So when could I’ve been right? Never! And that is because Software development is a learning process more than anything else. You uncover more and more of the complexities of the project as you go.
For agilistas this is old news, of course. We know this. But the question still comes. Just the other week we’re asked to estimate when phase 2 is done. By then we hadn’t even decided what goes into it. So it still happens.
What to do? Just give me a date when you want it done. And we’ll try to fill it with the most important functionality, in the best quality we can manage in that timespan. I’m sorry. The emperor is naked - you cannot estimate a software project with any certainty.