Re: [scrumdevelopment] Re: Burn Up Charts
- Hi everybody,
preamble: if a burn-up chart helps (in any way) a team more than a burn-down chart then just use it! :)
> If the team has little control over the backlogCan we really say that a project where the team has little control over the backlog is a Scrum project?
> We described the burn-up chart in terms of features (e.g.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.
> 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.
It seems to me this is one of the common difficulty for those addicted to pert charts while Scrum (and any other agile approach I think) is supposed to use an empirical approach. I don't remember it exactly but I'm quite sure that also Ken and Mike wrote something about this in their book.
> As I read them, the burnSorry 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 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.
Ken, Mike: am I wrong? (maybe!)
Marco Abis - CEO & Chairman
Agility SPI: Software Process Improvement
abis@... - abis@...
> 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.