Burn-Down chart is one of the most useful project progress metrics. It shows how many features (user stories) where accomplished during previous sprints (iterations) and clearly indicates progress. It came from SCRUM and widely used in agile projects. However, to achieve good metric with Burn-Down chart, you should know some tips.
The major one is to break project into quite comparable features. I mean comparable by effort.
For example, you have 10 features. One of them will take 20 days, other 4 will take 10 days, and the rest 5 will take 2 days each. Do you think Burn-Down will be a good progress indicator in this case? No for sure. For example, you can implement all small features during the first iteration, and spend all of you time on big fat feature implementation in iteration #2. So Burn-Down will show great speed decreasing, but this is likely not true in this case.
So it is better to split the big feature into several smaller. Yes, this is a kind of an art, but you can track progress more precisely in this case.
I am very glad to say that TargetProcess:Planning 1.0 has been released today.
TargetProcess:Planning is the web-based agile project management tool that focused on Project Planning and Tracking practices. It supports all iterative processes, but encourages to use Extreme Programming planning style.
The version 1.0 is free and everyone can download and use it.
Additional details at https://www.targetprocess.com
Martin Fowler has a great post about fixed-price projects. They, at ThoughtWorks, just doubled original estimate (so half a million becomes one million). It reminds me Estimation Games (exceptional Rob Thomsett's article). He calls this game "Doubling and add some".
I was taught this game in 1968 by Bob Smyth who, in those days, was the
smartest person I had ever met. Simply, you figure out [however you can] what
you think the task will take and then double it. So a 5 day task is quoted as a
10 day task.
Like all good games, I learnt the lesson of why you play when I
submitted my first ever estimate to my big boss and he immediately halved it.
Later, I realised there was a better version of this game. I quadrupled my
initial estimate so then, when my boss halved it I still had double [which
surprisingly I always needed]. Bob also showed me that by adding some float or
fudge factor usually around 20 - 40 % if I was halved, I still had some slack up
my sleeve [which surprisingly I also always needed].
Of course, the problem with this game is that everyone knows it why novice players are often caught out by bosses/clients who cut the estimate given by a novice by 3/4 when the novice has only doubled their bid. The other problem is that it never stops. In a version of bluffing as seen in poker, no one knows who has doubled or who have
multiplied by eight and so on.
Much later, when I was researching material for project management, I found that time and motion studies in the 1950's had shown that the average lost time [meetings, waiting, talking and so on] in office work was around 50%. So the doubling game was based on some sound research.
Read the article and you'll understand all defects of fixed-price projects estimation.
There is a very true post at Agile Business Coach blog about Waterfall methodology.
"Traditional Waterfall Methodologies destroy options by making decisions earlier than they need to be made."
I think this phrase emphasize the main weakness of Waterfall. Sure, Waterfall has many weak points, and it is obvious for most experienced developers that Waterfall is just wrong choice for the vast majority of projects. Risk management in waterfall projects doesn't help. Actually, there is too little space for risk management. You can't step back and do some rework. You have a Plan. You have a Signed&Approved Spec. You can change them, but very often these changes take a lot of time. And time is one of the most important constraints in the project.
Waterfall is not agile, thus I don't like it. At all.
However, I know that Waterfall could be used for certain types of projects. It can be used successfully for small, repeatable projects, where surprises are rare. But even for these projects iterative approach is more suitable. It's just a common sense...