Scrum, day 46: discussing bad news

Today's objective: respond to an uncomfortable discovery in a way that preserves useful information and leads to a clear next decision.

Read alongside: Mastering Professional Scrum, chapter 7, focusing on transparency and accountability. Allow roughly five minutes for this companion, plus the assigned section.

The first response shapes the next report

A Developer tells Elena that the fictional ShiftSwap expansion forecast is no longer credible. The new café's qualification rules are more complex than the team assumed, and a required scenario remains unresolved.

Elena is disappointed. The café owner has begun preparing supervisors. Her first response could be to ask why the Developer did not work faster, demand a reassuring date, or insist that the original report remain green until there is certainty of failure.

Those responses may make the current conversation shorter. They also teach people that reporting uncertainty creates personal risk. The next warning may arrive later, when fewer useful choices remain.

Establish the facts before interpreting intent

Elena asks what changed, when the team learned it, which outcome is affected, and what remains uncertain. The Developers explain the qualification scenario and show why the previous implementation assumption does not cover it.

This does not remove responsibility for earlier decisions. It establishes a shared basis for examining them. Perhaps the team overlooked a question it could reasonably have asked. Perhaps the café changed a policy. Perhaps the difference could only be discovered through detailed examples.

The next action depends on that distinction. Treating every surprise as negligence discourages learning; treating every surprise as unavoidable prevents the team from improving its judgment.

Separate immediate response from later investigation

The immediate need is to decide what can safely happen next. Elena and the Developers examine a narrower pilot, a revised forecast, and the information needed to resolve the remaining scenario. Stakeholders need an update while they can still adjust preparations.

The team can later inspect why the assumption survived into the forecast and what would help next time. Trying to conduct the entire retrospective investigation before taking the urgent product decision may delay useful action.

Both conversations matter. The first manages the current consequence. The second improves the system that produced or failed to detect it.

Ask questions that invite evidence

“Why did you promise something impossible?” assumes intent and a conclusion. “What did we know when we made the forecast, and which assumption changed?” makes it easier to reconstruct the decision.

“Can you guarantee this will never happen again?” invites an unrealistic assurance. “What would help us notice this kind of uncertainty earlier?” opens a practical improvement discussion.

Language alone cannot create trust if the consequences remain punitive. The organization also needs to act consistently with the stated invitation to report problems. People will learn more from what happens after the conversation than from a poster about openness.

Keep accountability concrete

An open discussion should still lead to action. Someone needs to arrange the rule clarification, the Developers need to revise their plan, and Elena needs to communicate the product consequence. The team should agree when to inspect progress.

Accountability becomes clearer when it concerns a specific responsibility and observable follow-through. It becomes less useful when it means assigning a person to absorb all frustration about an uncertain outcome.

If a colleague repeatedly ignores an agreed quality practice, the team should address that behavior directly and respectfully. Openness does not mean every choice is beyond examination. It means the examination can use facts without requiring people to hide information to protect themselves.

Preserve uncertainty in the stakeholder update

Elena explains that a qualification rule differs from the pilot cafés, the team is checking its implications, and the broader rollout forecast needs revision. She describes the currently supported scope and the next decision point.

She avoids replacing the old unsupported certainty with a new one. If a limited pilot is only a possibility, she labels it accordingly. Stakeholders can then decide which preparations to continue and which to defer.

This kind of update may be uncomfortable, but it supports action. A reassuring message that omits the unresolved condition transfers the surprise to a later moment and potentially to more people.

Notice whose information is missing

The person closest to a problem may be a new colleague, a contractor, or someone whose concerns have previously been dismissed. A discussion dominated by the most confident voices can miss information even when nobody explicitly forbids disagreement.

Radu can help by inviting concrete observations from the people involved, allowing written input where useful, and checking whether a proposed conclusion fits their experience. He should not force personal disclosure or turn every disagreement into a public confrontation.

The aim is enough safety and clarity for relevant information to enter the decision. The team can adapt the conversation format to support that aim.

Rehearse a difficult update

Write a short update about a real or imagined forecast problem. Include the observed fact, the affected outcome, what is still unknown, the proposed next action, and when stakeholders will hear more.

Then write the first three questions you would ask if you received it. Check whether they seek evidence and decisions or imply blame before the situation is understood. Identify one concrete responsibility that should remain clear after the discussion.

Reflection: what did your team's response to the last uncomfortable report teach people about when to bring the next one?

Next, day 47 explores the choices available when time and money are limited.