3452RE: [scrumdevelopment] Re: question regarding muliple projects against a small team
- May 10, 2004Dave--
I think it's a bit of a stretch to question someone's understanding of Scrum
because they want to track individual burndown.
Like I mentioned in another post, I tried tracking individual burndown but I
did it to help programmers who were overcommitting (especially at the start)
to see that they were overcommitting. They signed up for tasks. I assigned
nothing. This was one of those teams that would look at a schedule and
think, "Hmm, 40 hours this week, let's sign up for 3000 hours of coding. I
think we can do that." I just wanted them to see--in a single number--that
they were overcommitting. The individual burndown graphs I did *should have*
had value in this direction but even confronted with such a number this team
kept thinking they could make it. (They never would.)
From what I've seen of Deb's other posts she has a very good understanding
of Scrum and I suspect her individual burndown tracking is presented to them
for their benefit, not hers.
Author of User Stories Applied for Agile Software Development
From: David A Barrett [mailto:dave.barrett@...]
Sent: Monday, May 10, 2004 9:59 AM
Subject: [scrumdevelopment] Re: question regarding muliple projects against
a small team
>I think I see part of the problem. You've made an assumption here:I wondered if anyone would latch onto that. It's a valid point.
>"individual goals which are (probably) assigned by management"
First, I figure anyone who's going to go to the trouble of maintaining
individual burndowns is probably enough of a control freak to assign the
tasks as well. I guess what I'm saying is that I don't think it's a shakey
assumption, so I'm not that willing to toss it out. Even if you do assume
that the team sets its own goals, this kind of tracking seems specifically
aimed at preventing the team from acting as a team.
Second, what's the purpose of such tracking? I see three good reasons for
maintaining a team burndown graph: 1. To prove to management that you've
got things under control; 2. To assist the team in knowing if they are on
track for their sprint goals; 3. As a learning aid for the team when
setting later sprint backlog lists. These all have value. I don't see how
the individual burn down graphs are going to add any extra value.
Lastly - and I hesitate to mention this one - I wonder how someone's use of
such graphs reflects on the their understanding of Scrum. To me (and I
have to keep on saying that over and over again, "To me"), the idea of
Scrum is point the team in the right direction, wind them up, let them go
and get out of the way. As Reg Braithwaite-Lee said (I'm paraphrasing
now), "Simply bring together talented people and remove the obstructions
Lawyers' Professional Indemnity Company
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Yahoo! Groups Links
- << Previous post in topic Next post in topic >>