The Daily Scrum — Checklist, Best Practice & Common Mistakes

Jonathan Fager Jonathan Fager
7 minute read
The Daily Scrum guide — checklist, best practice & common mistakes

What is the Daily Scrum?

The Daily Scrum is a central ceremony (meeting) in the Scrum framework. It’s one of the “rituals” defined in the Scrum Guide, written by Jeff Sutherland and Ken Schwaber.

The Daily Scrum is a 15-minute meeting specifically for the Development Team. The purpose is for the team to:

  • Have a daily check-in to discuss the current Sprint Goal
  • Make sure the team is on track to hit the Sprint Goal
  • Adapt the Sprint backlog if needed
  • Create an actionable plan for the day of work ahead

In Scrum we always work towards the Sprint Goal and the Daily Scrum has the specific purpose of helping us reach that Sprint Goal.

As defined in the Scrum Guide the purpose of the Daily Scrum is to:

Optimize the probability that the Development Team will meet the Sprint Goal. 

The Product Owner and Scrum Master are welcome to join, especially if they are also working in the team as developers (which is a story for another time), but be aware that the Daily Scrum is a meeting primarily for The Development Team to discuss, adapt, and solve issues.

Structures and techniques

There’s probably as many different structures and techniques for the Daily Scrum as there are Scrum teams, and you and your team should develop a structure and technique that works best for you.

As written in the Scrum Guide…

Daily Scrums improve communication, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

Originally, the official Scrum Guide outlined three questions as a basis for the Daily Scrum:

  • What did I do yesterday? [that helped us meet the Sprint Goal]
  • What will I do today? [to help us meet the Sprint Goal]
  • Do I need any help / Is there any trouble? [to help us meet the Sprint Goal]

However, these questions were removed from the Scrum Guide in 2020.

I personally believe these questions serve their purpose and should still be used in the Daily Scrum.

My best guess for their removal is due to how these questions are a potential slippery slope towards turning the Daily Scrum—a planning meeting for the next 24 hours—into a stakeholder status update or check-in meeting.

The Daily Scrum vs Stand-ups

The Daily Scrum and Stand-ups are often confused, misunderstood and used interchangeably.

The truth is that these are two differing formats coming from two separate software development frameworks. Even though they are very similar, let’s start with the key differences between the two.

QueryThe Daily ScrumStand-ups
Who?Developers (Others optional)Whole team
How?15 minutes, same time, same placeUsually morning
Topic?Are we on track to reach our Sprint Goal?Status update meeting / team check-in
Goal?Plan the next 24 hours. Make sure no one is blocked from workingMake sure work is progressing. Give an overview of work in progress.
Quirks?Organized by the Development Team. Very few rules to followDone standing, to encourage shorter meetings

Steal with pride – mixing the two formats

You may have realized that all companies seem to make their own minor (or major) adjustments to Scrum. And even though Stand-ups aren’t an official part of Scrum, there is nothing stopping you from “stealing with pride”.

I’ve personally worked in teams where the three questions originally outlined in the Scrum Guide for Daily Scrums have been a game changer and a great start to every morning. Especially, when we learnt to reduce clutter by reframing our replies to those three questions solely around the topic — “…to help us meet the Sprint Goal”.

The Daily Scrum for remote / hybrid teams vs collocated teams

The Daily Scrum works very well across different team setups — regardless of whether you are all in the same room, or spread across the world. The success of the meeting boils down to facilitation, respect and inclusiveness.

The success of the meeting boils down to facilitation, respect and inclusiveness.

I’ve worked in a team where we had three people in an office in Gothenburg and three people in an office in Gdansk (one outside Lviv and one in a subway station in Kiev during the invasion of Ukraine). We made that work.

It worked because our Daily Scrums were to the point and effective. We enforced video-chat (webcams on) to be more inclusive, although one colleague strongly refused on days where their hair wasn’t fixed.

We also enforced a strict timebox and often used Zoom’s breakout rooms after the meeting ended, if needed, to discuss potential issues, ask for help or clarify issues and stories.

Moral boosting

As a Scrum Master, I personally really appreciated those morning meetings as our Daily Scrum was a powerful way to build team spirit and get to know each other better.

People often joined a few minutes early to chat, and sometimes stayed a few minutes later to chat, usually about non-work stuff.

