HKSM

A Sprint Burndown or Burnup Chart is a time-based visual that tracks work in a sprint: burndown shows remaining work, burnup shows completed work against total scope. It is created from the Sprint Backlog at Sprint Planning and updated daily to provide transparency, forecast completion, and expose scope changes.

Key Points

• SBOK tracking artifact created at Sprint Planning and updated daily during the sprint.
• Burndown plots remaining work; burnup plots completed work versus total scope to reveal scope change.
• X-axis is sprint days; y-axis is a single metric such as story points, task hours, or count of tasks.
• Developers maintain the chart; it is visible to the Product Owner and stakeholders for transparency.
• Updates only when items meet the Definition of Done; avoid partial credit to keep signals clean.
• Used as input to Daily Standup, Demonstrate and Validate Sprint, and Retrospect Sprint.

Purpose

The chart provides a simple, shared view of sprint progress so the team can inspect and adapt quickly. It helps forecast if the sprint goal is achievable, highlights blockers, and makes scope changes visible to everyone.

As an Input/Output across SBOK processes, it is created from the Sprint Backlog, updated during Daily Standup, and referenced in the Sprint Review and Retrospective to inform decisions and improvements.

Key Terms & Clauses

• Sprint Backlog: The committed work for the sprint used to baseline the chart.
• Work Remaining (burndown): The amount of effort left in points, hours, or tasks.
• Work Completed (burnup): The cumulative sum of done work aligned to the Definition of Done.
• Ideal Trend Line: A simple linear guide; not a target to enforce.
• Scope Change: Adjustments to total scope; burnup makes this explicit by changing the total-scope line.
• Velocity/Throughput: Empirical delivery rate used to interpret chart trends and forecast outcomes.
• Information Radiator: The chart must be visible and easy to read for the whole team and stakeholders.

How to Develop/Evaluate

1. Choose chart type (burndown or burnup) and a single metric for the sprint (story points, hours, or task count).
2. Establish a baseline from the Sprint Backlog (sum of estimates) at Sprint Planning.
3. Draw axes: days on the x-axis; chosen metric on the y-axis. Add an ideal trend line for guidance.
4. Update daily after work meets the Definition of Done; avoid partial updates on in-progress items.
5. Annotate scope changes: adjust the total-scope line (burnup) or the baseline (burndown) and record the reason.
6. Evaluate slope and patterns: steep drops indicate steady completion; flat lines signal blockers; rising scope may threaten the sprint goal.
7. Forecast completion by projecting the current trend; raise risks early in the Daily Standup.

How to Use

• Daily Standup: Inspect the chart to identify impediments and replan the next 24 hours.
• With the Product Owner: Discuss scope changes and negotiate swaps to protect the sprint goal.
• Sprint Review: Explain actual progress and any scope adjustments to stakeholders.
• Retrospective: Analyze estimation accuracy, blocking patterns, and update working agreements.
• Reporting: Share as an information radiator on a wallboard or tool dashboard for transparency.
• Multi-team coordination: Use team-level charts and, if needed, a simple aggregate to align dependencies.

Example Snippet

Two-week sprint, 10 days, baseline 40 story points.

• Day 1: Baseline 40. Burndown starts at 40; burnup shows 0 of 40 done.
• Day 5: Team has 22 points done; burndown shows 18 remaining; trend suggests on track.
• Day 7: Product Owner adds a small change; total scope increases to 44. Burnup total line jumps to 44.
• Day 10: 40 points done, 4 not finished; remaining items return to the Product Backlog for future sprints.

Risks & Tips

• Do not use the chart to judge individual performance; it is a team accountability tool.
• Inconsistent updates or giving partial credit creates noise and harms forecasting.
• Large tasks cause stair-step patterns; break work into small, testable tasks.
• Prefer burnup when scope may change; it separates delivery rate from scope growth.
• Always tie conversations to the sprint goal; adjust scope rather than pushing overtime.
• Annotate major events (impediments, scope changes) directly on the chart for context.

PMP/SCRUM Example Question

Mid-sprint, the team's burnup chart shows the completed-work line flat for two days while the total-scope line jumped from 40 to 46 points. The team worries about missing the sprint goal. What should the Scrum Master do first?

1. Ask the team to work overtime to match the original trend line.
2. Facilitate a discussion with the Product Owner to remove or defer lower-priority items and adjust the Sprint Backlog while keeping the sprint goal intact.
3. Re-estimate all user stories so the chart realigns with the ideal line.
4. Cancel the sprint immediately and start a new sprint with the increased scope.

Correct Answer: B — Facilitate a discussion with the Product Owner to remove or defer lower-priority items and adjust the Sprint Backlog while keeping the sprint goal intact.

Explanation: The chart signals scope increase and a stall. The Scrum Master should enable scope negotiation with the Product Owner to protect the sprint goal, not force overtime, re-estimate to fit a chart, or cancel without cause.