I’m not a fan of estimation. I try to avoid it when I can. However, I’m not orthodox. I won’t be telling everyone that refusing to estimate is the way to go.
I admit that I’m now in a comfortable land of time and material contracts that give more flexibility to the clients and more safety to the vendors at the price of mutual trust. At the same time Lunar Logic is the first of my jobs that works this way, so I’m more than familiar with fixed everything sort of contracts too. In that world estimate is a king. A lousy king though.
Despite the fact, that fixed price projects are a nightmare from my past life, we can’t forget about estimation at all. Even those awesome folks we started working with recently started with asking us to deliver estimate in story points or other abstract measure of our choice.
I intended to track progress in the project with Cumulative Flow Diagram (CFD) that counts only a number of tasks completed. However, having individual estimates for all the stories in backlog it’s easy to have two CFDs: one tracking a number of stories and tasks and the other that refers to initial estimates.
One might suppose that it would be basically the same data on both charts. And one would be wrong.
Let’s start with the charts. Here’s standard CFD for the first few weeks.
And here’s CFD that bases on estimates in story points.
What’s the difference? In fact, there are quite a few of them.
For the starters, the scope changed only on the first chart. What does it mean? Simply that despite no change in total points there were new tasks. In this case almost all of them were non-functional tasks like setting up the environment, design pre-processing and adjustments in existing code that enables integration with the new part of an application.
There was also a split of one of stories to a couple of them for the convenience. The total estimate didn’t change although there was a new story to build.
Another thing you may notice is that on the second chart we’ve finished anything pretty late in the project, while the standard CFD shows completion of a couple of features early. Again it is connected with non-value-adding and non-functional features that had to be completed to get the team running.
Finally, and most interestingly, try to judge amount of work in progress and size of stories in progress looking at the charts. A hint: you will find the answer to the former in the first and to the latter on the second chart.
Standard CFD tells you that we care about limiting WIP and avoid starting too much. The story point-driven chart shares a different story. Steepness of the coding curve indicates that we’ve started with heavy features. In this case heaviness was mostly driven by risks – the heaviest features were most risky ones. We decided to start with them to address risks pretty early in the process so if there’s a screw up on the way we know it as soon as possible.
By the way, I don’t focus here on the data that you specifically get from CFD. You could draw exactly the same conclusions if you used burnup charts, which are gateway drug to Cumulative Flow Diagrams.
Obviously, CFD can tell you a bit more, e.g. about the awesomeness of the client, as they don’t ever have anything stacked in approval. Whatever is ready it gets verified and accepted.
Anyway, the point is that despite I don’t feel that detailed estimates in this project really pushed us further (maybe despite building trust relationship, but that’s a different story) we can still use the work invested in estimation to learn something.
And, as you see, you can learn quite a bit using very simple tools.