We just made a switch last Friday. We identified the developer s available core hours, and ticked off the tasks needed to fulfil the customer story cards (inMessage 1 of 51 , Oct 2, 2006View Source
We just made a switch last Friday. We identified the developer’s available core hours, and ticked off the tasks needed to fulfil the customer story cards (in ½ and full-day units only) until there were no more hours left. We’ll not really track the hours (and whether they were right), but will burn down the # tasks (maybe even in ½ units) over the 1-week iteration. Sound workable? Any final suggested tweaks?
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Stephen Bobick
Sent: Wednesday, September 27, 2006 12:37 AM
Subject: Re: [scrumdevelopment] Re: Velocity: Measuring Actuals
Yes, you do decompose backlog items into tasks but the estimates are not in "real time", and it is preferable, IMO, to call them something else: beans, units, whatever. The important thing is knowing how many "work units" a team can do in a sprint, not how many hours/days each task takes. You are committing to everything by the end of the iteration, and the estimates of effort are only used to make sure the promised work is doable so you can feel confident in making the commitment to complete it.
On 9/26/06, Arrowood, Paul (ELS-STL) <P.Arrowood@elsevier .com> wrote:
Isn't this counter to what Jeff Sutherland says? I thought I read in some Scrum documentation yesterday that you decompose agreed-upon stories into 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 maybe you're suggesting an alternative?
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 andMessage 51 of 51 , Oct 2, 2006View SourceHi 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/>