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

Re: [scrumdevelopment] Burn Up Charts

Expand Messages
  • David J. Anderson
    Mary, Can you clarify my understanding of your chart? As I see it, it is showing the number of Features completed against a target of the total Features in the
    Message 1 of 64 , Apr 1, 2003
    • 0 Attachment
      Mary,

      Can you clarify my understanding of your chart?

      As I see it, it is showing the number of Features
      completed against a target of the total Features in
      the scope. Is this correct?

      i.e.

      It does not show the number of man hours (or man days)
      as is shown in the Scrum charts in Ken and Mike's
      book.

      Hence, your chart would be a departure for Scrum. It
      shows client-valued output, rather than level of
      effort required to complete a deliverable.

      David
      --
      David J. Anderson
      http://www.uidesign.net
      Agile Interface Design

      --- 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):
      >


      __________________________________________________
      Do you Yahoo!?
      Yahoo! Tax Center - File online, calculators, forms, and more
      http://platinum.yahoo.com
    • 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
      • 0 Attachment
        Mike,

        > 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.

        Agreed!

        > (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.

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