Scrum, day 07: how the framework fits together

Today's objective: connect Scrum's accountabilities, events, artifacts, and commitments to one product decision.

Read alongside: Scrum: A Pocket Guide, fourth edition, §§2.1–2.4, from “The house of Scrum” through “Framework, not methodology.” Keep the Scrum Guide available to locate the elements mentioned here. Allow roughly five minutes for this companion; spread the book sections over another session if needed.

Follow one Sprint from purpose to feedback

The fictional ShiftSwap team is preparing the second-café pilot described in day 06. We will walk through one possible Sprint to see how the framework's parts work together. The numbered days in this reading series are lessons, not individual Sprints.

For this walkthrough, the team's Product Goal is that employees at the first two cafés can arrange eligible swaps and tell when they are final without a manager reconstructing conversations. This describes a future condition the team wants the product to support. Day 10 will examine how to make that direction useful for planning and evaluation.

The next Sprint concentrates on the second café's approval flow. In this example, the team uses two-week Sprints. Two weeks is its choice; Scrum allows a fixed Sprint length of one month or less. The Sprint contains the other events and the work between them. Scrum.org's Sprint reference explains that boundary.

Understand who is accountable for what

Elena, the Product Owner, discusses the pilot evidence with employees and managers and orders the Product Backlog accordingly. It contains possible product improvements, including clearer approval responsibility and a more discoverable decline explanation. She is accountable for maximizing the product's value and for effective management of that backlog.

The Developers bring the skills needed to create the usable change. Here that includes interface design, implementation, testing, and operational work. They decide how to deliver it and keep their plan current. Calling them Developers in Scrum describes an accountability; it does not mean that everyone must have a software-programmer job title.

Radu, the Scrum Master, helps the team use Scrum effectively and improve its practice. When access to the test environment repeatedly prevents completion, he helps address that impediment with the people who can change it. He does not need to assign everyone's daily tasks to perform that service.

These accountabilities coexist in one Scrum Team. They give decisions a clear home while leaving plenty of work to do together. The Scrum Team section of the Guide is the reference for their full definitions.

Connect the work to three commitments

During Sprint Planning, the whole team establishes a Sprint Goal: employees at the second café can distinguish a pending request from a final arrangement, including during a supervisor handover. The Developers select relevant work in discussion with Elena and plan how to complete it.

Three artifacts make different aspects of the work visible. Each has an associated commitment:

The names matter because the objects serve different decisions. A list of completed tasks cannot establish whether the product is usable. A usable change alone cannot tell the team whether it is pursuing a worthwhile direction. The artifact commitments in the Scrum Guide connect those questions without making them interchangeable.

Adapt the work while the Sprint is running

On the third working day, a Developer discovers that the current supervisor cannot see which requests were left pending by the previous supervisor. At the Daily Scrum, the Developers inspect progress toward the Sprint Goal and adjust their plan. Two people work through the handover together while another finishes an already-started verification task.

If their discovery changes the scope they expect to complete, they discuss the trade-off with Elena. The Sprint Goal helps them decide which work matters most. Their initial task list can change as they learn more about achieving it.

Refinement of possible future work also continues during the Sprint. Someone may clarify a later reporting request or split a large improvement into smaller options. Refinement is an ongoing activity, not an additional mandatory Scrum event. The team chooses useful techniques for doing it.

Inspect the result and the way of working

When the approval change meets the Definition of Done, it contributes to a usable Increment. The team can release it to the pilot before the Sprint Review if that is an appropriate product decision. It does not need to hold a usable result until that event.

At the Sprint Review, the team and stakeholders examine the result and what they have learned. The café manager walks through the handover, employees discuss the remaining confusion, and Elena considers how that evidence affects future work. A demonstration supports this conversation, but an applause-only presentation would miss the decision about what comes next.

At the Sprint Retrospective, the Scrum Team examines how it worked. It notices that the environment delay from day 05 persisted and chooses an improvement to try. The Review concerns the product and its future; the Retrospective concerns improving quality and effectiveness in the team's work. Scrum.org's event overview provides a useful comparison.

The next Sprint begins after this one ends. Feedback changes the next plan, and the product provides a firmer starting point than the team had before.

Distinguish the framework from your implementation

ShiftSwap might use a digital board, pair programming, examples written in plain language, and automated deployment. Those practices can help the team. Scrum does not prescribe a particular board, estimation scale, story template, or deployment tool.

The framework still has defined accountabilities, events, artifacts, and commitments. Choosing useful supporting practices is different from quietly removing the opportunities to inspect and adapt. A team that retains the meeting names while avoiding product feedback loses something essential to this example.

Reconstruct the loop

Take a recent product change and draw its path from a longer-term goal to a usable result and then to the next decision. Add who was accountable, what information was visible, and where feedback could change the plan.

Circle a point where information was missing or arrived too late. Name the conversation or change in working practice that could improve that point. A diagram is useful only if it helps you see a real decision more clearly.

Reflection: which part of your current process produces information that no one uses? What would need to change for that information to influence the product or the team's work?

The next companion looks at the behavior needed when the information is uncomfortable to share.