tutorial
Scrum, day 16: a Daily Scrum that changes the plan
Today's objective: turn progress information into a useful adjustment of the Developers' plan toward the Sprint Goal.
Read alongside: Scrum.org's Daily Scrum reference and Scrum: A Pocket Guide, fourth edition, §3.2, “The Daily Scrum questions.” Allow roughly five minutes for this companion, plus the assigned reading.
Listen for the decision the update should support
On the fifth working morning of ShiftSwap's fictional Sprint, the interface Developer says the decline screen is nearly finished. The service Developer reports that the endpoint works for recent requests. The test specialist says she is waiting for representative older data. Everyone has a reasonable update.
The Sprint Goal is that employees at the second café can understand a declined request and choose a valid next step without asking the manager to interpret it. The updates do not yet tell the Developers whether they can achieve that result or what they should do differently today.
If the conversation ends after each person speaks, the team may repeat the same report tomorrow. The Daily Scrum becomes useful when the information changes how the Developers coordinate their work.
Inspect progress toward the goal
The Developers look at the complete flow. Recent requests behave as expected, but older ones may contain an internal note rather than an employee-facing explanation. That uncertainty affects whether the screen can safely display the available information.
They ask which part of the goal is still unsupported and what evidence they need next. The answer is more specific than “testing is blocked.” They need to distinguish the old record types, decide how each should behave, and verify the resulting employee experience.
The Scrum framework defines the Daily Scrum as a fifteen-minute event for the Developers, held each working day. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. The official reference leaves the structure to the Developers, provided it supports that purpose.
This means the team can choose useful prompts. It does not need to retain a particular set of three questions merely because they are familiar. Equally, changing the questions alone will not help if the team avoids making a decision.
Make one concrete adjustment
The Developers decide that two people will inspect the old record types immediately after the event. The interface Developer pauses a cosmetic refinement and works with the test specialist on examples of the expected display. The service Developer brings the relevant data knowledge.
They update the Sprint Backlog to show the investigation and the work awaiting its result. The plan now reflects the most consequential uncertainty instead of allowing everyone to continue optimizing a separate component.
| Before the conversation | After the conversation |
|---|---|
| “The screen is nearly finished.” | Its completion depends on agreed behavior for the older record types. |
| “Testing is blocked.” | Two Developers will obtain representative records and define the missing examples. |
| “I will continue my next task.” | A less important refinement is paused so the team can resolve the shared constraint. |
The adjustment does not need to be dramatic. It needs to be specific enough that the people involved can act and inspect the result later.
Keep detailed problem-solving in the right conversation
The record discussion could easily consume half an hour. The Developers do not have to solve every technical detail within the Daily Scrum. They identify the problem, agree on who needs to investigate, and continue the detailed discussion afterward.
That follow-up is useful work. Calling it a continuation of the Daily Scrum while requiring everyone to remain would obscure the timebox and involve people who may have no contribution to make.
The fifteen-minute boundary remains the same for a two-week Sprint. It is not automatically divided in half because the Sprint is shorter than a month. The team can finish earlier when it has achieved the purpose, but speed alone is not the measure of success.
Bring a scope consequence to the Product Owner
Suppose the investigation shows that converting the older records would require more work than expected. The Developers can discuss a scope adjustment with Elena while protecting the goal. They do not need to wait until the following morning to raise it.
Elena may help evaluate whether a clear explanation for new requests and an explicit safe path for older ones still provides a useful result. The Developers contribute feasibility and quality considerations. The Daily Scrum identified the need for this conversation; it need not turn into a general stakeholder meeting itself.
A Product Owner or Scrum Master who is actively working on Sprint Backlog items participates in the Daily Scrum as a Developer. Their job title alone does not make the event a report to them. Radu can help the Developers understand and conduct it without becoming the person who allocates everyone's work.
Let the plan change between daily events too
At two in the afternoon, the test specialist finds a case where the wrong next action is displayed. She shares it with the relevant Developers immediately. Holding that discovery until the next scheduled Daily Scrum would add delay without improving coordination.
The daily event provides a reliable opportunity to inspect the shared direction. It does not limit collaboration to one fifteen-minute window. The Developers remain responsible for keeping their plan useful as information arrives throughout the day.
Tomorrow's conversation can inspect what the investigation revealed, whether the adjustment helped, and what is now the most useful next step. It should not require everyone to recite a complete account of every activity since the previous meeting.
Rewrite an update as a decision
Take the statement “I worked on the endpoint yesterday; today I will continue.” Add the result it supports, the remaining uncertainty, and any help or coordination needed. Then identify whether this information should change the team's plan.
If you attend a daily event, notice one adjustment that follows from it. It may concern sequencing, collaboration, scope discussion, or removing an obstacle. If nothing ever changes, investigate whether the conversation is inspecting the work or merely describing activity.
Reflection: what can the Developers decide together in fifteen minutes that would be harder to coordinate through disconnected individual updates?
The next companion takes the resulting usable product to stakeholders and examines what a Sprint Review should help them decide.