The Scrum Big Picture

Read the map as one system, not a pile of ceremonies. Accountabilities decide who owns what. Artifacts make work and progress visible. Events are the inspect-and-adapt loop that keeps the three commitments lined up: Product Goal, Sprint Goal, and a Done Increment.

How the pieces connect

1. Product Goal
2. Product Backlog
3. Sprint Planning
4. Sprint Goal
5. Daily Scrum
6. Increment
7. Sprint Review
8. Sprint Retro

One Scrum Team, three accountabilities

Product Owner, Developers, and Scrum Master are accountabilities on one Scrum Team — not three departments. The team is self-managing within Scrum: they decide who does what, when, and how, toward the Sprint Goal.

• Product Owner — Product value, Product Goal, Product Backlog ordering. Makes trade-offs visible. Says no (or not now) so the team can say yes to a coherent Sprint Goal.
• Developers — Sprint Backlog, how work gets Done, quality of the Increment. Forecast what they can complete, swarm toward one Sprint Goal, and update the plan as they learn.
• Scrum Master — Scrum effectiveness — coaching the team and the wider organization. Teaches the why behind events, removes impediments, and protects focus without becoming the boss of the work.

Artifacts and their commitments

• Product Backlog (commitment: Product Goal). The ordered list of what might improve the product. It exists to achieve the Product Goal — not to park every request forever.
• Sprint Backlog (commitment: Sprint Goal). The Developers' plan for this Sprint: the Sprint Goal, the selected Product Backlog items, and an actionable plan for delivering them. The plan can change; the Goal should stay coherent.
• Increment (commitment: Definition of Done). The usable, quality-bar slice of product created during the Sprint, added to previous Increments. If it is not Done, it is not an Increment — it is unfinished work.

How Product Goal, Sprint Goal, and Increment relate

These three nest. If they do not line up, the team can be busy every day and still have no story stakeholders can follow.

1. Product Goal — The longer-term destination for the product. The Product Backlog is the path; this is why the path exists.
2. Sprint Goal — Why this Sprint exists — one coherent objective the team could miss even if some tickets close. It is a step toward the Product Goal, not a dump of unrelated stories.
3. Increment — Usable evidence that the step happened. Stakeholders inspect it at the Sprint Review and help adapt what comes next.

When each event creates clarity vs. when it drifts

• The Sprint (A fixed container (typically 1–4 weeks) that holds all other events). Creates clarity: A time-box creates focus: start together, finish together, inspect together. When it drifts: A mini-waterfall inside the Sprint, stretching the Sprint when work is not Done, or treating the Sprint as a reporting period instead of a learning loop.
• Sprint Planning (Start of the Sprint — why, what, and how). Creates clarity: The team leaves with a Sprint Goal, a selected slice of the Product Backlog, and a plan the Developers own. When it drifts: Loading tickets with no Sprint Goal; the Product Owner dictating how; planning until every hour is allocated and nobody can absorb discovery.
• Daily Scrum (Every working day of the Sprint — 15 minutes, Developers). Creates clarity: Inspect progress toward the Sprint Goal and adjust the next 24 hours. People talk to each other, not at a board. When it drifts: A status report to the Scrum Master, a 45-minute stand-up, or a ticket-by-ticket recitation with no mention of the Sprint Goal.
• Sprint Review (End of the Sprint — inspect the Increment with stakeholders). Creates clarity: Working product in the room (or on screen). Stakeholders help adapt the Product Backlog. Progress toward the Product Goal is honest. When it drifts: A slide-only demo, no real stakeholders, or treating Review as a sign-off gate instead of an inspect-and-adapt conversation.
• Sprint Retrospective (After Review, before the next Planning — people, process, tools). Creates clarity: One concrete improvement with an owner, tried in the next Sprint. When it drifts: Skipped under schedule pressure, a blame session, or a parking lot of ideas that never become an experiment.

Common anti-patterns and healthier alternatives

• The Scrum Master “runs the meetings.” Healthier: The Scrum Master coaches the team to run their own events. Developers own the Daily Scrum.
• The Product Owner is a stakeholder request queue. Healthier: The Product Owner orders work by Product Goal and outcomes, and makes insertion cost visible.
• No Sprint Goal — just a list of stories. Healthier: One coherent Sprint Goal that could fail even if some tickets complete.
• Velocity as a performance KPI. Healthier: Use Sprint Goal success, cycle time, quality, and customer/business outcomes.
• Carry-over is “normal” every Sprint. Healthier: Inspect slicing, forecasting, interruptions, and whether Done is actually Done.
• Stakeholders stuff scope mid-Sprint. Healthier: New asks go to the Product Backlog. Trade-offs go through the Product Owner. The Sprint Goal stays protected.
• Definition of Done is optional (“we’ll test next Sprint”). Healthier: If it is not Done, it is not an Increment. Quality is part of “done,” not a later phase.
• The Retro is a complaint hour with no follow-through. Healthier: Pick one improvement, name an owner, and check it in the next Retro.

This map is original teaching language from The Agile Forum, grounded in the Scrum Guide (2020). It is not a substitute for the Guide, and it is not a certification syllabus. scrumguides.org