Scrum, day 36: listening to conflicting feedback

Today's objective: investigate conflicting feedback by separating the situation, underlying need, and proposed solution before choosing the next step.

Read alongside: Mastering Professional Scrum, chapter 4, focusing on feedback and adaptation. Allow roughly five minutes for this companion, plus the assigned reading.

Two managers want opposite changes

One manager at the fictional ShiftSwap pilot asks for more notifications. They worry about missing pending requests during a busy evening. Another asks the team to remove notifications because repeated messages interrupt their work.

Elena could count votes, choose the more senior manager's preference, or build a large settings screen that allows every possible combination. Each response makes a decision before understanding why the experiences differ.

Conflicting feedback is often a reason to investigate context. The team needs to know what each person is trying to accomplish, what currently gets in the way, and which part of the experience prompted the requested solution.

Ask for the last concrete occurrence

Elena asks the first manager about a recent missed request. The manager was away from the desk, returned shortly before handover, and did not know a decision was waiting. The notification they wanted was a timely indication of new responsibility.

The second manager describes receiving repeated updates about requests already handled by another supervisor. Their objection concerns irrelevant and outdated interruptions. They do not necessarily oppose a useful alert about a decision they genuinely need to make.

The apparent conflict becomes more precise. Both managers may want timely, relevant information, while the current product distributes messages without enough regard for responsibility and state. That possibility is a hypothesis to examine, not a conclusion established by two conversations.

Preserve the request without mistaking it for the need

The team records each proposed solution alongside the situation that produced it. “Send more notifications” remains useful feedback, but it is no longer the entire backlog description.

The underlying problem might be expressed as an incoming supervisor failing to recognize a pending decision in time. The second problem might be repeated messages about decisions that no longer require that supervisor's attention.

This distinction leaves room for alternatives. A clearer handover view, a better indication of current responsibility, or a narrower notification rule might help. The team can compare them before committing to a general-purpose notification preference system.

Look for differences that change the solution

The cafés may operate differently. One has a single manager on duty; the other has overlapping supervisors. One relies on a shared terminal; the other frequently works away from it. A solution appropriate to one setting may behave poorly in the other.

Elena and the Developers identify which differences are relevant to the current Product Goal. They avoid assuming that every preference requires a separate configurable feature. Sometimes a product should support both contexts. Sometimes a context falls outside its current boundary. Sometimes a common solution becomes visible only after the differences are understood.

The decision needs an explanation that stakeholders can assess. “We chose the other manager's request” is less useful than “we are testing whether alerts tied to current responsibility address both observed difficulties.”

Choose a small next investigation

Before changing notification behavior, the team traces a few representative request sequences. Who was responsible when the message was sent? Had the request already changed state? What information did the recipient need at that moment?

This investigation may reveal an existing defect, a missing product rule, or a misunderstanding about the workflow. Each would lead to a different next step. Building settings before resolving the distinction could give users control over an unreliable mechanism without addressing its core problem.

The investigation should remain bounded. The team can select a few relevant cases, state the question, and decide when it has enough information to choose a small experiment. It does not need to map every future café configuration before learning anything useful.

Make the Product Owner's decision visible

After considering the evidence, Elena orders a narrowly scoped improvement to alert relevance ahead of a general settings page. She explains the expected benefit, the affected users, and what the team will observe after the change.

The managers may still disagree. Being heard does not guarantee that every requested solution will be built. A transparent decision gives them a way to challenge the assumptions or provide missing information without treating the backlog as a contest for influence.

The Developers contribute information about feasibility and consequences. They may discover that reliable responsibility data is a prerequisite. That information can change the order of work or suggest a smaller approach.

Close the feedback loop

The team returns to the managers after trying the change. It asks whether the original difficulty improved, rather than simply whether they like the new feature. The first manager may still miss decisions because their working environment makes any digital alert easy to overlook. The second may report fewer irrelevant interruptions.

Mixed results are useful. They can reveal that one proposed mechanism addressed only part of the problem. The team can retain the benefit while investigating the remaining need.

Feedback loses value when it enters a backlog and disappears indefinitely. Even when a request is deferred, explaining the decision and the conditions for revisiting it helps stakeholders understand how their observations influence the product.

Investigate a disagreement

Choose two conflicting requests. For each, write the person's situation, intended outcome, current obstacle, and suggested solution. Mark what you know directly and what you are inferring.

Identify a question or observation that could explain the difference. Propose one bounded next step that would improve the decision, and describe how you would communicate a choice to the stakeholder whose preferred solution is deferred.

Reflection: are the stakeholders disagreeing about the outcome they want, the context they face, or the mechanism they believe will help? Your next conversation should target that distinction.

Next, day 37 places these decisions within a plan that can adapt.