At the beginning I owe you a small explanation to that strange title :-) I would like to write a few words about project tracking. It will be mostly a translation of my post from Battle for Agility which is a blog where I write in the first place, but as that one is written in Polish I thought this particular post might be interesting also to those of you who don’t read in Polish.
But let’s come to the point – my bizarre title. Some time ago I was working on a project and before each new iteration I used to hear “We are on the right track!”. As you may expect it had as much in common with the real situation as my title.
How does it look to you (the image below)?
Right… looks like the common burndown chart. Well maybe not so common because it’s expressed in percent instead of story points, but this will become clear in a few minutes.
So based on that chart one might even tell that we are indeed on the right track. Let’s assume that this chart was made for some project which was started with a fixed-price contract. Somehow we’ve created the base estimation for that project which included 50 pts – this became our starting 100% (scope). If we had a fixed-price contract, then we had a fixed budget. But not the money is important here, only the number of man-hours we had in the budget based on that contract (we’ve put X our developers for Y weeks/iterations into that project). Let’s assume it was 500 man-hours and it also became our 100% (budget).
Now, how about having our burndown look like that?
Right – not so good anymore… but everyone thought it’s going to be perfect and in fact in their minds they thought the burndown would look rather like this:
So where am I heading to? When we track only a scope burndown (or if we only track whether our team meets the assumed velocity level) there is always a chance that we will miss the fact we’re far away from our “track”. It’s just the way a burndow with only variable works. It always looks more or less correct until it falls down, because we only expect the falling trend and we react only when that trend is disturbed. But what we don’t see is how it relates to our contracted budget and this is especially true when we estimate in story points.
This is even so if we have current scope burndown vs. some assumed or planned burndown but still expressed only in story points and base on only estimated values.
That is why we use percent values. This way we can put two different scales tracked in our project on a single burndown chart. If we recalculate our budget expressed in hours/money into percent of budget already used and we do the same with the delivered scope expressed in story points, then we can tell not only if we are going to finish within a given time frame (burning down the scope), but also if we’re doing it within a given budget.
We’ve finished stories worth 10 pts in total which is 20% of our project scope, we’ve also worked 125 hours on those stories (real working time, not estimated values), which is 25% of our budget. Now that is the information that may warn us – we’re spending 5% more then we’re delivering. If we would not control the budget, those 20% of burned scope might have not look so bad right?
I think this might be a very simple to calculate and yet very accurate way of tracking project progress. Based on those two correlated factors we can tell whether we are truly on the right track or not. Finishing on time is simply not enough.
I would also like to note (based on our recent discussion about tasks estimation at LinkedIn) that the approach presented here works well when you have stories estimated in points and you don’t even estimate tasks. No estimations in man-hours needed tool to be able to track time and stay up to date. I’m sure that the stakeholder seeing the red line falling down faster than the blue one won’t wait long to react :-)
PS: We plan to provide such a way of project tracking in one of the future releases of tinyPM.