Scrum, day 11: Product Owner decisions

Today's objective: distinguish Product Owner accountability from personally performing every product-management task.

Read alongside: the Product Owner section of the Scrum Guide and Scrum: A Pocket Guide, fourth edition, §2.5, focusing on the Product Owner. Allow roughly five minutes for this companion, plus the assigned reading.

Three reasonable requests arrive together

The fictional ShiftSwap team is preparing its next Sprint. Employees at the second café can now see when a swap is final, but some still ask the manager what to do after a request is declined. Elena, the Product Owner, receives three requests in one morning.

An employee wants the decline explanation displayed beside the request. A manager wants automatic reminders for pending approvals. A sponsor wants a dashboard showing usage across cafés before an upcoming business meeting.

Each request has a plausible benefit. The team cannot treat all three as its most important next step. Its Product Goal concerns dependable swaps at the first two cafés, including reducing the manager's need to reconstruct conversations.

Elena's accountability gives this decision a clear home. As Scrum.org explains, the Product Owner is accountable for maximizing product value and effective Product Backlog management. That requires product judgment and communication, not merely maintaining a tidy list of tickets.

Find the decision behind each requested feature

Elena asks the employee to walk through a recent declined request. The explanation existed, but the employee could not find it and did not know whether to invite another colleague or change the requested shift.

The manager's reminder request concerns a different delay: supervisors sometimes leave requests pending during a handover. Elena needs to understand how often this happens and whether reminders would solve the underlying problem.

The sponsor's dashboard supports a decision about expanding the pilot. For the immediate meeting, the sponsor may be able to use the existing request records and a short account of what the team has learned. Elena checks that possibility instead of assuming a dashboard is the only acceptable answer.

These conversations do not make everyone agree. They make the competing needs more concrete. Elena can now explain why helping employees respond to a decline may be the next useful step and what information she still needs about reminders.

Delegate work while retaining accountability

Elena asks a Developer with interaction-design experience to investigate the decline flow with two employees. Another Developer and the manager clarify the rules for making a new request. A colleague prepares the usage information the sponsor needs.

Those people can contribute observations, propose improvements, and help describe Product Backlog items. Elena does not need to transcribe every interview or write every sentence herself. The Product Owner may delegate this work while retaining accountability for the resulting backlog and product decisions.

The practical question is how she remains informed enough to fulfill that accountability. In this example, the group shares the observed problems, proposed options, and unresolved questions in a short conversation. Elena then updates the order and explains the current reasoning.

A queue in which every minor wording change waits for her personal approval would make collaboration unnecessarily slow. At the other extreme, letting each contributor silently reorder work would make the overall direction difficult to understand. Clear delegation includes which decisions someone may make and which require a wider discussion.

Make the order explainable

Elena places the decline explanation and next-step behavior above the reporting interface. She records a brief reason:

We have observed employees returning to the manager after a declined request. We will first improve their ability to understand the outcome and choose a valid next step. The sponsor's immediate meeting can use the current records. We will investigate the handover delay before choosing a reminder approach.

This is a current judgment, not a declaration that reporting has no value. If the sponsor explains that a necessary funding decision depends on information the current records cannot provide, that is new context to consider.

The ordered backlog helps make the decision visible. It should also be understandable to the people doing the work. A high-priority item labeled “decline improvements” would leave the Developers guessing about the intended result, despite its clear position in the list.

Keep stakeholder influence and product accountability together

The sponsor can challenge Elena's reasoning and bring additional evidence. Employees and managers can do the same. One accountable Product Owner does not imply that other people lose their voice.

It does mean that incompatible requests need to be resolved through an explicit product decision. If the sponsor privately asks a Developer to build the dashboard while the manager privately requests reminders, the visible Product Backlog no longer represents the actual direction of the work.

Elena addresses that situation by bringing the needs into the same conversation. She explains what is being considered, which outcome guides the order, and how a request can be reconsidered. The organization must also respect her product decisions for this arrangement to work. A title alone cannot compensate for every decision being overridden informally.

Work with the Developers on feasibility

Elena's preferred outcome does not establish how much can be completed in the next Sprint. The Developers need to examine the work, their capacity, dependencies, and the quality standard.

They may discover that displaying the decline reason is straightforward while automatically creating a new request introduces difficult eligibility checks. Together they can consider a smaller useful flow. Elena contributes the product trade-off; the Developers contribute the delivery judgment and choose how to build it.

This conversation preserves the distinction between ordering product improvements and dictating the implementation plan. It also makes the product decision better informed. A high-value idea that is much larger than expected may deserve a different next step than its original description suggested.

Practice making one accountable decision

List three requests competing for attention in a product you know. For each, identify the person affected, the desired result, the evidence available, and the consequence of deferring it.

Write a short ordering decision in the Product Owner's voice. Include one task you could delegate and the information you would need back. Then name the evidence that would make you reconsider the order.

Reflection: are stakeholders asking the Product Owner to make a decision, or merely to document decisions already made elsewhere? What would need to change for the accountability to be real?

The next companion follows the Developers as they turn the proposed direction into a plan they can adapt together.