- too much pressure early on
- it doesn't handle the unplanned
- it is unforgiving
- PM's and customers misread it
- it discourages refactoring
- it focuses on a predetermined time
- really? most people feel it at the end
- it is a reminder of the reality of the clock
- neither is the market, it is changing whether you deliver or not
- well... yes, that's true with any data point
- not if you refactor constantly
- or you could say it focuses on meeting a completion of commitment
Umm... no. If you are really interested in going agile, then you have to understand that there is a power shift from the managers to the team. Instead of having people above (who aren't doing the work) ask for ridiculous things and make useless statements, the team is now more in charge of the process. But, the idea of a self-empowered, self-managed team is that the team has to be willing to be accountable for the work. This is not just the validation and quality of that work, but also the predictability of its timely delivery.
My view on this matter is two-fold:
- The burndown is an indicator. Bad trends in burndowns should be a flag for resetting expectations. When expectations are adjusted (be it the developers, customers, or managers), then everyone should know about it (that is why we do sprint planning and sprint review together, right?).
- ANY METRIC can be abused. If your culture stinks, or there isn't a trusting relationship between the team and the customer or managers... then any metric can be abused to support finger pointing. This is not specific to the burndown.
"My definition [of agile] is that you accept input from reality, and you respond to it" - Kent BeckA burndown is one of many measurements of reality! Unfortunately I think the answer in this situation is that the group needs to improve the cultural issues instead of throwing out the burndown.