Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Burn Up Charts

Expand Messages
  • Mike Beedle
    Mary: 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
    Message 1 of 64 , Apr 2, 2003

      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,

      - Mike

      --- 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
    • Dave Hoover
      Mike, ... Agreed! ... I think we struggle with researching previous art because most of the leading agile thinkers are in the trenches, not in academia.
      Message 64 of 64 , Apr 12, 2003

        > I think it is fine to assume that it is "independent
        > 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 always
        > 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.)

        I think we struggle with researching "previous art" because most of the
        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.

      Your message has been successfully submitted and would be delivered to recipients shortly.