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

Re: [scrumdevelopment] Re: Burn Up Charts

Expand Messages
  • Russ Rufer
    Thanks for the link Marco, ... I found most of this quite familiar from an XP perspective, but I am getting a clearer picture of the emphasis on a burn down
    Message 1 of 64 , Apr 3 2:09 AM
    View Source
    • 0 Attachment
      Thanks for the link Marco,

      > http://www.controlchaos.com/manage.htm

      I found most of this quite familiar from an XP perspective, but I am
      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
      complete work."

      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"
      projects).

      - Russ
    • 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 6:46 AM
      View Source
      • 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.