Scrum, day 39: selecting work for a Sprint

Today's objective: combine a meaningful Sprint Goal, realistic capacity, and known uncertainty into a credible selection of work.

Read alongside: Mastering Professional Scrum, chapter 5, focusing on planning a Sprint, with the Scrum Guide's Sprint Planning section nearby. Allow roughly five minutes for this companion, plus the book reading.

Start with a useful result

The fictional ShiftSwap team is considering a Sprint focused on helping incoming supervisors recognize the requests that need their attention. Elena brings recent observations from the cafés and explains why this matters now.

The Developers have refined a possible handover summary and identified uncertainty about responsibility during overlapping supervision. They also know that one colleague will be away for several days and that a small operational correction remains important.

Selecting work requires considering these facts together. A list ordered by importance is necessary input, but it does not automatically become a coherent and achievable Sprint plan.

Discuss why this Sprint matters

The team proposes a goal around making pending responsibility understandable during handover. It checks whether that result is valuable enough to focus the Sprint and whether the product is ready for the proposed step.

The discussion may reveal that clarifying responsibility is more urgent than sending alerts. It may also reveal that the cafés need to resolve an operating rule before some behavior can be implemented. These discoveries can change the proposed goal or the scope supporting it.

The goal should be meaningful in terms of the product result. “Complete ten items” provides little guidance when the team later needs to choose between two competing pieces of work.

Use capacity as a constraint, not a productivity target

The Developers consider the available people, known absence, operational duties, and the skills needed for the work. They also consider recent experience completing similar items under the Definition of Done.

An absent colleague may affect more than the number of available hours if they hold knowledge others need. The team can plan pairing before the absence, choose a different slice, or make the dependency explicit. Pretending all hours are interchangeable would conceal the actual constraint.

Capacity information helps the team make a credible forecast. It should not become a demand to allocate every minute in advance. Complex work includes discovery, coordination, and adaptation that a fully packed task calendar can make harder to handle.

Examine the uncertainty that could change the plan

The responsibility rule is the main unknown. The team can involve the relevant managers before selection, narrow the initial scope to a clear case, or include a bounded investigation that informs the implementation.

The Developers should explain what they expect to finish under each approach. A vague investigation with no decision point can consume the Sprint without producing the intended result. A smaller clear case may provide a usable step while preserving the unresolved case for later.

The choice depends on the user consequence. Excluding overlapping supervision is reasonable only if the resulting capability remains safe and useful for its stated scope. The team should not choose an artificial boundary merely because it makes estimation easier.

Include the work needed to finish

The selected item is more than its main implementation task. It may require examples, integration, permission checks, interaction verification, and operational preparation. The Developers consider these when forecasting what they can complete.

They can decompose the work enough to expose dependencies and plan collaboration. They do not need to predict every task perfectly. The plan will become more detailed as they learn.

If an item appears to fit only by postponing verification or ignoring the shared quality standard, it does not fit as currently understood. The team needs a smaller slice, a different selection, or a more honest forecast.

Keep the forecast distinct from the goal commitment

The Developers select work they believe can support the goal within the Sprint. The selection is a forecast based on current understanding. Discoveries may require negotiating scope with Elena while preserving the goal and quality.

This flexibility does not make selection casual. A team that routinely chooses far more than it can finish should inspect the causes and improve its judgment. Equally, treating every selected item as an unconditional contractual promise can encourage hidden problems and resistance to useful adaptation.

The team needs both seriousness about its goal and transparency about the uncertainty in its plan. These qualities reinforce one another when people can discuss new information promptly.

Explain what was deferred

Elena wants an alert preference screen as well as the handover summary. The Developers explain that the preference work introduces a separate interaction and additional verification beyond the current forecast.

The team can discuss whether it is essential to the goal. If it is not, deferring it may preserve a coherent result and leave room for learning. Elena can explain that decision to stakeholders without presenting the deferred item as guaranteed work for the next Sprint.

A useful plan includes clear choices about what receives attention now. Leaving every request nominally “in scope” while privately expecting some to remain unfinished creates avoidable confusion.

Make a small planning decision

Take a candidate Sprint Goal and three possible items. Describe available capacity, one relevant dependency, and the quality work needed for completion. Select a coherent set and explain why the remaining work is deferred.

Introduce a plausible discovery and describe how you would respond. Identify which parts of the plan the Developers can adapt directly and which need a scope conversation with the Product Owner.

Reflection: does your selection express a credible path to a useful result, or does it mainly reflect how much work stakeholders hope will fit? What evidence would help bring those views closer together?

Next, day 40 extends that discussion to expectations beyond one Sprint.