Scrum, day 12: Developers own the delivery plan

Today's objective: explain how the Developers plan, maintain quality, and adapt their work together without waiting for someone else to assign every task.

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

Start from a shared result

Elena has explained why ShiftSwap should improve what happens after a request is declined. The fictional team's next planning conversation will explore how employees can understand the outcome and choose a valid next step without asking the manager to interpret it.

One approach would be to assign a screen to one person, an endpoint to another, and the tests to a third. Each person could then report progress on a separate component. That arrangement might be useful for some work, but the assignments alone would not explain how the complete employee experience will become usable.

The Developers begin by walking through the result together. What information must be available? Which actions are valid after a decline? What happens if the original shift has already started? How will an employee using assistive technology find the explanation?

Their plan must connect these questions to an integrated result. Individual tasks support that result; they do not replace it.

Understand the accountability beyond coding

In Scrum, Developers are the people committed to creating any aspect of a usable Increment. The term includes the different skills the product needs. A person whose main contribution is testing or interaction design can participate in this accountability.

The Scrum.org Developer reference identifies four recurring responsibilities: planning the Sprint, adhering to the Definition of Done, adapting the plan toward the Sprint Goal, and holding each other accountable as professionals.

For ShiftSwap, these responsibilities connect. A plan that omits important checking makes its forecast less credible. A quality problem discovered late may require adapting the work. Helping a colleague finish the integrated behavior may matter more to the goal than completing another isolated task.

The team does not need everyone to perform identical activities. It needs the people doing the work to take shared responsibility for whether those activities produce the intended usable result.

Build enough of a plan to begin intelligently

The Developers sketch the decline flow using three concrete situations: a colleague is ineligible, the manager declines for a scheduling reason, and the request is no longer relevant because its shift has passed.

They identify a useful first slice: show the accurate reason and the next permitted action for a current request at the second café. They discuss whether the same behavior fits both the existing data and the manager's policy. That conversation exposes an assumption: some old requests do not contain a reason the employee can understand.

Instead of assigning interface work immediately, two Developers investigate how those records should be represented. Another prepares examples for the complete flow. The plan now reflects a question that could change the implementation.

The Developers will refine the plan as they learn. They do not need to forecast every conversation or code change on the first morning. They do need enough understanding to begin coherent work and recognize threats to completion.

Keep the plan available to the people using it

Suppose the investigation reveals that the employee-facing explanation must be stored separately from an internal manager note. The Developers update the Sprint Backlog so the additional work and its purpose are visible.

If the change affects the scope they expect to complete, they collaborate with Elena on the trade-off. They might retain a reliable explanation and a clear manual next step while deferring an automatic retry shortcut. The decision depends on whether that smaller flow still serves the Sprint Goal and meets the quality standard.

A private checklist on one person's computer would make this adaptation harder to inspect. The Sprint Backlog should provide a current picture of the Developers' plan. The tool can be simple, provided the people relying on it can understand what is happening and what needs attention.

Treat quality as part of the work

The Developers identify checks for accurate explanations, permitted actions, and access to the relevant request. They also consider whether an internal note could appear where an employee-facing reason belongs.

These concerns influence the design while it is still being developed. Leaving them until after everyone reports their implementation tasks complete would increase the risk of discovering an incompatible assumption late.

If a check reveals that the flow does not meet the Definition of Done, the work remains unfinished. Neither an attractive demonstration nor a nearly complete task board changes that state. The Developers can make the problem visible and adjust their plan without redefining completion to make the numbers look better.

An item-specific behavior, such as showing the decline reason beside the request, also needs clear examples. The shared Definition of Done and the particular item's expected behavior provide related but different information. Day 19 will examine that distinction more closely.

Hold each other accountable through specific conversations

One Developer notices that a colleague has started a reporting task while the decline flow awaits review. She asks whether helping with that review would contribute more to the Sprint Goal today.

This is a professional coordination conversation. It works better when it refers to the goal and current work than when it becomes a judgment about effort. The colleague may know about a dependency that changes the decision, so the conversation should leave room for that information.

Shared accountability also includes asking for help early, communicating availability, and explaining a concern someone else may have missed. It does not require surveillance or a competition over who closes the most tickets.

Turn a component plan into a delivery plan

Choose a feature you know. Write the end-to-end result a user should be able to complete. List the work needed to understand, build, verify, and operate it, including any uncertainty that could change the approach.

Identify one point where two people need to coordinate. Describe the information they need from each other and how the plan will change if an assumption fails. Then name one existing task someone could help finish before starting another.

Reflection: when new information arrives, can the people doing the work update their plan directly? If they must wait for an external task assignment, identify what decision is being held outside the team and why.

The next companion considers how a Scrum Master can help improve those conditions without taking over the Developers' decisions.