A Daily Scrum can be organized person by person, story by story, or in any other way that helps the Developers inspect progress and adapt their plan.
The format matters less than the outcome.
After the Daily Scrum, the team should understand:
- Whether progress toward the sprint goal is on track
- Which work needs attention today
- Where people need to coordinate
- What impediments or risks need follow-up
- What the team’s plan is until the next Daily Scrum
If the Daily Scrum answers those questions, the format is probably working.
If it doesn’t, change the format.
A common question is whether the team should go person by person or story by story. I was once asked this:
Most of our teams complete 10 or more user stories per sprint. When we go person by person in the Daily Scrum, it’s clear what each person is working on, but it isn’t clear how each story is doing or when a story is in trouble. For example, if no one worked on a story yesterday, problems with that story may not be visible because no one mentions it.
We started conducting the Daily Scrum story by story instead of person by person. Now it’s clear how each story is progressing, but it’s harder to know what each person is doing. Some people work on multiple stories, and others may not speak at all.
That’s a real tradeoff.
A person-by-person Daily Scrum can make individual activity visible but hide the state of the work.
A story-by-story Daily Scrum can make the work visible but sometimes lets people disappear into the background.
Neither format is automatically right.
The team needs a Daily Scrum that keeps attention on the sprint goal and the work most likely to affect it.
Start with the Purpose of the Daily Scrum
The Daily Scrum is not a status meeting.
It is not a report to the Scrum Master, product owner, or manager. It is a short planning event for the Developers.
The team is asking, in effect:
Given what we know now, what should we do next to make progress toward the sprint goal?
That question can be answered in many ways.
Some teams answer it by having each person speak. Some walk the board from right to left. Some discuss each product backlog item in the sprint. Some start with blocked work. Some start with the sprint goal and work backward.
The format is only a tool.
A team should keep a format as long as it helps them inspect and adapt. When the format stops doing that, the team should change it.
Person by Person Can Work
Many teams start their Daily Scrum person by person.
That can work well, especially for a small team with a clear sprint goal and a manageable amount of work in progress.
A person-by-person format is simple:
- What did I accomplish since the last Daily Scrum?
- What will I work on next?
- What is getting in my way?
Those questions can still be useful. But teams should not treat them as mandatory, and they should not let the questions turn the event into individual status reporting.
The danger is that the Daily Scrum becomes a series of disconnected updates.
“I worked on the login story.” “I fixed a defect.” “I have a meeting later.” “No blockers.”
Everyone talks. Nobody replans.
When that happens, the team may leave the Daily Scrum with no better understanding of whether the sprint goal is at risk.
Story by Story Can Work
A story-by-story Daily Scrum shifts attention from people to the work.
Instead of asking each person for an update, the team walks through the product backlog items or work items selected for the sprint.
For each item, the team asks:
- Is this moving?
- Is it blocked?
- Is anyone working on it today?
- Does it need help?
- Is it still likely to be done in time?
- Does it still support the sprint goal?
This can be a better format when the team has too many partially started items or when important work is getting ignored.
Story-by-story makes neglected work visible. If no one has touched an item for two days, the team can see that and decide what to do.
The risk is that some team members may stop participating. They wait until “their” story comes up, or they stay quiet because someone else is already talking about the item.
That is a problem. The Daily Scrum still belongs to all the Developers. Everyone should be engaged in the plan, even when they are not currently working on the story being discussed.
Walk the Board, Not the Room
A good compromise is often to walk the board instead of walking the people.
Put the sprint goal where everyone can see it. Then look at the sprint backlog or team board together.
Start with work closest to done.
Ask:
- What can we finish today?
- What is blocked?
- What has been sitting too long?
- Where do we have too much work in progress?
- What needs collaboration?
- What threatens the sprint goal?
This keeps attention on the work without losing the people.
When someone gives an update, ask them to point to the item they’re talking about. That one small habit helps the team connect individual activity to sprint progress.
“Point to what you’re working on” is often enough to make the Daily Scrum more useful.
The board also helps the team see patterns they might miss in a person-by-person conversation:
- Too many items are started.
- Nothing is moving to done.
- One item has become a bottleneck.
- Testing is piling up at the end.
- One person is overloaded.
- No one is working on the item most important to the sprint goal.
Those are exactly the kinds of things a Daily Scrum should make visible.
Too Many Sprint Backlog Items May Be the Real Problem
When teams struggle to discuss work clearly in the Daily Scrum, the problem is often not the Daily Scrum format.
The team may simply have too many sprint backlog items.
When a team selects 15, 20, or 30 items for a sprint, it becomes hard to see what matters. The Daily Scrum turns into a long list of fragments. People jump from item to item. Work starts faster than it finishes.
A useful guideline is that many Scrum teams do better when they average roughly one to one-and-a-half product backlog items per person in a sprint.
A six-person team might therefore finish somewhere around six to nine product backlog items in a sprint. Teams with shorter sprints will usually be toward the low end of that range. Teams with longer sprints may be toward the higher end.
That is not a rule.
And it absolutely does not mean each person should take one story and work alone for the sprint.
The point is simpler: if the team has so many items that no one can tell what is happening, the team may need smaller batches, clearer sprint goals, and less work in progress.
A Daily Scrum cannot compensate for a sprint backlog that is too scattered.
Consider a Point Person for Each Story
Another useful technique is to identify a point person for each product backlog item selected for the sprint.
This person is not the owner of the story in the old command-and-control sense.
The point person does not assign tasks. They do not become solely responsible for finishing the item. They are not the only person allowed to work on it.
They are simply the person expected to know the current state of the item.
A point person might spend a few minutes before the Daily Scrum checking whether the item is moving, blocked, waiting for review, or in need of help.
That can be especially useful when several people contribute to the same item.
The point person can say:
This story is close, but the test data setup is slower than we expected. I need help from someone who worked on the reporting story last sprint.
That is far better than five people each saying a small piece of what they did while no one explains whether the story is likely to finish.
Keep Teams Small Enough to Communicate
If the team is large, the Daily Scrum becomes harder no matter which format is used.
Large teams make it easier for people to disengage. They make coordination more expensive. They make it harder to maintain a shared understanding of the sprint goal and current plan.
I prefer Scrum teams of about five to seven people when possible.
A larger Scrum team can still work, but once the team gets much beyond that, the Daily Scrum often becomes a symptom of a deeper problem. The team may need to split into smaller, more cohesive teams organized around the same product.
When people cannot track what is happening in 15 minutes, do not only change the meeting. Look at team size, work in progress, dependencies, and the clarity of the sprint goal.
Try Different Formats for a Sprint
The best way to choose a Daily Scrum format is to experiment.
Try person by person for a sprint. Try story by story for a sprint. Try walking the board from right to left. Try starting with blocked work. Try starting with the sprint goal and asking what most needs attention today.
Then discuss what happened in the Sprint Retrospective.
Ask:
- Did the Daily Scrum help us adapt our plan?
- Did it make risks visible early enough?
- Did we leave with a clear plan for the day?
- Did the right people talk?
- Did we focus on the sprint goal?
- Did the event stay short and useful?
If you have multiple teams in the same organization, let different teams try different approaches for a sprint. Then bring people together to compare what they learned.
Teams do not all need the same Daily Scrum format.
They need a Daily Scrum that helps them inspect progress, adapt the sprint backlog, and coordinate the next day of work.
So Which Format Should You Use?
Use person by person when the team is small, work is clear, and the format produces a useful plan.
Use story by story when work is getting lost, too many items are in progress, or the team needs better visibility into each product backlog item.
Use the board when the team needs a stronger connection between people, work, and the sprint goal.
And change the format when it stops helping.
The Daily Scrum is not about giving everyone a turn to talk.
It is about helping the Developers decide how to work together today so they can make the best possible progress toward the sprint goal.