Re: [scrumdevelopment] Re: Burn Up Charts
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
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
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,
--- 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 "burndown"
> metaphor, as a match that burns, or as gas tank thatmetaphor
> 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.
> 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.