Re: [scrumdevelopment] Re: Burn Up Charts
- View SourceThanks for the link Marco,
getting a clearer picture of the emphasis on a burn down chart (focusing
on reduction of backlog instead of progress).
The issue I identified with burn down charts, which started us toward
looking at alternatives, is reflected in pages linked from your reference.
On http://www.controlchaos.com/sburndown.htm I find the following:
"The velocity of work is the slope of the burndown graph at any point in
time: Velocity of work = amount of work completed/number of days to
On a different page, http://www.controlchaos.com/burndown.htm , I read
"Plot the slope of the backlog. If you draw a line representing average
slope over a period of time, you can project it to determine when no
work is likely to be left."
The problem is that during the lifetime of the burn down chart, the
amount of work being charted doesn't remain constant (especially when
used on larger granularities, as for releases). When the work being
charted fluctuates, the line no longer represents just work completed,
it's an undifferentiated measure of both work completed and backlog
change. The slope is no longer a measure of velocity as calculated
above. We wanted to split these two measures so that each (especially
velocity) could be considered separately.
I should ask, though, is the term "velocity" used differently in Scrum
than I'm used to from XP? It wouldn't appear so from the above quote,
but maybe things fall into place better if this is viewed as "velocity
of backlog reduction" instead of "velocity of work"?
Do you have other links to suggest, or a FAQ (especially ones intended
to explain Scrum in terms of XP, rather than "traditional" or "normal"
- View SourceMike,
> I think it is fine to assume that it is "independentAgreed!
> thinking". This is a good thing because it confirms
> that at least 2 people can reach the same conclusions
> and can validate their experiences and explain
> the world the same way.
> (You could alwaysI think we struggle with researching "previous art" because most of the
> ask the question the other way: Is the stuff
> from "Growing Software" coming from somewhere else
> since our stuff was published 5-7 years ago
> i.e. PLOP3 proceedings, PLOPD4 book, etc. I think
> it is safe to assume "independent thinking" because
> our industry is famous for not researching
> "previous art". In hard Science this would actually
> be an embarrassment.)
leading agile thinkers are in the trenches, not in academia. This is why I was
excited when I saw the overlap between the Scrum book and "Growing
Software". I figured that both the Scrum folks and Roy had probably not had
the opportunity to find each other.
I look forward to the outcome of future collaborations between agile thinkers
who find complexity science applicable to software development.