Agile Myths — The Burndown Chart
The Essence is not Burning down but telling what is remaining
Why am I writing this?
Recently someone who was new to the SW world, and is bewildered by all the hype of Agile and SaFE and Scrum and Planning Poker and Story Points and similar, asked me about Burndown Chart.
Most people assume that say you estimated 80 hours for a task; Every day you work at it; you deduct 8 or 9 hours from it. Basically like a time tracking chart. But actually, that is completely the wrong way to do it. Nobody cares how many hours you put in; Say that after 80 hours you still are not even close to 10 per cent of that task completion. That means it should show 72 hours still remaining to complete the Task. It is to show how much approximate time remains for others to see. And if after 80 hours you think that it will take 800 hours more; then you update the chart to show that 800 hours are remaining,
An Estimate is an Estimate — nothing else ( It’s perfectly okay to be wrong)
There are a number of articles on the internet that forgets that ESTIMATE is an ESTIMATE and not something that you can come magically at with planning poker and creating an alias with Story Points and Complexity and poor managers; understanding nothing of this and putting the story points in their excel formula to get man hours finally.
There are too many terms already — planning poker, story points etc. Fret not, safe to ignore and not worth googling. You can in plain speak estimate as low complexity but a lot of work (for example translating to a foreign language pack), low complexity low work, medium complexity or high complexity. It does not matter; this speak your program manager is least interested. They will need it in time units. And finally, you give out say 3 Staff Weeks or similar.
But you are cannot be held on to an Estimate you gave; before fully analyzing or maybe after initial POC. ESTIMATES change all the time; the more you start working on a task the more clear it becomes.
And hence r; the Burndown chart is rather more practically a Burn Up chart usually. Let me explain
Nobody cares a damn about how much effort you put into a user story; People only want to know HOW MUCH IS REMAINING.
XPlanner was one of the oldest Agile tools out there, and I used to run it for my projects long back
It had this good option of putting daily the amount of work remaining. Just for you to know that this is the real thing and is the way Agile and its predecessor XP (Xtreme Programming) was done.
Agile is a verb; agility is a culture, But years hence it is misrepresented and misused badly. Very few people really get it; People want to say they are agile, but demand “accurate estimates” — if that is not an oxymoron I don't know what is, and it might be funny; were it not that it just makes the developer adds a buffer to everything; and what is expected to make things efficient, makes it more inefficient. So it is not funny; it is kind of sad.
Side note — If you are here for the Burndown chart; there are so many articles regarding that and hope you find that; what I wanted to convey was how to do it correctly
Resources
Read
the Agile Manifesto — Simple but the most enlightening
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more
View (if you have time)
Agile is Dead by Dave Thomas • GOTO 2015. One of the original signatories and authors of the Agile Manifesto
