Let me start by stating what the Daily Scrum is not. The Daily Scrum is not a status review or report for anyone, including product owners, Scrum Masters, or stakeholders. This is both destructive and common enough that I feel it is important to call this out. Instead, the Daily Scrum is a chance for the team to transparently inspect and adapt how their sprint is going. It is an opportunity for course correction, not micromanagement. Even the physical orientation of the participants at a Daily Scrum is telling: are they collaboratively huddling in a circle, or is there one “person in power” at the front with the rest of the Development Team meekly answering questions?

I say this because the driving ethos and daily outcomes of your team’s Daily Scrum are more important than its exact manifestation. That said, here’s a format that I’ve found works reasonably well.

First, start the Daily Scrum at the same time and place, every single day. Some teams like to skip the Daily Scrum on days that they conduct Sprint Review and/or Sprint Planning, but this is a missed chance to reconnect before these important events. Ideally, your team should have a dedicated space with either a physical or electronic task board and burn-down chart visible to everyone. If you are distributed or remote, video is better than audio. Start the Daily Scrum on time, even if much of the team is missing… within a few days, attendance should improve as being late to a meeting in progress is more uncomfortable than being late to a meeting that hasn’t started yet.

Next, each development team member answers three questions—right from the Scrum Guide—as concisely as possible: “What did I do yesterday that helped the Development Team meet the Sprint Goal?” “What will I do today to help the Development Team meet the Sprint Goal?” “Do I see any impediment that prevents me or the Development team from meeting the sprint goal?”

As the member of the development team is speaking, watch out for the following. First, is everyone else looking directly at the person speaking and paying full attention? It can be a fun game for the speaker to look for anyone who isn’t paying full attention and nominate them as the next speaker. Second, are they speaking directly to tasks that are visible to the whole team on the board, or are they working on something else? I once had a mentor who told me that we should consider any effort towards work not on the board as an act of sedition, because it deeply impacts the product owner’s ability to support the team and saps the team of velocity made good against the sprint goal.

Third, sometimes answering these questions can spark an intense discussion. In order to keep the Daily Scrum to 15 minutes or less, any team member has the authority to designate the current topic a “parking lot” item, to be discussed with any interested parties immediately following the Daily Scrum. Any individual who does not wish to be present for that discussion need not attend.

Next, examine the team’s burndown chart and incomplete sprint backlog items. Does the team still feel confident that they can meet the sprint goal and finish everything in the sprint backlog by the end of the sprint? (And, no, meeting the sprint goal and finishing everything in the sprint backlog are not the same thing.) If not, why? Is there a course correction that will enable the team to succeed? If not, should one or more backlog items from the bottom of the sprint backlog be removed? This inspection and adaptation will improve the team’s chance of success and give the product owner a chance to provide early warning to their stakeholders if the goal will not be met.

A couple of other useful hints. It’s not the Scrum Master’s job to always facilitate the Daily Scrum, only to ensure that it happens, smoothly and within the 15-minute time-box. Also, people who are not on the team are always welcome to attend, so long as they do not interfere with the event. For instance, watch out for stakeholders demanding status updates or additions to the current sprint’s backlog; these sorts of requests should be directed to the Product Owner.

That’s the essence of the Daily Scrum. Feel free to experiment with the format. Be sure to track whether or not your experiment helped your team meet the sprint goal or provide an early warning.