54952Re: [scrumdevelopment] Re: Looking for Advise on Standup, burndown, and tracking progress
- Apr 17, 2012As one of the ScrumWorks developers years ago, I want to chime in here.We never ever ever intended the metrics to be abused in the manner Tony's management seems to insist on. The Sprint Burndown Chart, if used at all, is to help the team's self organization, not give management reasons to intervene. People outside the team should visit the team's Sprint Review Meeting to see the actual product! Why would you prefer a bunch of derived numbers over an actual tested product demo you can touch and feel for yourself? That's like prefering pornography over actual sex!The tool does generate the Mike Cohn style converging/diverging release burndown (or up) charts Gareth refers to below. I've found them useful when definition of *done* is sufficiently rigorous. But they're never the main thing. Scrum is about unleashing team self organization; perhaps we were naive in hoping organizations would use our tool this way.
On Apr 17, 2012, at 10:56 PM, "merceroz" <gareth.mercer@...> wrote:
I wanted to focus in on the reporting progress part of your question.
From the sounds of it you have a PBL which outlines the stories to be delivered. You mention points, so presumably you have or could work out, a rough sizing for each story. So as you say you could track the story and / or point burndown to track progress.
However you say that management "claim this is too high level to make adjustments, that being off track will not show in the chart until it's too late." I would focus in on what this means. If you work with short 1 week sprints, you've got six sprints to go, and can provide relevant feedback to management on a weekly basis. In addition, assuming you're tracking tasks through a sprint burndown, you can provide relevant feedback on a daily basis.
This is probably nothing new to you. Hence my question about how what management want, and why do they feel the additional overhead they are asking for will give a better insight into what's going on. Why doesn't a daily update on tasks, and weekly update on points and stories not provide what they want?
One thing I've found is that providing management with a picture can short cut a lot of discussion. Even if the picture is based on the information they've already rejected! They don't need to take the time to understand your argument about why what you're suggesting will work - they can just look at the picture and see it tells them what they want to know.
I'm a fan of this approach - http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown.
In reality requirements will evolve and the scope will change - more so as it's a POC / R&D project. This style of burndown clarifies the difference between scope changing and the external perception that a team is not delivering. Which not only sounds like it would be useful in your situation, but puts you, the team and the PO in a better position to make decisions that are likely to lead to success.
Hope this helps.
--- In firstname.lastname@example.org, "tony_t_tubbs" <tony_t_tubbs@...> wrote:
> Management's desire has been and is to use ScrumWorks so they can run reports so they can see progress. The team often feels like this is forcing a tool that doesn't always fit. Our current situation is a POC sprint that has a lot of R&D to do. We do not know hours like we might otherwise. We have estimated story points relative to each other. We know when we start, and we know when and what MUST be done - a functioning POC of specific key concepts and business functions by June 1 as proof we can do a full implementation.
> Really, the POC containing the stories we've identified MUST be done. Whatever that takes. Longer hours or what not. The management wants hours in scrumworks so they can see if we are on track or not. I've suggested burndown only stores, or perhaps story points. (Which doesn't fit into ScrumWorks reporting I guess) They claim this is too high level to make adjustments, that being off track will not show in the chart until it's too late. By then longer hours or adding people or whatever will just be too late.
> Note that I personally, and expect many of you, would put this scenario into ScrumButt category. Assuming there's nothing I can do about that for the moment, please advise what I can actually do to best meet the needs/desires. If it can be done in a way that could convince management there's a better way, then all the better for me and my fellow developers.
- << Previous post in topic Next post in topic >>