Daily Standup Assessment

Every question on the Daily Standup Assessment maps to a habit that separates teams who use the standup to coordinate the day from teams who use it to read status into the air. Below is a breakdown of each scored question: what it measures, why it matters, and concrete steps to improve if your team scored low.

Score Interpretation

How to read your total maturity score (0 to 100).

1 to 20: Struggling. The standup is not functioning as a coordination event. It happens rarely or without the people who do the work, the board is closed, and blockers either never come up or come up and go nowhere.

21 to 40: Developing. The event happens, but it is a status round. People report to the Scrum Master, the sprint goal is never mentioned, and the impediments raised on Monday are still open on Friday.

41 to 60: Norming. The habit is real and the basics hold. The next gains come from working the board instead of the roster, giving every blocker a named owner, and keeping the event inside fifteen minutes.

61 to 80: Performing. The standup is working. The team meets daily, uses the board, and resolves most blockers quickly. Tune the peer-to-peer coordination and how tightly the conversation stays on the sprint goal.

81 to 100: Thriving. The standup is a genuine advantage. The team replans the day in fifteen minutes, surfaces dependencies before they bite, and holds itself accountable to the sprint goal without the Scrum Master driving it.

Team Size

What is the number of team members including the Scrum Master, Product Owner, and Tech Lead?

Why it matters: A standup is a fifteen minute coordination window, and the math is unforgiving. Six to nine people can each speak, hear everyone else, and still have time to sort out an overlap. Below six you usually do not have enough skills in the room to reroute work when someone gets stuck, so the event becomes a status check with no coordination available to do. Above twelve, the timebox forces everyone into headlines, and the specific handoffs that make a standup worth holding never surface.

To improve your score: If you are at thirteen or more, look hard at whether you actually have two teams sharing one board. Split them so each runs its own standup against its own sprint goal. If you are under six, confirm the Scrum Master, Product Owner, and Tech Lead are counted, and check whether part time members are attending a different standup instead of yours. A team that cannot cover its own work end to end will keep discovering that in standup and having nowhere to take it.

Attendance

How many team members were in attendance?

Why it matters: The standup only produces a shared plan for the day if the people doing the work are in the room. When half the team is missing, the people who show up coordinate around a picture with holes in it, and the absent half learns about a change hours later in a message thread. Chronic partial attendance is also how a team quietly decides the event is optional, and once that belief sets in, attendance keeps sliding.

To improve your score: Track attendance for two weeks and look for the pattern rather than reacting to one bad day. If the same people miss every time, the slot conflicts with something standing, so move the standup instead of repeating the ask. Pick a time that works for every time zone the team spans, even if it is inconvenient for the majority. If someone truly cannot attend, have them update their cards before the event and name who needs to hear it, but treat that as a stopgap rather than a substitute.

Roles Present

Who was present?

Why it matters: The standup needs three specific capabilities in the room. The Scrum Master protects the timebox and owns removing impediments. The Product Owner answers priority and scope questions on the spot so nobody loses a day waiting for a decision. The Tech Lead spots the sequencing problem and the two people unknowingly working the same seam. When the Product Owner is absent, questions turn into tickets that sit. When the Tech Lead is absent, overlaps get discovered in the pull request.

To improve your score: Publish a short list of who is required and who is optional, and hold to it. Give the Product Owner a standing five minutes immediately after standup for scope questions so those conversations do not consume the event itself. If the Product Owner cannot attend, name a proxy with real decision authority rather than deferring every question to tomorrow. Full team presence is the target, so make partial attendance visible in retrospective rather than absorbing it.

Facilitation

Was the Scrum Master present and did they facilitate?

Why it matters: Present but silent is the most common and most costly pattern here. Facilitation is what keeps the event from collapsing into a round of individual reports. The facilitator ends the tangent, parks the design debate, pulls in the person who has not spoken, and makes sure every impediment leaves the event with a name attached. Without facilitation, the standup runs long, the loudest technical opinion sets the agenda, and the problems raised evaporate the moment the call ends.

To improve your score: Give the Scrum Master explicit ownership of facilitation and a repeatable flow: read the sprint goal, walk the board from right to left, ask what is blocking flow, close with the parking lot and named owners. Name a backup facilitator so one absence does not produce an unfacilitated fifteen minutes. If the Scrum Master is deliberately stepping back so the team can self organize, make that a stated experiment with a rotating team facilitator rather than a silence people have to interpret.

