Re: Velocity: Measuring Actuals
- Hi Paul,
Here's some observations that have given me clarity in teaching and
coaching Scrum teams:
1. Core hours I have used as real time hours for the work days of the
Sprint minus one day for beginning and end of Sprint meetings.
2. The task hours estimates for burn-down are typically in ideal
hours. This is implicit, not explicit.
3. I have found that when the initial burn-down estimates equals the
core hours, about half the estimated work gets completed.
4. So we have a predictable 50% ratio. I think this corelates with
research from value mapping in Lean organizations where the best ratio
of touch-time to clock-time is about 50%.
5. Velocity is a different idea. It is used to decide to stop adding
Stories to a Sprint Plan. Using Mike Cohn's model, velocity is
expressed as "Story Points per Sprint", where a Story Point is a unit
of size. The size unit remains an invarient and the the velocity can
be compared over multiple Sprints. There are three factors affecting
- team membership
- business domain
Keeping these stable permits more intuative knowledge, flow and
improved velocity. Change any of them and the velocity will most
likely decrease as the changes are integrated and then flow can be
For how to do Story Point estimating I suggest reading Mike Cohn's
books. In his first book he described a point as being ideosyncratic
to one team on one project. In his second book he discusses how to
have some consistency of what a point means across teams and projects.
I agree with Stephen about the units (or beans). The bottom line is
whether the team and the other stakeholders are taking the concept
"commitment" seriously. Velocity is the key to achieving that and
thereby building trust - they key to Scrum's value.
I think it helps to be precise about the value and limitation of two
- Burn-down informs the team countinuously on whether they are
likely to meet their commitment - nothing else.
- Velocity informs the team of what size of commitment to make in
the future - nothing else.
Call or write if I can be of more help.
--- In email@example.com, "Arrowood, Paul \(ELS-STL\)"
>available core hours, and ticked off the tasks needed to fulfil the
> We just made a switch last Friday. We identified the developer's
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
>[mailto:firstname.lastname@example.org] On Behalf Of Stephen Bobick
> From: email@example.com
> Sent: Wednesday, September 27, 2006 12:37 AMnot in "real time", and it is preferable, IMO, to call them something
> Yes, you do decompose backlog items into tasks but the estimates are
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.
><mailto:P.Arrowood@...> > wrote:
> -- Stephen
> On 9/26/06, Arrowood, Paul (ELS-STL) <P.Arrowood@...
>in some Scrum documentation yesterday that you decompose agreed-upon
> Isn't this counter to what Jeff Sutherland says? I thought I read
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 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 firstname.lastname@example.org, "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 email@example.com, "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/>