tutorial
Scrum, day 01: when a good plan meets real users
Today's objective: recognize an assumption inside a plausible product plan and choose a useful way to investigate it.
Read alongside: Scrum: A Pocket Guide, fourth edition, §1.1, “To Shift or not to Shift.” Use the section heading to find it in your print or digital copy. Allow roughly four minutes for this companion, plus your book reading. The 60-day reading plan explains the sequence and editions.
A convincing plan
Imagine a team building ShiftSwap, an application that helps café employees exchange shifts. Every person, conversation, and result in this example is fictional.
The initial request sounds straightforward. Employees currently post messages in a group chat when they need someone to cover a shift. The café manager wants fewer messages and a clearer record of the final arrangement. The team proposes a form for requesting a swap, a matching screen, notifications, and an approval dashboard.
Those features fit the request. The developers can discuss database tables, permissions, and delivery dates. A designer can sketch the screens. After a planning meeting, the team has enough detail to begin working.
It also has several unresolved assumptions. Will employees create an account for something they already accomplish in a familiar chat? Do they want to exchange shifts with any qualified colleague, or only with people they know? Does the manager need to approve every arrangement? Who can confirm that the person accepting a shift has the required training?
A detailed implementation plan can coexist with a weak understanding of the problem. Each screen might work exactly as designed while the overall product makes employees' lives harder.
Separate what was observed from what was inferred
Before writing more requirements, the team makes a small evidence table. Its purpose is to reveal the reasoning behind the proposed product.
| Statement | What kind of statement is it? | A useful next step |
|---|---|---|
| The manager spends time reconciling swap requests in chat. | A reported problem from one stakeholder. | Observe how the manager handles several actual requests. |
| Employees will prefer an automatic matching screen. | An assumption about user preference. | Discuss recent swaps with employees and observe a prototype session. |
| Every swap needs managerial approval. | A possible policy constraint. | Check the café's actual scheduling policy and exceptions. |
| A requester must know whether the swap was approved. | A proposed requirement. | Investigate what uncertainty currently causes mistakes. |
These statements need different kinds of investigation. A policy question may have a definite answer in an existing document. A question about how people will behave with a new product may require trying something and observing the result. A technical question might be resolved with a small engineering experiment.
The distinction changes what the team does next. Building an entire matching system would be an expensive way to discover that employees mostly want to invite one trusted colleague.
Make a smaller commitment
Suppose the team decides to investigate that last assumption. It writes a question before designing the experiment:
Can an employee arrange a swap with a specific colleague and understand its approval status without asking the manager for an update?
For an early design session, a clickable prototype may reveal confusing language or missing information. The team records what participants attempt, where they hesitate, and which questions they ask. That feedback helps refine the design, although it does not establish how people will behave over several weeks of real use.
A later pilot could use a small working flow at one café: request a swap, invite an eligible colleague, record acceptance, obtain approval where required, and show the resulting status. The team would still need appropriate access controls and a dependable record of the arrangement. A narrow scope is a choice about how much capability to offer; the people using it still need it to work reliably.
Before the pilot begins, the team agrees to look at completed swaps, requests that need help, and the reasons employees abandon the process. It also records the limits of the experiment. One café and a small group can reveal useful problems without establishing a result for every location.
Let the result affect a decision
In our scenario, employees understand the invitation flow, but the manager still receives status questions. The team observes that employees cannot tell whether their colleague's acceptance is enough to finalize the swap.
That observation changes the next decision. Clear approval status becomes more urgent than automatic matching. The team can explain the change using something it observed, and it can investigate whether the revision helps.
The Scrum Guide describes Scrum as a framework for creating value in complex situations. Its recurring opportunities to inspect results and adapt give this kind of learning a place in the team's work. Our example is one possible product investigation; the particular table, prototype, and pilot design are supporting techniques.
As you read the Pocket Guide, keep the café team's decision in mind. Ask where a commitment becomes useful, where it becomes premature, and what information could justify changing it.
Apply the idea to your own work
Choose a feature you have recently built, requested, or considered building. Write three sentences:
- We have observed that a particular person has this problem.
- We believe this change will help because of this assumption.
- Before committing further, we could investigate the assumption in this way.
Be specific about the observation. “Users need a dashboard” already contains a proposed solution. A report that someone spends half an hour gathering information every Monday gives you a problem to investigate.
Reflection: if the experiment contradicts the plan, which decision should change? Naming that decision makes the investigation useful before you begin.
In the next companion, the same team receives competing requests. We will use the Agile values to reason about what it should do.