Scrum, day 02: Agile values in everyday decisions

Today's objective: use an Agile value to explain a practical trade-off while keeping the team's constraints visible.

Read alongside: Scrum: A Pocket Guide, fourth edition, §§1.2–1.3, “The origins of Agile” and “Definition of Agile,” followed by the Agile Manifesto. Allow roughly four minutes for this companion, plus the assigned reading.

Values become useful when choices compete

In day 01, the fictional ShiftSwap team discovered that employees needed clearer information about whether a shift exchange was final. The next conversation brings three competing requests.

The café manager wants the status problem fixed. A business sponsor wants a reporting dashboard promised in an earlier presentation. A developer wants time to document a permissions decision that currently exists only in a chat thread.

All three requests have a plausible purpose. Choosing between them requires judgment about the users, the risks, and the team's current commitments. A declaration that the team is “Agile” does little to explain that judgment on its own.

The Manifesto expresses preferences between things that can all have value. It gives greater weight to collaboration, usable software, human interaction, and adaptation when they compete with procedures, extensive documentation, negotiation, or adherence to an existing plan. It explicitly retains value in the latter items. Read the original statement with that qualification in mind.

Start with the conversation people need

The status issue appears in the team's work tracker as “Improve swap notifications.” That wording leaves room for several interpretations. One developer imagines another email. The manager is thinking about the schedule. An employee wants a definite answer on the request screen.

The team arranges a short conversation with the manager and an employee who experienced the confusion. They walk through one actual sequence: an invitation was accepted, an approval was pending, and the requester assumed the swap was complete.

The work tracker remains useful for recording the decision and following the work. The conversation gives the record meaning. It reveals the specific misunderstanding the product needs to resolve.

A practical question for the team is: which conversation would remove uncertainty that another paragraph in the ticket has failed to remove? That question helps the team choose a concrete action.

Decide what documentation earns its place

The permissions note deserves consideration too. Suppose anyone who knows a request identifier can currently retrieve its details. The developer has identified a decision about who may see and approve a swap. Losing that decision could lead to inconsistent behavior or an inappropriate disclosure.

A brief record can preserve the rule, its rationale, and the examples used to check it. The team can connect it to tests and update it when the policy changes. Its value comes from the decisions it supports and the mistakes it helps prevent.

By contrast, a long presentation describing every screen may add little if no one uses it and it becomes stale immediately. The team can ask who needs each document, what they will do with it, and how it will stay trustworthy.

The principles behind the Manifesto connect agility with technical excellence, good design, and a sustainable working pace. That makes the quality of the permissions behavior part of the discussion about useful delivery.

Bring the sponsor into the trade-off

The reporting dashboard was promised for a reason. Perhaps the sponsor needs to understand how often employees swap shifts and whether staffing problems cluster at particular locations. Quietly discarding the request would leave that need unresolved.

The team shares what the pilot revealed and asks the sponsor which upcoming decision depends on the dashboard. It discovers that a weekly export would answer the immediate question. A polished interactive screen could wait while the team resolves the status confusion.

This is a possible outcome of collaboration, not a universal answer. In another situation, reporting might be required before a wider launch. The useful practice is to make the needs and consequences discussable so the people involved can make an informed choice.

Make a change visible

The team records what it learned, which work it proposes to change, and who needs to participate in the decision. In a Scrum setting, the current Sprint Goal and the responsibilities of the Product Owner and Developers would also shape how this change is handled. We will examine those boundaries in the Sprint companions.

For today's reading, focus on the quality of the reasoning. “Someone asked for a change” is incomplete. The team needs to understand what changed, what evidence supports the request, and what continuing the earlier plan would cost.

A useful decision note might read:

Employees are mistaking an accepted invitation for a finalized swap. We propose clarifying approval status before expanding the reporting interface. A weekly export will support the sponsor's immediate staffing review. We will check whether employees still need help interpreting status during the next pilot session.

This note connects evidence, a choice, a consequence, and a way to learn more. It also gives someone who disagrees something specific to challenge.

Explain one decision

Pick a recent disagreement about delivery. Write down the two competing needs, who experiences the consequences, and which Agile value helps you reason about it. Include one constraint that remains important, such as access control, a contractual obligation, or a sustainable workload.

Reflection: what evidence would persuade you to choose differently? A thoughtful answer leaves room for circumstances to matter.

In the next companion, we will turn the team's proposed work into a small piece of usable product and examine what it can teach us.