Standup Cadence

How often do Daily Standups occur?

Why it matters: Daily is in the name because the value of the event decays fast. A team meeting three days a week is making decisions on two day old information for the rest of the week, and the gaps are exactly where work quietly diverges, where a blocker sits unspoken, and where two people build the same thing. Skipped days also break the rhythm that makes the event feel automatic, and an event people have to remember is an event people miss.

To improve your score: Put a standing block on the calendar for every business day and defend it the way you defend Sprint Planning. If the team says daily is too much, the real complaint is almost always length or value, so fix the content rather than cutting the frequency. Keep it fifteen minutes, keep it on the board, and let the team feel the difference. Co-located teams still need it, because informal hallway contact is not the same as a shared plan for the day.

Time and Place Consistency

Is the event held at the same time and place?

Why it matters: A standup that moves is a standup people miss. A fixed time and place removes the daily negotiation about when and where, and it protects the rest of the calendar because everyone can plan around a known point. Teams that shift the standup to accommodate whoever is busiest tend to drift later and later until it is no longer a start of day event and no longer shapes the day at all.

To improve your score: Pick one time and one link or one physical spot and hold both for a full quarter. Schedule it early enough to shape the day but late enough that every time zone on the team can join awake. Put the location in the calendar invite and in the team channel so nobody has to hunt for it. When a stakeholder asks you to move it, treat that as a reason to protect the slot rather than a reason to move again.

Cameras On

Were cameras on?

Why it matters: A standup is a fifteen minute read of the team, and most of that read is not in the words. Cameras are how a facilitator catches the person who says they are fine while looking stuck, or the hesitation before someone accepts a plan they do not believe in. Audio only standups hide all of it, and silence gets recorded as agreement. Cameras off also makes multitasking easy, and a team half attending to a chat window is not coordinating anything.

To improve your score: Set a team norm for cameras on and explain the reason rather than just stating the rule. Keep the event short enough that being on camera for it is a reasonable ask. If people consistently opt out, find out what is behind it, whether that is meeting load, home setup, or discomfort, and solve that instead of repeating the request. In person standups satisfy this automatically.

Timebox

How long did the meeting last?

Why it matters: Fifteen minutes is not an arbitrary limit. It is the constraint that forces the event to be about coordination instead of status. When a standup runs past fifteen minutes it is almost always because a problem is being solved in front of an audience of people who do not need to be there. The cost compounds: attention drops, people start arriving late, and the event stops being worth defending on anyone’s calendar.

To improve your score: Run a visible timer and let it end the event. Use a parking lot aggressively: the moment a topic needs more than about a minute, name the two or three people who will stay after and move on. If you regularly need more than fifteen minutes with nine or fewer people, the usual causes are a board that is not open or people narrating history instead of naming what changes today. Fix those two things before you consider a longer timebox.

Board Visibility

Was the board visible?

Why it matters: Without the board on screen, the standup runs from memory, and memory is organized around people rather than work. That is how you get an event where everyone describes their own week and nobody notices the card that has been in progress for six days. A visible board keeps attention on the items closest to done, makes blocked and aging tickets impossible to skip, and gives the team something concrete to point at when they disagree about what is actually moving.

To improve your score: Share the board at the start of every standup and walk it from right to left, so nearly finished work gets attention before new work does. Update cards live during the event so the board reflects reality by the time you close. If your board is chronically stale, fix that first, because a board nobody trusts makes the event feel pointless and teams stop opening it.

Blockers Discussed

Were blockers discussed?

Why it matters: Surfacing impediments is the highest value thing this event does. Note that discussing blockers only earns full credit when follow-up actions get assigned, because a blocker named without an owner is just a complaint with better framing. Teams that never raise blockers are rarely blocker free. More often they have learned that saying something out loud produces nothing, so they stop spending the social cost.

To improve your score: Ask about impediments directly instead of hoping they arrive inside a yesterday and today update, because people under report when the question is implicit. Before the event closes, every blocker should have a named owner and a next step, and the Scrum Master should own the ones that need authority the team does not have. Make raising a blocker safe by treating it as a service to the team rather than an admission, and thank the person who raises the awkward one.

