Scrum, day 60: choosing your next experiment

Today's objective: choose one practical improvement, define the evidence you will inspect, and set a real date to decide what to do next.

Read alongside: Scrum: A Pocket Guide, fourth edition, §4.1, and Mastering Professional Scrum, chapter 8. Optionally use the free Scrum Open assessment to identify framework topics to revisit. Allow roughly five minutes for this companion, plus your selected reading.

Finish the sequence with a decision

Across this series, the fictional ShiftSwap team encountered unclear user needs, misleading progress claims, late quality information, too much started work, fragmented authority, and organizational constraints. It did not solve every problem by adopting a single technique.

The recurring pattern was to make a situation understandable, choose a useful next step, inspect the result, and adapt. Your next step can follow the same pattern. It should be small enough to act on and meaningful enough that the evidence could change a real decision.

Completing sixty reading sessions is an accomplishment. The practical value now depends on what you can explain, observe, and improve in your own setting.

Choose a problem you can describe without a slogan

“We need better Scrum” is too broad to guide an experiment. “Important request variations are discovered after implementation decisions depend on them” gives a clearer starting point.

Your problem might concern a confusing product outcome, a recurring handoff, an unclear decision boundary, or a quality claim people interpret differently. Choose something you have observed, including who experiences its consequence and why it matters now.

If you are not currently on a Scrum Team, use a realistic scenario or observe a collaborative activity you can access. Be clear about the limits: an individual exercise can develop your reasoning, but it does not reproduce the full experience of a Scrum Team delivering a product.

Pick a change within your actual authority

You may be able to improve an example discussion, make a decision record clearer, or arrange a conversation about a recurring dependency. You may not be able to change staffing, funding, or organizational policy directly.

An experiment should respect that boundary. Where another person's decision is required, your next step may be preparing evidence and proposing a bounded trial with them. Do not label a change “small” if it quietly assumes authority you do not have.

At the same time, avoid treating a broad constraint as proof that no useful action is possible. Identify the part you can influence and the conversation needed for the rest.

Explain why the change might help

Write the mechanism in ordinary language. For ShiftSwap, discussing representative records earlier might expose behavior differences before implementation depends on a mistaken assumption. Limiting started work might focus attention on finishing and reveal recurring dependencies.

The explanation should be specific enough to challenge. If the expected effect does not appear, you should be able to examine whether the practice was tried, whether its mechanism operated, or whether a different problem dominated.

Avoid promising a broad productivity improvement from a small local change. Start with the observable consequence the change is intended to influence.

Decide what you will inspect

Choose a few observations that relate directly to the expectation. You might record which assumptions surfaced earlier, how long an item waited for a decision, or whether colleagues interpreted a completion claim consistently.

Include the effort required and a possible unwanted effect. A useful conversation can become burdensome if applied indiscriminately. A work limit can expose a dependency without removing it. A clearer report can still fail to reach the person who needs to act.

The evidence does not need to be elaborate. It needs to be reliable enough to support the next decision and honest about what it cannot establish.

Set a date and name the possible decisions

Choose an actual review date or a clear event after a small number of relevant opportunities. Put it somewhere you will see it. “Review later” is easy to forget when ordinary work becomes busy.

At that point, decide whether to keep the change, modify it, stop it, or collect a little more evidence. State in advance what would challenge your expectation. This makes it easier to learn from a disappointing result rather than defend the practice because you proposed it.

If the change causes a serious problem sooner, respond promptly. A review date creates a dependable inspection point; it does not prohibit adaptation before then.

Keep a one-page experiment record

Use these prompts in your own words:

Keep the record concise enough to update during the work. The purpose is to preserve your reasoning and observations, not to produce a polished document that nobody uses.

Use assessment feedback for targeted reading

If you take Scrum Open, use uncertain or incorrect answers to identify sections of the Guide to revisit. Scrum.org describes it as a free assessment of basic knowledge, without certification. A strong result can support confidence in that knowledge while leaving practical judgment to develop through experience.

Return to a book passage when it helps answer a current question. You do not need to reread the entire shelf in order every time. Your reading log can become an index of useful ideas, examples, and unresolved questions.

Explain an idea to another person using a concrete decision. Their questions can reveal gaps that repeated private reading may not expose.

Begin the next learning cycle

Complete your experiment record today. Identify the first action and the person, if any, whose participation you need. Make the review point real before the plan fades into a general intention to improve.

Reflection: what evidence, available a few weeks from now, would persuade you to change your mind? Choosing to look for it is a practical way to carry this reading beyond day sixty.

The full sequence remains available in the Scrum reading track. Revisit the companion that best supports the decision in front of you, and revise your understanding as your experience grows.