Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
I have never considered burn up charts before but I think they do a much better job of telling a story. I have never seen anyone really take burn down charts seriously, and at most places I have worked, there is a big period of stagnation for the first few days while everyone fixes stuff from last sprint and then 60% of the work gets done in the 48-72 hours before the demo.
I think the utility all depends upon how effectively an organization uses Agile. If you pressure the team to make stupidly optimistic estimates in order to look good in front of the client, you're going to have a hard time explaining that away no matter what. If we need several days of remediation every single sprint, does that mean we never are actually completing a sprint successfully?
You did an excellent job making the case for burn up charts, and in organizations where people are valued over process, I think it provides a lot more context.
I have never seen anyone really take burn down charts seriously, and at most places I have worked, there is a big period of stagnation for the first few days while everyone fixes stuff from last sprint and then 60% of the work gets done in the 48-72 hours before the demo.
Haha, I know what you mean !
Thanks for the input.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have never considered burn up charts before but I think they do a much better job of telling a story. I have never seen anyone really take burn down charts seriously, and at most places I have worked, there is a big period of stagnation for the first few days while everyone fixes stuff from last sprint and then 60% of the work gets done in the 48-72 hours before the demo.
I think the utility all depends upon how effectively an organization uses Agile. If you pressure the team to make stupidly optimistic estimates in order to look good in front of the client, you're going to have a hard time explaining that away no matter what. If we need several days of remediation every single sprint, does that mean we never are actually completing a sprint successfully?
You did an excellent job making the case for burn up charts, and in organizations where people are valued over process, I think it provides a lot more context.
Haha, I know what you mean !
Thanks for the input.