Scrum, day 08: values when the news is uncomfortable

Today's objective: choose an observable response to an uncomfortable discovery and explain how the Scrum values shape that response.

Read alongside: Scrum: A Pocket Guide, fourth edition, §2.7, “The Scrum values,” and the Scrum.org explanation of those values. Allow roughly five minutes for this companion, plus the assigned reading.

A problem appears just before a demonstration

The fictional ShiftSwap team is preparing to show its second-café approval flow. A Developer discovers that an old notification can arrive after a request has been cancelled. The message describes the earlier approval as if the shift exchange were still final. The request screen shows the correct current state, but an employee reading only the notification could make the wrong arrangement.

The team has already told stakeholders that the approval work is nearly complete. Its quality standard requires status messages to remain consistent with the actual request state. The discovery therefore changes what the team can honestly describe as finished.

Someone suggests demonstrating only the normal sequence and fixing the unusual case afterward. Another person says the whole Sprint must now be a failure. Both reactions are understandable under pressure, and both skip the conversation the team needs: what exactly is wrong, how it affects the goal, and what can be done responsibly.

The five Scrum values are commitment, focus, openness, respect, and courage. Use them here as guides to choices people can observe. Memorizing the words does little for the employee who receives the wrong message.

Openness makes the actual state discussable

The Developer shares a reproducible example: approve the request, cancel it, then allow the delayed notification to arrive. She explains what the employee would see and which quality expectation is violated. She also states what she has not checked yet.

This is more useful than a vague warning that “notifications are broken.” It is also more useful than a green status accompanied by a private message saying that there is one small problem. People making decisions about the pilot need the same relevant information.

Elena, the Product Owner, now knows that the planned demonstration needs an accurate account of the work's state. The Developers can inspect the affected path. The Scrum Master can help the team have that discussion without turning the person who found the problem into its cause.

Courage turns a concern into an action

Sharing the example may feel risky because it contradicts the earlier progress report. A colleague can make that easier by supporting the act of raising the concern: “Let's reproduce it together and update what we know.”

Courage also matters after the problem is acknowledged. The team may need to revise an expectation with the sponsor or challenge the proposal to call the work complete. Doing so calmly and specifically gives others a fair chance to respond.

A useful statement would be:

We found a delayed-message case that can mislead an employee about a cancelled swap. This part does not yet meet our completion standard. We are checking the correction and will explain what is actually usable at the Review.

The statement does not require certainty about the final fix. It requires honesty about the information currently available.

Respect changes how disagreement happens

The person who wrote the notification code had not been given the cancellation example. Another person assumed the delivery service would preserve the order of messages. The team can inspect both assumptions without labeling either colleague careless.

Respect does not require accepting an unreliable result. It means treating people as capable contributors while examining the work rigorously. “What assumption did this design depend on?” invites an explanation that the team can test. “Who thought this was a good idea?” makes defending personal competence the immediate concern.

Respect applies to stakeholders too. The café manager scheduled time for a demonstration and needs to know what changed. A direct update lets the manager decide how to use that time. Concealing the issue to avoid disappointment would deny the manager relevant information.

Focus and commitment help choose the next move

The Sprint Goal concerns dependable understanding of approval state at the second café. The notification problem bears directly on that purpose. A cosmetic reporting change has less immediate relevance.

The Developers discuss scope with Elena and concentrate on the message behavior. They consider whether a smaller notification approach can meet the goal and the existing quality standard. A simpler implementation may be enough; quietly lowering the standard would change the meaning of “finished.”

Commitment shows up in supporting the goal, helping colleagues, and doing the work needed to produce a trustworthy result. It should not be reduced to defending every initial task or requiring people to work through the night. A plan that relies on exhausted people can make the next quality problem more likely.

The Scrum.org discussion of values in practice is helpful here: commitment concerns shared goals and support, while the selected work can change as the team learns.

Keep the quality boundary visible

If the correction meets the Definition of Done in time, the team can include it in the Increment and discuss it at the Review. If it does not, the team must be explicit about what remains unfinished and how that affects progress toward the goal.

The Definition of Done section of the Scrum Guide prevents unfinished work from being passed off as part of an Increment. The team can explain the impediment and the learning without presenting the incomplete behavior as a completed result.

Living the values does not guarantee that every Sprint achieves its goal. It improves the conditions for detecting problems, making responsible decisions, and learning from what happened. The team can later examine why the misleading status report persisted and which examples should have been discussed earlier.

Rewrite the difficult conversation

Imagine you are present when someone proposes hiding the delayed-message case. Write a two-sentence response that describes the observable problem, its consequence for users, and a constructive next action. Avoid judging anyone's motives.

Then consider the response you would want if you were the person who introduced the defect. Keep the quality expectation intact while making it possible to ask for help.

Reflection: which behavior from a colleague or leader would make it easier for you to raise bad news earlier? Choose something observable, such as asking for the example before assigning blame.

The next companion examines whether the team actually has the skills and authority needed to finish the work it takes on.