Re: [scrumdevelopment] Re: Velocity: Measuring Actuals
- Hello Steve, thanks for sharing your thoughts. On Tuesday, September
26, 2006, at 6:35:21 PM, you wrote:
> Isn't this merely how some compute the burndown? "I put about 8 hours intoYes, but hours aren't burndown. Accomplishments are. A team that
> this, I see another 6 hours to go." Add it up, stick it on a chart, and you
> have a nifty way of seeing how the sprint is going. I see that if you
> merely rolled it up and reported it up the chain that is could be used for
> evil, but if we use it for good..
focuses on hours isn't focusing on getting things done. Tracking
hours makes it "OK" to do whatever you're doing so long as you're
keeping the hours up to date.
The point of the Sprint or iteration is getting backlog items done,
not getting tasks done. Tracking hours, in my experience, obfuscates
that key fact.
And thirdly, the Code is more what you'd call guidelines than actual rules.
- Hi Victor, Paul et al,
Let me add a thought.
I found a straight forward solution to this in practice -
The Stories commited for the Sprint are numbered 1 and up and placed
on the task board from left to right. The Tasks are placed below them
in the Not-Started row.
Train and coach the team members to ask one question whenever they
have a break in their activity: "What can I do to advance any
incomplete task on Story 1 and then higher numbered stories in order?"
The result is team members focus on completeing the highest priority
stories over completing tasks alone. Hopefully that means they are
delivering the most value sooner.
If the work is too siloed this can be a problem, but that can be an
opportunity for cross training as an investment in effective story
completion in the future.
--- In email@example.com, "Victor Szalvay" <victor@...>
> I know Ron, Stephen, and Boris have responded to this point, but
> indulge me here:
> Yes, the original Scrum approach is to break backlog items into tasks,
> then the team burns down task hours until they are "done" with the
> sprint. This is how it reads in the books and in the popular online
> This has some serious flaws though. In my experience (and that of
> others) new Scrum teams have a very hard time focusing on getting
> product backlog items (PBIs) 100% done by the end of the sprint. This
> is largely because they decompose the PBIs into tasks, distribute the
> tasks amongst themselves and then break off to work on the various
> tasks. Yet rarely do new Scrum team member pause to consider the
> bigger, more important question: are we making progress on completing
> features/PBIs to the 100% satisfaction of our product owner?
> Imagine this scenario: the sprint time box has ended and it is time
> for sprint review. Before the sprint review, the team members look up
> at their highly visible burndown chart and see that they are about 5%
> of the tasks remaining to be done.
> Tell me if this team can answer the following question based on this
> burndown chart:
> "How much value have we delivered this sprint to the product owner?"
> You cannot answer this question because, as it happens, many new scrum
> teams have a tendency to finish backlog items to a 90% state. How
> much value does a 90% done PBI bring to the product owner? Answer:
> alsmost none. What if instead of progressing all PBIs to a 90% state,
> the team instead made darn sure half of the PBIs in the sprint were
> 100% done? In this case the PO would receive the value of the 100%
> complete items. This is very much based on lean thinking.
> I hope this helps,
> -- Victor Szalvay
> --- In firstname.lastname@example.org, "Arrowood, Paul (ELS-STL)"
> <P.Arrowood@> wrote:
> > Thanks for you comments, Ron Jeffries. On Tuesday, September 26,
> 2006 6:20
> > PM, you wrote:
> > >>> ...hours aren't burndown. Accomplishments are. A team that
> focuses on
> > hours isn't focusing on getting things done. Tracking hours makes it
> "OK" to
> > do >>>whatever you're doing so long as you're keeping the hours up
> to date.
> > The point of the Sprint or iteration is getting backlog items
> > getting tasks done. >>>Tracking hours, in my experience, obfuscatesmaybe
> that key
> > fact.
> > Isn't this counter to what Jeff Sutherland says? I thought I read
> in some
> > Scrum documentation yesterday that you decompose agreed-upon stories
> > tasks (which are estimated in hours or fractional days). You fill
> up the
> > iteration using hours from those tasks, stopping once you've
> allocated as
> > many hours as are available. Did I misinterpret something? Or
> > you're suggesting an alternative?
> > Cheers,
> > Paul Arrowood
> > <http://agile-arrowood.blogspot.com/>