Scrum, day 25: ownership of the work

Today's objective: identify who should make a work decision, what constrains it, and how the people involved will inspect its consequences.

Read alongside: Mastering Professional Scrum, chapter 2, focusing on self-organization. Compare that older terminology with Scrum.org's explanation of self-managing teams and the current Scrum Guide. Allow roughly five minutes for this companion, plus the reading.

Waiting for permission that nobody needs to give

The fictional ShiftSwap team needs to investigate a disagreement between a request's current state and a delayed message. Two Developers could pair on the problem this afternoon. They hesitate because a delivery manager assigned each of them a different item at the start of the week.

Their proposed change supports the Sprint Goal, stays within the existing quality requirements, and does not require additional spending. Yet they wait for the manager to approve the rearrangement. The manager is unavailable until tomorrow.

The delay is not caused by a missing technical skill. It comes from an unclear understanding of who can adapt the work. If the team owns only the execution of individual assignments, it cannot respond promptly when the shared plan needs to change.

Separate direction from detailed control

The organization can establish a product's purpose, funding boundaries, and genuine operating constraints. Elena makes Product Owner decisions about value and the Product Backlog. The Developers determine how to turn selected work into a usable result and adapt their plan as they learn.

These responsibilities interact. A delivery decision that changes the expected user benefit needs discussion with Elena. A product priority that assumes unavailable skills needs discussion with the Developers. Interaction does not mean that every decision requires permission from every participant.

For the proposed pairing session, the Developers can examine the effect on the Sprint Goal and coordinate the change themselves. They can make that adjustment visible to the manager without turning visibility into an approval gate.

Understand the terminology in the book

The assigned book uses self-organization, reflecting the framework at the time of publication. The current Scrum Guide describes Scrum Teams as self-managing. That includes deciding internally who does what, when, and how.

The practical question is broader than whether people can choose a technical implementation. Can they organize their work, respond to discoveries, and take responsibility for the resulting product within clear boundaries? A team that chooses its programming language but cannot change a daily assignment has a constrained ability to do that.

Scrum.org's explanation emphasizes goals, boundaries, accountabilities, and the skills needed to act. Autonomy without those conditions can leave people uncertain about both their authority and the consequences they are expected to own.

Map a few actual decisions

ShiftSwap writes down decisions it recently delayed:

This is a local discussion aid, not a new formal Scrum artifact. Its value is in revealing where people have confused being informed, being consulted, and being responsible for a decision.

Do not make every decision a vote

Shared ownership can be misread as requiring unanimous agreement on every detail. That creates another queue. The people closest to a reversible implementation choice may be able to decide, explain their reasoning, and invite relevant feedback.

The Developers might agree that changes affecting a shared interface need consultation with colleagues using it. A small internal change can be handled by the people doing the work, within their established quality practices. More consequential or difficult-to-reverse choices deserve wider attention.

The team should choose an approach that fits the decision. It can preserve distinct accountabilities while using expertise from others. Elena does not need to ignore technical advice to remain accountable for product value, and Developers do not need to wait for Elena to assign each technical task.

Make genuine constraints explicit

One Developer lacks access to the environment needed to investigate the message sequence. That is a real constraint. Pretending the team is fully empowered does not make the missing access appear.

Radu helps identify who can resolve it and what evidence they need. The team explains the specific work blocked, the access required, and how the organization's safeguards can be preserved. The solution may be approved access, a supported diagnostic route, or a different arrangement that removes the recurring dependency.

Self-management does not mean bypassing controls or absorbing every organizational problem alone. It requires a credible way to surface constraints and work with the people who can change them.

Respond to a poor decision without reclaiming every decision

Suppose the Developers rearrange work and underestimate the impact on another item. The manager could respond by requiring approval for all future changes. That would reduce the team's ability to learn how to make better decisions.

A more useful response is to inspect what information was missed, who should have been consulted, and how the effect could have been noticed earlier. The team may improve its decision record or check dependencies before the next rearrangement.

There can be circumstances that require changing boundaries. The change should respond to a concrete risk or missing capability, with a way to reassess it. One disappointing outcome is not evidence that every future decision must move outside the team.

Examine one permission queue

Choose a decision your team routinely waits to have approved. Describe its purpose, likely consequences, reversibility, and actual constraints. Identify who is accountable, who has relevant expertise, and who simply needs to know the result.

Propose a clearer arrangement for that specific decision. If authority cannot change immediately, identify the information or conversation needed to resolve the uncertainty. Avoid declaring the whole team “empowered” while leaving the practical queue untouched.

Reflection: when your team discovers a better way to achieve its goal, can it act on that discovery? Name the smallest decision boundary that would need to become clearer for the answer to improve.

Next, day 26 examines how people use that authority to work across specialties.