What do I note during daily stand-ups?
What should you take note of, and what actions should you consider taking afterwards?
Hello 👋, It’s Vibhor. Welcome to the 🔥 paid member only🔥 edition of Winning Strategy: A newsletter focused on enhancing product, process, team, and career performance. Many subscribers expense this newsletter to their Learning & Development budget. Here’s an expense template to send to your manager.
Do you take notes during daily stand-ups?
I won’t be surprised if you don’t. Most Scrum Masters have no idea what they "should" actually be noting down.
I’ve seen even experienced Scrum Masters second-guess what they’re supposed to capture during standups.
There are some Scrum Masters who proudly declare they're "documenting everything" when they're really just collecting unnecessary clutter. Some don’t take notes at all.
But there are also those who not only take notes but thoughtfully organize their observations in a way that genuinely helps their teams improve.
What is the difference?
The "difference" lies in understanding what truly matters during a Daily Standup and what deserves to be captured.
So!
What exactly should you be noting?
Let's find out.
Why is it important?
You might be wondering, “Does it really matter if I take notes during stand-ups?”
Short answer… it does.
Not because you need another to-do on your plate or someone expects you to keep tabs on every word spoken.
But because the right notes turn conversations into insight.
For example:
Let’s say a team member mentions the same blocker three days in a row. Another team member hints they’re falling behind on their work. Someone else keeps mentioning dependencies that aren’t being addressed.
If you’re not taking notes or, worse, if you’re taking notes without purpose, you are likely to miss these signals.
When you capture what matters, you make the invisible… visible.
You spot recurring blockers
You notice who’s always overloaded, or who’s quietly picking up the slack
You see which dependencies are a hindrance, sprint after sprint
Without notes, these things slip right past. With them, you’re equipped to help, not just react.
So, yes. It matters.
And here’s what you must note and why.
#1 Attendance and Energy
Let's start with the basics.
Who showed up? Who didn't?
Sounds obvious, right? Almost too simple to mention. However, there's more to this than simply taking attendance like a schoolteacher.
Note: You don’t do it out loud. You silently take a note on who is present.
When you TRACK who's present (and who isn't), then OVER TIME you start to see the patterns.
For example:
Is someone regularly missing stand-ups? This signals disengagement, overwork, or even personal challenges.
Did someone unexpectedly skip today? This signals a blocker they’re hesitant to share, or a priority conflict.
Your notes tell that kind of story.
Next…
Don't just stop at who's physically there. Pay attention to who's mentally present, too.
Track the team’s energy and mood.
What’s the vibe? High energy? Everyone is joking, chatting, and sharing openly? Or is the room tense, quiet, distracted, and people just going through the motions?
Just note what stands out.
Who’s present, who’s absent?
Any big changes in energy or mood?
Is the team unusually quiet or chatty?
Is there tension in the air, or is everyone engaged?
Here’s why this matters:
Team’s attendance and energy are early warning signals.
They tell you when to check in, when to step back, and when something might need your (or someone else’s) attention before it becomes a big problem.
So, note it!
Not every detail. Just what’s different, what’s unusual, and most importantly, what feels off.
#2 Impediments and Blockers
The stuff that can really derail a sprint: blockers.
If there’s one thing every Scrum Master should be laser-focused on during stand-ups, it’s impediments and blockers.
Your job is to:
notice them,
document them, and
ensure they’re addressed
And you do this whether they’re explicitly mentioned or they are subtly implied.
What do I mean by that?
Explicitly Mentioned Blockers
Sometimes, team members directly call out what’s holding them back. When this happens, you take notes on:
Who’s affected?
What’s the Impediment/blocker?
What’s the next step, and
Who owns it?
For example, your notes might look something like this:
Team Member 1: Waiting for access from the DevOps team. Follow up with the DevOps lead.
Team Member 2: Stuck on a bug. Needs help from…
You create a clear record of what’s happening and who’s responsible for resolving the issue.
Implicitly Noticed Blockers
Not every blocker will be explicitly stated. Sometimes, you’ll need to read between the lines.
For example:
Is someone stuck in the same place for multiple stand-ups but hasn’t explicitly asked for help?
Are dependencies being mentioned repeatedly but not addressed?
These subtle cues are just as important as the explicit ones.