Blocker Follow Through

Once a blocker is raised, does it actually get followed up on and resolved?

Why it matters: This is where most standups leak their value. A blocker mentioned every morning for a week that never moves teaches the team the event is theater, and the lesson transfers: people stop raising the next one. Repeatedly unresolved impediments also point at something structural, usually a dependency the team cannot clear alone, an approval bottleneck, or a Scrum Master carrying more escalation than one person can absorb.

To improve your score: Keep an impediment list where the whole team can see it, with an owner and the date it was raised. Open standup by clearing that list before touching new work. Set an aging rule, for example anything open more than two days gets escalated by name to the person who can actually remove it. Review how long impediments stayed open during retrospective so the pattern becomes visible instead of anecdotal.

Dependencies

Were dependencies discussed?

Why it matters: Dependencies are the blockers that have not happened yet. Naming them in standup is the cheapest moment to resequence work, open the conversation with the other team, or split the story so the part you control keeps moving. Teams that only discuss a dependency once it has become a blocker spend the back half of every sprint reacting to somebody else’s queue.

To improve your score: Make it a standing question: what does today’s work need that we do not control? Record each dependency on the card with a named contact and the date you need it by. When another team owns part of the work, get the request into their queue the same day rather than waiting for a scheduled sync. As with blockers, a dependency named without an owner and a next step does not count as handled.

Sprint Goal Reviewed

Were sprint goals referenced or reviewed during the standup?

Why it matters: The sprint goal is what turns a set of individual updates into a plan. Without it, the standup measures activity rather than progress, and a team can have a genuinely busy week while the goal quietly slips. Standups that never mention the goal are usually the same standups where nobody realizes the sprint is in trouble until the demo, when there is no time left to do anything about it.

To improve your score: Put the sprint goal at the top of the board and read it out at the start of the event, every day, even when it feels repetitive. Close with one direct question: are we still on track for the goal, and what would we change today if we are not? When the answer is no, that is the moment to renegotiate scope with the Product Owner, not on the last day of the sprint.

Goal Focus

Does the standup stay focused on the sprint goal rather than drifting into unrelated topics?

Why it matters: Drift is the most common way a fifteen minute event becomes a thirty minute one, and it always starts reasonably: a design question, a production issue, an update about a different project. The cost is that the people who needed two minutes of coordination lose the room, and the work closest to the sprint goal ends up getting the least attention because it came up last.

To improve your score: Keep a parking lot visible to the whole team and move anything that is not about today’s progress toward the goal into it, with a name and a time to continue. Give the facilitator explicit permission to interrupt, and agree to that as a team so the interruption reads as the job rather than rudeness. If the same topic drifts in every single day, it needs its own short standing session with the three people it concerns.

Participation in Updates

Did every team member that was present give an update?

Why it matters: When someone attends but never speaks, the team loses the one thing the standup exists to surface: whether that person’s work is moving and whether it touches anyone else’s. Silence is rarely disinterest. It usually means a few voices dominate, or that updates are being delivered to the Scrum Master and quiet members see no reason to add to that queue. Either way, the coordination that person needed does not happen.

To improve your score: Walk the board instead of going around the roster, so every item in flight gets a voice attached to it and nobody can be skipped silently. Have the facilitator invite people who have not spoken before closing the event. If someone consistently has nothing to report, check whether they are working outside the sprint or waiting on something nobody has escalated, because both are worth knowing.

Coordination Style

Did team members primarily address each other directly, or mostly report status to the Scrum Master?

Why it matters: This is the question that separates a standup from a status meeting. When everyone faces the Scrum Master and recites what they did yesterday, the event is reporting up rather than coordinating across, and the handoffs that should have taken ten seconds in the room instead happen later over messages, or not at all. Peer-to-peer standups sound different: people ask each other for help by name, claim work, and settle sequencing on the spot.

To improve your score: Have the Scrum Master visibly step back, stop being the person everyone looks at, or hand facilitation to a rotating team member. Walk the board rather than the roster so the conversation attaches to work instead of individuals. Coach people to speak to the person their work touches by name and to end with an ask rather than a summary. When someone reports to the Scrum Master, redirect it: ask who else on the team needs to know that.