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

Re: [scrumdevelopment] Re: Burn Up Charts

Expand Messages
  • Russ Rufer
    ... Could you describe (or point to a FAQ or article) how you make estimates of staff time to determine y position on the burn down chart. I m especially
    Message 1 of 64 , Apr 2, 2003
      Marco Abis wrote:

      > > We described the burn-up chart in terms of features (e.g.
      > > rough estimates of cumulative story points) because relative difficulty
      > > of features is more easily (and accurately) estimated than staff days.
      > >
      > > A primary goal of the burn up chart is to illustrate the need (or
      > > opportunity) for scope negotiation, and to make these historical
      > > negotiations clear and distinct from changes in velocity.
      > >
      > > Measuring against planned features makes feature adjustment the easiest
      > > and most natural response to a projected problem.
      > This is exactly what you are supposed to do with the Scrum burn-down
      > chart: duration is not considered, the only important thing you have to
      > track to be able to "empirically" manage the project is the remaining
      > work (and date). I know it is easy to confuse this with time reporting
      > but Scrum do not even consider the amount of time a team work. The only
      > tracked thing are goals.

      Could you describe (or point to a FAQ or article) how you make estimates
      of staff time to determine y position on the burn down chart. I'm
      especially interested in how this is done at project inception and how
      adjustments to the estimate are reflected on a burn down chart over the
      course of a project.

      Suppose you over estimate staff time early and re-estimate as the
      project progresses. Do you toss out your old burn down chart? If you
      just continue to extend the existing chart, it would seem that the more
      rapidly descending line would be indistinguishable from an increase in
      team velocity (or a reduction in scope for that matter).

      > > As I read them, the burn
      > > down chart shows how much money (~staff time) the project expected to
      > > spend at a series of historical points. The burn up chart shows
      > > historical progress toward a planned feature set.
      > Sorry but this is a misrepresented view of Scrum burn-down charts. In
      > Scrum you track the remaining work (to achieve a goal) to be able to
      > manage the project in its cost, date, quality and functionality. This
      > quantitative view let's you (with your customers) make tradeoffs between
      > these four variables but it always track remaining work and not duration
      > or money.

      In terms of the four management axes you list, I interpreted the burn
      down chart as a measure of cost vs date (cost as consumption of limited
      staff hours which some but not all stakeholders will associate with
      budget). I see the burn up chart as measuring functionality vs date.

      The goal of the burn down chart is prediction. It shows a historical
      trend that lets you make reasonable guesses about the future which in
      turn serve as the basis for making tradeoffs in your long term plans.

      With changes in staff composition, velocity, and scope all reflected by
      changes to one line, can any be distinguished from the others? If not,
      it seems you've lost empirical data that could be quite useful in making
      tradeoff decisions.

      Can those using burn down charts mention whether this is ever a
      difficulty in practice (please include details of project size and

      I found David Anderson's explanation for smoothing features in
      Cumulative Flow Diagrams on large projects quite illuminating. It makes
      perfect sense once you see it and have a rough understanding of the
      project size it works for. I'm interested if there's a similar
      phenomena for burn down charts. I just don't see it yet (at least not
      the same kind of statistical smoothing) because the prerequisite of a
      tendency toward a norm with small deviation wouldn't seem to apply.

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