My previous boss always ended the Friday Daily Scrum with a “It’s Friday so remember, Whiskey is allowed before lunch!”. If he forgot he would receive some very angry Slack messages.

In Sweden where I work and live, Wednesdays are also called “small saturday”. We even got team t-shirts printed saying “Have A Lovely Small Saturday”. This became our unofficial Wednesday dress code.

It might sound cheesy, but our Daily Scrums became a great morale booster and helped us have come together as a remote team.

The Daily Scrum agenda and checklist – look no further!

Here it is. My boilerplate for implementing the Daily Scrum in your organization. Don’t carbon copy it. Rather, use it as an inspiration and make sure it fits your organization, colleagues and culture.

Daily Scrum agenda and checklist

Who?

  • All developers that are actively working on the project
  • The Scrum Master, to facilitate and make sure people “behave”. (optional)
  • Product Owner / Product Manager, to answer questions and help prioritize and solve issues. (optional)
  • Any other colleagues that might help your team reach the Sprint Goal. (optional)

When & Where?

  • Same time, same place every day!
  • Timebox to 15 minutes.
  • Tools like Zoom, Microsoft Teams, Google Hangouts and Around all work great, but work hard to keep people engaged.

How?

  • Answer the following questions:
    • What did I do yesterday that helped us meet our Sprint Goal?
    • What will I do today that will help us meet our Sprint Goal?
    • Do I need any help / is there anything blocking us from meeting our Sprint Goal?
  • Avoid long discussions. If needed, ask the involved parties to schedule a meeting after the Daily Scrum.
  • Can it wait? Gather the input for the Sprint Planning, Backlog Refinement or Retrospective.

Tips

  • Schedule the Daily Scrum 30 – 60 minutes into the working day. This helps people prepare, read emails, check for updates, check log, etc. This decreases the otherwise quite common “ehh I’ll have to check that” type reply.
  • Randomize the order of who speaks. I’ve found this keeps people more engaged. They don’t zone out as they might have otherwise, if they knew their turn wasn’t for a while.
  • Look to include the Product Owner and Scrum Master in the Daily Scrum. This helps to build team spirit and avoid an “us vs them” mentality.
  • For remote teams this helps the feeling of having colleagues that care about them, which is very important to some individuals.

Troubleshoot your Daily Scrum

Pitfalls and anti-Scrum patterns

So what if your Daily Scrum just isn’t working well? Whether the team is struggling to come together on issues, or they are just losing interest, there are always ways to reflect and improve the meeting. Let’s look at some common issues.

Interruptions

A common issue with the Daily Scrum is interruptions. Strictly enforce “respect and order” in your Daily Scrums. This means:

  • Conduct the Daily Scrum in a quiet and calm environment
  • Pay attention to the meeting, don’t fiddle around with other stuff
  • No interrupting
  • No talking over each other
  • Be on time
  • Be a decent colleague

If any of these become a recurring issue, bring it up on the Sprint Retrospective and strongly push for change.

“No issues”

I’ve seen this several times. During the Daily Scrum, the team will report that there is nothing blocking them, yet stories are not progressing for an unknown reason.

The fix?

Stress the importance of stating blockers and impediments during the Daily Scrum and work on the morale and headspace in the meetings — are people afraid to share? Create an environment where failure is acceptable and can be learnt from, as a team.

Status meeting

It’s fair to say that the Daily Scrum does have a status aspect to it, but it’s main purpose is not to check-in. The purpose is to plan the day ahead.

As such, Daily Scrums that go like this:

“Yesterday I was fixing bugs and today I will fix bugs and there is nothing blocking me”

…is not particularly helpful.

If that’s actually the plan and everything is going smoothly, great! But that’s seldom the case. What I’d rather see would be something along these lines.

“Since the primary goal of the Sprint is to get the new payments system working I spent most of yesterday helping Sarah with the “custom value Stripe payments” bug. It turned out it was a type error, so be sure to check that when you use the payments API.

Today I’ll pick up a story from the Sprint backlog and spend some time on code-review.

The only thing still blocking me is that I’m still waiting on the code-review of JT-412, so it would be great if anyone could take a look at that.”

Of course, this does have the status aspect—stating what is going on—but it also serves to tell the team about the progress towards the Sprint Goal and outlines a plan for the next 24 hours.

