Re: [scrumdevelopment] Re: Burn Up Charts
- Marco Abis wrote:
> > We described the burn-up chart in terms of features (e.g.Could you describe (or point to a FAQ or article) how you make estimates
> > 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.
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 burnIn terms of the four management axes you list, I interpreted 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.
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
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.
> I think it is fine to assume that it is "independentAgreed!
> 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 alwaysI think we struggle with researching "previous art" because most of the
> 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.)
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.