3 benefits of improving your burn-down charts
blog.in-sight.io
blog.in-sight.io
I have yet to see this type of process and measurement add value or productivity to a project. But perhaps that's just my experience.
Look, they're estimates . . . often made by other people than the ones doing the work.
(Oh, and having the build break for two or three weeks running didn't help the "estimates" very much. A culture of build breaking just rewards the people who are less careful than others).
I finally got the PM on our project to call our scrum meetings "status meetings" instead, because that's exactly what they were. Status for rollup into the Great Burndown Chart.
Over two years out of that garbage and I'm still bitter.
When you hear the words "Yup, we do Agile, but we have our own take on it," run away, because it's going to suck hard.
Agile means doing it your own way. It means customizing what works for the team and the particular tasks.
Scrum is a fixed methodology with a rulebook.
(A lot of time "Agile" gets used to mean "Scrum" but the two aren't the same, or even the same kind of thing, though the Scrum Book is an often not-unreasonable starting point for an agile organization.)
Every team/company has their own take on Agile, copying what other successful teams do verbatim doesn't necessarily work. There are objectively many wrong ways to do Agile (your above example being one) but not any single "correct" way.
Have you been on a team that has added productivity? Note that most teams get more done by adding labour, but that is not increasing productivity. Rather, getting more or better output per labour hour.
Then, how did you know where to focus effort to improve? And that you've increased productivity? Were the teams relying on improving tools, improving practice, and in what mix?
The most productive teams are the ones that focus on good people doing good honest work, being fairly rewarded, having a meaningful separation/delegation of responsibility/authority, communication, a knowledge of when to gather data and optimize against it and when not to, etc.
So, any time you try to distill team productivity on this cooperative creative endeavor into some number that you're going to put on a chart and give people shit about, you've already lost. If you don't already have a sense of how productive your team is and what the obstacles to increasing that are, chances are you're just a suit and you need to have someone else to run the team.