Scrum, day 21: assessing today’s practice

Today's objective: use observations from recent work to identify one problem worth improving, without turning the discussion into a score for the team.

Read alongside: Mastering Professional Scrum, first edition, chapter 1, focusing on its improvement areas and the capabilities needed to develop a Scrum practice. Use the publisher's contents to locate the sections. Allow roughly five minutes for this companion, plus your book reading.

Start with a decision you could improve

The fictional ShiftSwap team has finished its decline-flow Sprint. Employees can understand a declined request and see a valid next action. The team also remembers several uncomfortable moments: an assumption about older records surfaced late, verification piled up, and people disagreed about whether an interface task counted as finished product work.

Radu, the Scrum Master, suggests inspecting how the team works. Someone offers a spreadsheet with twenty categories and a score from one to five for each. Another person wants to introduce a new planning tool immediately. Both suggestions risk moving the conversation away from the experiences that prompted it.

Before choosing an assessment method or a solution, the team needs a useful question: which recurring problem most limits its ability to create a useful, dependable product?

Separate an observation from its explanation

“We are bad at refinement” sounds like an assessment, but it combines a judgment and a suspected cause. It leaves little room for people who experienced the same work differently.

A more specific starting point is that two changes involving older request records needed substantial clarification after implementation began. One affected the employee-facing explanation. The other affected which next actions were available. In both cases, Developers had already made decisions that needed revisiting.

Those observations still need checking. Were they unusual cases? Had someone raised the issue earlier? Did the necessary information exist? A colleague remembers a useful note that never reached the people discussing the interface. That changes the investigation: information may have been available but disconnected from the decision.

The team writes the event, its consequence, and possible explanations separately. Doing so lets people challenge an explanation without denying that a frustrating event happened.

Look from more than one position

Elena, the Product Owner, noticed that the uncertain work made it harder to explain what the cafés could expect. A Developer working on the service noticed repeated changes to examples. A colleague concentrating on verification noticed that several items became available to check at once.

Each account describes part of the same system. Selecting the loudest account as the complete diagnosis would hide useful information. The team follows one item from its first discussion to a usable result and asks the people involved what they knew at each point.

This is also a chance to examine what helped. When a manager joined a short discussion about an older record, the team resolved a question quickly. Understanding that success may suggest a practical improvement with less disruption than replacing the whole refinement process.

Compare problems without pretending to calculate certainty

ShiftSwap considers three candidates:

The table makes the choices discussable. It does not establish a mathematical ranking. The team can consider recurrence, consequences for users, effort to investigate, and ability to make a change now. An inconvenient but rare event may deserve less immediate attention than a modest problem that affects almost every change.

Choose a problem small enough to investigate

The Developers already agreed in their Retrospective to discuss recent, old, and exceptional record examples for the next two relevant changes. Today's assessment gives that experiment a clearer reason: important behavior is being discovered after decisions depend on it.

They choose this problem first because there are upcoming changes on which to observe it, people recognize the consequences, and the team can adjust its conversations directly. They keep the verification queue visible as another concern. Selecting a focus does not establish that all other problems are unimportant.

The problem statement becomes: “For changes involving existing requests, we sometimes discover a consequential record variation after implementation has begun, causing decisions to be revisited.” It is specific enough to investigate and broad enough to allow more than one explanation.

Avoid turning the assessment into a reputation contest

Suppose management asks each team to report a monthly Scrum maturity score. A team that reports more difficulties may appear weaker than one that reports very few. That creates an obvious temptation to improve the report instead of the work.

ShiftSwap can explain progress through concrete examples: which difficulty it examined, what it changed, what happened, and what remains uncertain. A structured questionnaire might still prompt useful questions, but the team should understand how its answers will be used before treating the scores as evidence of capability.

The Scrum Guide's description of empiricism grounds adaptation in observed experience. For this team, an honest account of a delayed decision offers a better starting point than a confident numerical self-description with no examples behind it.

Read an older book with a current reference nearby

Mastering Professional Scrum was published before the November 2020 Scrum Guide. You will encounter terminology from that period. In this series, Developers and self-management refer to the current framework. The book's reading assignments remain useful prompts for examining practice, while the current Guide supplies the framework reference.

As you read, mark a question that helps you examine your own work. You do not need to adopt every suggested practice or reproduce a whole assessment before trying one improvement. A productive reading session can end with a better question and an observation to collect.

Write one problem statement

Choose a recent piece of work that was harder to finish than expected. Describe one observable event, who experienced its consequences, and what decision became harder. Then list two possible explanations rather than settling immediately on the first.

Find one other person who can check the account. Ask what is missing and whether a contrasting example exists. Finish by naming a change you could investigate within the next Sprint, together with one reason this problem deserves attention now.

Reflection: if the team improved its assessment score but this problem continued unchanged, would you consider that progress? Decide what you would need to observe before saying the work had improved.

Next, day 22 turns the selected problem into a bounded experiment.