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

Re: [scrumdevelopment] Re: Burn Up Charts

Expand Messages
  • Mike Beedle
    David: Thank you. One thing that I missed in my post, is that the metaphor also forces a tension to arise when we try to balance the limited resources in a
    Message 1 of 64 , Apr 2, 2003
    • 0 Attachment

      Thank you.

      One thing that I missed in my post, is that the
      metaphor also forces a tension to arise when
      we try to balance the "limited resources in a time-
      box" we have, with the need to "realize the highest
      priority tasks" while we complete a meaningful
      product release.

      This tension forces a negotiating dialog between
      the Scrum Master and the Product Owner but it
      includes the pigs (committed resources
      of the team). For example, in week 2, 3, or 4 the SM
      and the PO might negotiate and re-prioritize
      and their dialog might sound like this:

      SM: "Can we live without a fix to bug X?"
      PO: "We must have the fix to X because of
      the training. We can't train the users
      without it."
      SM: (to developer) "Do you still think bug X will
      take 6 hrs?"
      dev: "Yes, but it might take more now that we know
      it was not a database problem."
      SM: "Ok, we will find that at the Daily Scrums.
      What about feature Y? Do we need Y
      for this release?"
      PO: "We can live without Y until next release but
      we still need to have it in the final release."
      SM: "Ok. Let's mark it to lower priority. If we
      have time we can still deliver it in this
      SM: Is Z still critical?"
      PO: "Yes, Z must be done."


      These re-prioritizing dialogs start typically
      on week 2 or 3 of a Sprint because like Ken said
      early, you may realize at some point by extrapolating
      the burn down chart, that there is a chance
      of not meeting _all_ of the goals (features, bugs,
      training, tool upgrades, training, conversions,
      setups, etc.), of the Sprint. (In Scrum _any_
      meaningful task is a valid task, it doesn't have
      to be a feature.)

      In Scrum we figure out what are the contents
      of a "meaningful and probable release" as soon
      as possible. You in fact may deliver more, but
      it is good practice to negotiate your lowest
      exit out of the Sprint.

      That way the expectation is set to the most
      realistic deliverable. On the other hand, if you
      end up delivering more it is all icing on the cake.

      All of the above is very typical in Scrum but
      the metaphor and the burn down chart help you --
      they force you to negotiate a meaningful release,

      - Mike

      --- David Anderson <netherby_uk@...> wrote:


      This was by far the best and clearest explanation I've
      seen or heard
      for the approach taken in Scrum. Thanks. I enjoyed
      this post a great deal.


      > 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
      > the correct metaphor. In Scrum we use the "burn
      > 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
      > has several implications:

      Yahoo! Groups Sponsor ADVERTISEMENT

      To Post a message, send it to:
      To Unsubscribe, send a blank message to:

      Your use of Yahoo! Groups is subject to the Yahoo!
      Terms of Service.
    • 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

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