1 Overview
The daily standup is often treated as a status meeting where each person reports what they did yesterday and what they will do today. That framing turns a flow-focused ceremony into a reporting ritual. The standup exists to help the team manage the movement of work, not to update a manager. When the conversation centers on the board, the team can see where work is stuck, what is aging, and what needs attention before the day's work begins.
In both Scrum and Kanban, the standup is a short, recurring event that belongs to the people doing the work. In Scrum, it is one of several ceremonies inside a sprint. In Kanban, it is a daily checkpoint in a continuous flow. The purpose is the same: inspect how work is moving and adapt. Status reporting is a byproduct, not the goal. When the standup is about flow, the team asks different questions. Instead of "What did you do?" the team asks "What is moving, what is blocked, and what is at risk of missing a commitment?" That shift changes who speaks, what gets discussed, and how long the meeting lasts.
The standup is not a replacement for planning, refinement, or retrospectives. It is a daily pulse. Its value comes from being brief, focused, and oriented toward the work on the board. If it becomes a long status round-robin, it loses its purpose and the team loses time. The method board comparison matters here: Scrum and Kanban both use the standup, but they frame flow differently. Scrum uses the sprint goal and sprint backlog as the context. Kanban uses work-in-progress limits and flow metrics. In both cases, the standup is a tool for managing flow, not for reporting status.
2 The problem this method was built to solve
Software teams often struggle with work that is invisible, unevenly distributed, and stuck in queues. Before daily standups became common, many teams coordinated through written status reports, long meetings, or ad hoc interruptions. Those approaches hid the real problem: work was not flowing. People were busy, but features were not moving to done. The standup was introduced as a lightweight way to surface blockers and adjust the plan daily. Its original intent was to replace lengthy status meetings with a short, focused conversation about the work.
The problem was not a lack of information; it was a lack of shared context. Team members knew what they were doing individually, but no one had a clear picture of the whole. Work would sit in a queue waiting for review, testing, or a decision. The standup created a daily moment to look at the board together and ask what needed to move. In Scrum, this was tied to the sprint goal and the sprint backlog. In Kanban, it was tied to the flow of work through a defined workflow. Both approaches recognized that status reporting alone does not improve delivery.
A second problem was coordination overhead. When teams grow, the number of dependencies and handoffs increases. Without a daily synchronization point, people resort to meetings, messages, and interruptions. The standup was designed to be a predictable, time-boxed event that reduces the need for constant ad hoc communication. It gives everyone a chance to hear about blockers and to offer help. The method was built to solve coordination and flow problems, not to create a reporting obligation. When it drifts into status reporting, it solves neither problem well.
3 How one cycle runs, from ready to done
In Scrum, a cycle begins with a sprint planning session where the team selects a sprint goal and a set of product backlog items. Those items become the sprint backlog. Work then moves through the team's workflow: design, development, testing, and so on. The daily standup happens each day of the sprint. The team looks at the sprint backlog and the board, focusing on what is in progress, what is blocked, and what is at risk of not meeting the sprint goal. The standup is not a status round; it is a chance to re-plan the day. At the end of the sprint, the team reviews the increment with stakeholders and holds a retrospective to improve.
In Kanban, there is no fixed sprint. Work is pulled through a workflow as capacity allows. The cycle starts when a work item is selected from a queue or backlog and placed on the board. The team uses work-in-progress limits to constrain how many items can be in each stage. The daily standup focuses on the board: which items are moving, which are aging, and which are blocked. The team may also hold replenishment meetings to decide what to pull next and delivery reviews to inspect completed work. The cycle ends when an item reaches the done column and is delivered. The standup is a daily opportunity to adjust the flow, not to report on individual tasks.
In both methods, the standup is a short event, often fifteen minutes. The team stands up to keep it brief, though that is a convention, not a rule. The conversation should be about the work, not the people. If someone is not needed for a particular discussion, they can step away. The goal is to keep work moving from ready to done. The standup supports that goal by making flow visible and by surfacing impediments early. When the standup is about flow, the team leaves with a shared plan for the day and a clearer view of what needs attention.
4 Roles and how they divide the work
Scrum defines three roles: product owner, scrum master, and developers. The product owner is accountable for maximizing the value of the product and managing the product backlog. The scrum master is accountable for establishing Scrum as defined in the Scrum Guide and helping the team improve. The developers are the people who create the increment. In the daily standup, the developers are the primary participants. The product owner and scrum master may attend, but the standup is for the developers to coordinate their work. The scrum master may facilitate if needed, but the goal is for the team to self-manage. The product owner can clarify priorities, but should not turn the standup into a status report.
Kanban does not prescribe roles. It is a method for managing flow, not a framework with defined accountabilities. Teams using Kanban may have a service manager or flow manager who helps with process improvement and removing blockers. The team itself is responsible for managing the board and the work. In the daily standup, anyone who works on the flow can participate. There is no separate scrum master or product owner unless the organization chooses to assign those responsibilities. The standup is typically facilitated by a team member or rotates. The focus is on the work items and the policies that govern flow. Roles are defined by the team's context, not by the method.
In both cases, the standup is not a place for role-based reporting. The product owner does not need a status update from each developer. The scrum master does not need to hear what everyone did yesterday. The team needs to know what is moving and what is blocked. The division of work is visible on the board. The standup is a chance to adjust that division if needed. If one person is overloaded or a task is stuck, the team can swarm or reassign. The roles exist to support flow, not to create reporting lines. When the standup is about flow, the roles fade into the background and the work takes center stage.
5 Artifacts worth keeping
Scrum has three formal artifacts: the product backlog, the sprint backlog, and the increment. The product backlog is an ordered list of what is needed to improve the product. The sprint backlog is the set of product backlog items selected for the sprint, plus a plan for delivering them. The increment is the sum of all completed work during a sprint, and it must be usable. In the daily standup, the sprint backlog is the primary artifact. The team looks at the sprint backlog and the board to see what is in progress and what is done. The product backlog may be referenced if priorities need clarification. The increment is not discussed in detail unless it affects the sprint goal. The standup is not a review of the increment; that happens in the sprint review.
Kanban uses a visual board as its central artifact. The board shows the workflow stages and the work items in each stage. Work-in-progress limits are explicit policies that constrain how many items can be in a stage. Flow metrics, such as cycle time and throughput, are often tracked to understand how work moves. In the daily standup, the board is the focus. The team looks at the cards, the limits, and the flow. They may discuss blocked items, aging work, and whether any limits need adjustment. The board is not a status report; it is a model of the work. The team updates it as work moves. The standup is a chance to inspect the board and decide what to do next.
Both methods value artifacts that make work visible. In Scrum, the sprint backlog and the board (often a task board) serve that purpose. In Kanban, the board and the flow metrics do. The artifacts worth keeping are the ones that help the team manage flow. If an artifact becomes a reporting tool for managers, it loses its value. The standup should use artifacts to have a conversation about flow, not to produce a status report. The team should keep artifacts that are useful and discard those that are not. The method board comparison shows that artifacts differ, but the principle is the same: make work visible and use that visibility to improve flow.
6 Where this method breaks down
The daily standup breaks down when it becomes a status meeting. This happens when the team reports to a manager, when each person gives a detailed update, or when the conversation focuses on individual activity rather than the work on the board. In Scrum, this often occurs when the scrum master or product owner treats the standup as a control point. In Kanban, it can happen when the board is not updated or when the team lacks clear policies. When the standup is about status, it takes too long, people disengage, and the real flow problems remain hidden. The ceremony becomes a chore rather than a tool.
Another breakdown occurs when the standup is used to solve problems that need a separate conversation. Detailed technical discussions, design debates, and conflict resolution should not happen in the standup. The standup is for coordination, not for deep work. If a topic needs more time, the team should take it offline. When the standup tries to do too much, it loses its focus and becomes ineffective. The time-box is there to protect the team's time. Ignoring it leads to long meetings and reduced participation.
In Scrum, the standup can also break down when the sprint goal is unclear or when the sprint backlog is not refined. The team then talks about tasks without a shared purpose. In Kanban, the standup can break down when work-in-progress limits are ignored or when the board does not reflect reality. Without accurate flow data, the team cannot make good decisions. Both methods require discipline to keep the standup about flow. The tradeoff is that the standup is simple but easy to misuse. It works only if the team commits to using it for flow, not for status reporting. When it breaks down, the fix is to return to the purpose: inspect the work, surface blockers, and adapt the plan.
7 Frequently asked questions
Is the daily standup mandatory in Scrum? Yes, the daily scrum is a required event in Scrum. It is time-boxed to fifteen minutes and is held at the same time and place each day. The purpose is to inspect progress toward the sprint goal and adapt the sprint backlog. The developers own the event. If the product owner or scrum master attends, they should not turn it into a status report. The standup is not a status meeting; it is a planning meeting for the day.
How is the standup different in Kanban? In Kanban, the standup is not prescribed by a framework, but it is a common practice. It focuses on the flow of work through the board. The team discusses work items, blockers, and flow metrics. There is no sprint goal, so the context is the workflow and the work-in-progress limits. The standup may be shorter or longer depending on the team's needs. It is often held in front of the board, and the team updates the board as they talk.
What should we do if the standup becomes a status report? First, recognize that the problem is the focus, not the format. Shift the conversation to the board. Ask questions like: What is blocked? What is at risk? Where is work piling up? Who needs help? Avoid asking each person what they did yesterday. If someone starts giving a detailed update, redirect to the work item. Keep the standup time-boxed. If needed, use a timer. The team should agree on the purpose of the standup and hold each other accountable. If the standup is about flow, it will be shorter and more valuable. If it is about status, it will feel like a chore. The choice is the team's.