Re: [scrumdevelopment] Burn Up Charts
I hear what you are saying about the convention
to associate "going up" with "being positive". It is
definitely part of the "metaphors with live by
or with", that of course is another metaphor itself
i.e. Lakoff et. al. stuff.
However, in my view, burn-up charts have a few
conceptual disparities with regards to Scrum and
Scrum values specially in the sense of not reinforcing
the correct metaphor. In Scrum we use the "burn down"
metaphor, as a match that burns, or as gas tank that
is being emptied, to reinforce the fact that we
have "limited resources in a time-box". This metaphor
has several implications:
* in Scrum we create urgency by knowing
"what is left to be done", and quickly
strategizing, planning, reconfiguring,
and acting in order to accomplish the goal.
But burn-up charts don't highlight "what is
left to be done", and therefore don't support
the same metaphor.
* In Scrum we know we are done when there is
nothing left to do. But in contrast
burn-up charts measure activity and
* in Scrum is very typical that the Sprint backlog
surpasses the original estimates because of
the constant cycles of creativity/research and
issue resolution. In a a burn-down chart we
hide the "moving target" aspect of the project,
because to Scrummers what is important is to
reach zero tasks to be done. And this is a
well-defined goal for every Scrum project.
But burn-up charts would potentially show
different goals on a daily basis, i.e.
the target is 640 the first day, but
that it could be 770 a week later, and 350 the
week after that. These charts with
different slopes could be confusing to understand
the true Scrum goal:
zero tasks and/or zero hours
to be done.
* Lastly, in Scrum we strongly believe in
strict time-boxing. Whatever is not done in
one Sprint is carried to the next Sprints, but
not necessarily to the next Sprint, because
tasks are executed in "business priority".
By highlighting what was not done, the burn-down
charts reinforce the concept of rescheduling
into other Sprints.
In contrast, this is not highlighted in
in burn-up charts.
Anyhow, these is what my tired eyes see,
--- Mary Poppendieck <mary@...> wrote:
> Hello Scrum Users,
> I was at the Silicone Valley User's Group meeting
> last week and after the
> meeting a discussion occurred around burn-down
> charts. The group has a
> problem with the Scrum charts because they trend
> down rather than up
> (perceived by developers as negative), and more
> particularly, because they
> measure two things at once: both the team's
> velocity and the change in the
> backlog. If the team has little control over the
> backlog, the thought is
> that they would prefer to see the two charted
> separately, and as a burn-UP
> chart. Below is one possible example (hopefully you
> can see this chart):
> What do Scrum users think about this?
> Mary Poppendieck
> www.poppendieck.com <http://www.poppendieck.com/>
> Author of
> Lean Software Development: An Agile Toolkit
> 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.