Sprint Goal is visible and agreed
The whole team can state the Sprint Goal in one sentence from memory.
Reference guides, visual examples, and a printable Sprint health checklist for use during any Sprint.
The Sprint Board is the team's shared view of everything that matters this Sprint — what is waiting, what is in progress, what is being reviewed, and what is done. The board's value is in being read, not just maintained. A board nobody looks at is a filing system, not a communication tool.
Sprint Backlog (To Do): Stories the team committed to this Sprint that haven't started yet. These should be ordered — the next most important story sits at the top, ready to be pulled as soon as someone has capacity.
In Progress: Stories actively being worked on right now. The most important column to watch. More items here than the team has members is a warning signal — it means focus is fragmented and everything is moving slowly.
In Review: Stories that are complete from the developer's perspective and are now being reviewed — code review, acceptance testing, PO check. Items stalling here often indicate a bottleneck in the review process itself.
Done: Stories that have met all acceptance criteria and passed the Definition of Done. Nothing moves here that hasn't fully cleared the DoD — "almost done" stays in In Review.
One person finishing one story completely is more valuable than three people each taking a story to 80%. The board makes this visible: a column full of In Progress items with nothing in Done is a sign the team is starting too much and finishing too little. Pull new work only when you have capacity to see it through to Done.
This is what the QuickBite team's Sprint Board looks like partway through Sprint 1. Sprint Goal: "A customer can find a restaurant, add items to their cart, and pay." Five days in, three stories are in progress, one is blocked, and two are done.
Reading this board: 5 points done, 8 in progress (one blocked), 5 not started. The payment story is blocked — this needs immediate SM action, not a note for the Retrospective. The blocked item sitting in In Progress while new work is being pulled is the first warning signal to address.
Every burndown chart tells a story. The five patterns below cover almost every Sprint situation a team will encounter. The dashed line is the ideal — the solid line is reality. The gap between them is the signal.
Actual line tracks close to ideal. Normal day-to-day variation. The Sprint closes cleanly with the goal met.
Continue. No action needed.Flat early, steep late. Front-loaded research or refinement. Team is behind on day 5 and sprinting in week 2.
Watch for blockers at day 7. Consider descoping.Line stays high despite real work completed. New stories were added mid-Sprint without removing anything.
SM + PO enforce Sprint Goal protection now.Completely flat for 2–3 consecutive days. A specific impediment is blocking all meaningful progress.
SM escalates immediately — not next Retro.Actual stays above ideal throughout. Multiple stories incomplete at day 10. The commitment was too large.
Address in Retro. Re-size next Sprint down.Name the pattern on day 4, not day 9. The earlier you recognise what is happening, the more options the team has. A "slow start" identified on day 5 can be addressed with descoping. The same pattern identified on day 9 means the team is deciding which stories to return to the backlog in the last hour of the Sprint.
| # | Signal | What it tells you | Action |
|---|---|---|---|
| ① | Burndown above ideal at day 4 | Pacing problem compounding daily | Investigate. Consider descoping by day 7. |
| ② | Story stuck In Progress 3+ days | Blocked, underestimated, or abandoned | Ask directly. Swarm if blocked. Split if too large. |
| ③ | Same blocker two days running | SM has not escalated effectively | SM escalates with a deadline — not tomorrow. |
| ④ | WIP exceeds team capacity | Focus fragmented; everything moves slowly | Finish before starting. Pull nothing new. |
| ⑤ | Silent team — no blockers raised | Problems are being hidden, not solved | SM holds individual conversations. |
Run through this checklist at the Daily Scrum each day. A "no" to any item is a conversation to have — not a note for the Retrospective.
The whole team can state the Sprint Goal in one sentence from memory.
The next most important story is at the top, ready to be pulled when someone has capacity.
Every In Progress story has acceptance criteria written. If not, pull the PO in now.
Any story that hasn't moved in three days needs attention — not tomorrow.
In Progress items should be equal to or fewer than the number of people on the team.
At least one story should reach Done every 2–3 days in a 10-day Sprint. If nothing is Done by day 5, the team is at risk.
If above ideal on day 4, investigate cause and consider descoping before day 7.
Two flat days = a blocked Sprint pattern. The SM needs to escalate immediately.
Not at the end of the day, not at the next standup — the moment they are known.
If the same blocker appears at two standups, the SM has not escalated effectively.
If it regularly runs longer, it has become a status meeting. Redirect focus to the board.
Run through it in the first 2 minutes of the Daily Scrum by looking at the board, not by going around the room. The board answers most questions instantly. The conversation should be about what is not visible on the board — the problems nobody has raised yet.
The forecast from Session 6 updates after every Sprint. The arithmetic is the same each time.
Subtract completed points from remaining backlog
Remaining = Previous remaining − Points completed this Sprint. If scope was added, add those points back in first.
Update rolling velocity
Drop the oldest Sprint, add the new one. Use the last 3–5 Sprints. One outlier Sprint does not change the forecast — a pattern does.
Calculate new forecast range — communicate it
New remaining ÷ velocity = Sprints. Express as a range (±1 Sprint). If the forecast changed, say so proactively: what changed, why, and what the options are.