Burnup vs. Burndown

If a Sprint Backlog was non-emergent, a burn-up chart would provide no advantage. However, if the work on a backlog is significantly added, re-estimated, or removed, it can be useful to visualize this by plotting a second line which the burn line then ought to approach.

If there are no significant backlog adjustments worth tracking, then merely recording a burndown of work to zero can provide adequate transparency.

Hi, thanks. But, even if there is a significant amount of change with the backlog, then a burndown line would still show this (as would a burnup)..?

Richard,

For the typical one and two-week sprints, I personally consider Sprint Burnups and Burndows less useful.

However, for a RELEASE plan spanning multiple sprints, burnup and burndown charts are very useful for tracking the done work (burnup) or remaining work (burndown) over time. This gives an empirical visual clue (the trendline) about hitting or missing the deadline.

The benefit of a Release (aka. Product) BurnUP (compared to a BurnDOWN) Chart is that If you have to add more work in the Product Backlog during the release project (i.e. over multiple sprints), the resulting Burndown unfortunately hides this. For example, If your team completed 10 points of work in a sprint, but the Product Owner added 10 points in the Product/Release Backlog, the resulting Burndown curve for the sprint would look like a flat horizontal line (+10 points added - 10 points done = 0).

To avoid the "flat line" issue with a Burndown chart, one could lower the target level (origo) as much as new work is added. (In the example above, we should move origo to -10, as 10 points are added in the product/release backlog). Then, the burndown curve looked realistic, actually showing -10 points of work done, and the new release target being 10 points further down than before.

Burnup Chart makes managing the situation above easier. Instead of lowering origo (that is not very elegant nor practical), we can simply erase and draw a new release target line 10 points higher (a horizontal line showing the targeted total amount of work before the deadline).

Just remember that adding more work into an ongoing project - without removing equal amount of less valuable work from the product/release backlog  - is usually just wishful thinking (that should be avoided). In that sense, choosing between a Burndown and Burnup Chart is mostly a matter of the Scrum Team's personal preferences.

The Burndown is from a known start point (Story Points, PBI's, Hours of effort) to 0.

The Burnup chart shows expended (Story Points, PBI's, Hours of effort) from 0.

If you have a traditional water fall approach where the PBI's are in fact "locked in requirement items" which are immutable then the total number is fixed at commencement. That's Waterfall dressed as Scrum via incremental releases.

Scrum is based on each Increment teaching you things you didn't know yet.

So during Sprint 1 you know "we need a website" - you build one. A Developer can add content to it.

During the Review you learn it needs additional functionality and users other than the developer need to add content.

• You've released something intentionally incomplete
• You've learned from that release
• You have even more opportunity to learn because there is some form of working product to use to engage stakeholders
• Your PBI's have gone from 5 to 35 at the first Sprint Review (but 4 were completed during Sprint 1)
• You expect more PBI's to emerge every sprint for a few sprints to come