Appendix. Scrum on one page

Scrum helps a team learn while it delivers a product whose outcome cannot be known in advance. Each Sprint ends with something usable and with evidence to decide the next step. If the work can be predicted from start to finish, Scrum no longer adds distinctive value (chapter 1).

Accountabilities of the Scrum Team

• Product Owner: value. Decides what gets done, in what order and why.
• Developers, with their agents: quality. They decide how it gets done and answer for it being done.
• Scrum Master: that the team works and improves. Removes what slows it down.

Goals drive development

Each goal hangs from the one above it (chapter 15):

• Company goal: what the organization wants to achieve.
• Product Goal: what change in user behavior the product is after.
• Sprint Goal: what this Sprint contributes to that change.

The events, by what they decide

• Release Planning: how we reach the Product Goal, with one or more teams, in the fewest Sprints. It details the next three or four and leaves the rest as direction. Dates are forecast from the history of previous Sprints; they are not promised (chapters 11 and 18).
• Sprint: the shortest span that lets us learn how to continue with the product. Along the way it usually produces several Increments (chapter 12).
  • Sprint Planning: which Sprint Goal brings us closest to the Product Goal, and a credible plan to achieve it.
  • Daily Scrum: are we still on track for the Sprint Goal? If not, we replan today.
  • Sprint Review: with the people who use or pay for the product, how the release plan changes. It is not a demo: validations are obtained during the Sprint.
  • Sprint Retrospective: what we change in how we work, including with the agents.

The artifacts, by what guides them

• Coordination board, guided by the company goal. It has three levels, as in Flight Levels: strategy, coordination between teams (initiatives and dependencies) and each team's work. It shows where value gets stuck and who decides the order.
• Product Backlog, guided by the Product Goal. Everything in it exists to move toward that goal; anything that doesn't is surplus.
• Sprint Backlog, guided by the Sprint Goal. It is the Sprint plan, and it changes when what we know changes.
• Increment, guided by the Definition of Done. Only what meets it counts, whether a person or an agent wrote it (chapter 14).

Release Planning and the coordination board are not in the Scrum Guide, which leaves out the medium term so it can work in any context. With a real product and several teams, you need them.

The test

Scrum works if each Sprint leaves something usable and a decision made with evidence. If it only leaves closed tasks, it is a ticket factory.

Chapters