Lack of preparation

“Erhm what did I do yesterday.. Haha… I don’t remember. Uuhh”.

If I’d gotten a penny for every time I’ve heard this… You wouldn’t come unprepared for other meetings, so don’t do it for the Daily Scrum.

For the meeting to be effective and strictly timeboxed, make sure you and your team members prepare a little.

Try to write down what you did yesterday, if you typically forget. Spotted a blocker throughout the day? Write that down too.

If you’re forgetful, try using sticky notes on your desk for note taking and you’ll quickly see efficiency improvements in your Daily Scrums.

If you’re forgetful, try using sticky notes on your desk for note taking and you’ll quickly see efficiency improvements in your Daily Scrums.

TL;DR

  • The Daily Scrum is a 15 minute meeting focused on assessing whether you’re on track to meet your Sprint Goal.
  • After the Daily Scrum your team should have a plan for the next 24 hours.
  • It’s classically only for the Development Team, but the PO and SM are a great addition.
  • The Daily Scrum and Stand-ups are technically different, but it’s not worth worrying about too much.
  • The best teams keep their Daily Scrums short and respect each other’s time.
  • These three question should help guide the meeting:
    • What did I do yesterday?
    • What will I do today?
    • Do I need any help?

FAQs

Why should the Product Owner attend the Daily Scrum?

There are several reasons why the Product Owner (PO) might want to attend the Daily Scrum:

  • Unblock work
  • Prioritize and clarify work
  • Help facilitate cross-team communication
  • Give additional business context of stories
  • Continually work to develop and improve the agile processes
  • Learn about how the team is progressing
  • Build stronger relationships with the team
Which role is most likely to communicate an impediment during a Daily Scrum?
As the Daily Scrum is “the developers' meeting”, the most likely role to communicate an impediment is a developer. An impediment to the Sprint Goal must be addressed. Avoid long discussions. If it can be solved quickly, great. If not, reach out to the Scrum Master to facilitate another meeting and solve the issue.
Who is required to attend the Daily Scrum?
Officially, the only required attendees are the Development Team. However, you should invite anyone that can help the team meet their Sprint Goal.
Who starts the Daily Scrum?
This is not defined in the Scrum Guide, and is instead left up to team themselves to decide. In most teams I’ve worked with, the team lead or Scrum Master starts the Daily Scrum by saying good morning and updating the team about any team members being sick, stuck in traffic or similar. This way the team can take that into consideration when planning the day.
What is the timebox for the Daily Scrum?
The timebox for the Daily Scrum is 15 minutes.
Is the Daily Scrum recommended for collocated teams?
Collocated teams can greatly benefit from a Daily Scrum.
A developer identified a major technical issue during a Daily Scrum. What should the team do?
Can it be solved directly? Great. If not, take it outside the meeting. The Scrum Master will make sure that the issue reaches the right stakeholders and that the process to fix it starts.
What is the difference between a Stand-up and a Daily Scrum?
  • The Daily Scrum is defined in the Scrum Guide and is a meeting to make sure that the team is on track to meet their Sprint Goal.
  • The Stand-up comes from eXtreme Programming and is in many ways very similar to the Daily Scrum, but is considered more of a status and stakeholder update meeting, rather than being focused on a Sprint Goal.
Jonathan Fager

Jonathan Fager

Well hello there! I'm Jonathan, Product Manager at Ratt. I sail, do triathlons and brew beer for life. I work with software teams, product management and the intersection between business and tech.

Continue reading

  • What does a product manager actually do?

    What does a product manager actually do?

    Product managers are creators. They’re problem solvers. They facilitate solutions that people value.
    Read more
  • Lean Agile – Bringing Them Together To 5x Your Delivery

    Lean Agile – Bringing Them Together To 5x Your Delivery

    Lean and agile have a lot of similarities. They both focus on rapid, iterative development in order to deliver value to customers faster and avoid wasted development time by producing unnecessary features.
    Read more
  • Use Cases vs User Stories. What Are The Differences?

    Use Cases vs User Stories. What Are The Differences?

    Whilst user stories and use cases were both designed to describe the expected system behavior from a user's perspective they are two very different tools. And whilst they do share similarities they have far more differences. Let's dig in.
    Read more