Firstly, I believe that there is no such thing as an ideal stand-up. It depends on the needs of the team and their stage of maturity. I’ll run through several stand-ups that I consider “good” depending on what the team need. I’ve ordered the following in terms of team maturity, from least mature to most mature.

Traditional Team-Member Based Daily Stand-up

Scenario 1

Everyone arrives on time - if anyone is late, they are told they are late and asked to come on time in the future by the SM

The team stand around a physical sprint board that details all the work items. Some boards may have just stories on them, some boards may have the tasks for every story on them, depending on what the team needs

The SM asks each person the three daily questions:

What did you do yesterday?

This enables the planning of dependencies within the sprint as well as provide background in case other team members notice changes in their shared code - hopefully reducing surprises and, ultimately, preventing wasted time.

What are you going to do today?

This enables to rest of the team to offer support or advice. It also means you're a lot less likely to get two people trying to pick up the same work item and wasting time.

Do you currently have any impediment or blocker that you need help with?

The whole team is together, so this is a great opportunity to ask for help. Asking this question acts as both a reminder and also permission to ask for help.

The team listen to each other and offer brief help or advice to each other, or agree to chat after stand-up

Everyone leaves understanding what they are doing today.

All done in 15 mins or less

Scenario 2

Everyone arrives on time - if anyone is late, including the SM or PO, they are told they are late and asked to come on time in the future by their team members.

The team stand around a physical sprint board that details all the work items. Some boards may have just stories on them, some boards may have the tasks for every story on them, depending on what the team needs.

Each person takes turns to describe what they worked on yesterday, what they’ll be doing today and asks for help around problems they are encountering.

They say how long they think is remaining on their piece of work and what happens next.

This enables the team to plan their work more efficiently. It can also spark questions like: Why didn't you complete that item yesterday like you said? What's changed? Who's going to work with you on the next stage?

The team listen to each other and offer brief help or advice to each other, or agree to chat after stand-up.

Everyone leaves understanding what they are doing today, and have a rough idea what their teammates are doing today.

All done in 15 mins or less

Scenario 3

The team meet daily as they’ve agreed.

The team discuss their work and plan the day ahead. They allocate actions to help remove or unblock any impediments.

Everyone has a good understanding of what everyone in the team is working on and how that may impact their own work.

How long they spend for this session has already been determined by the team but will probably change again in the future.

Alternative Daily Scrum Format

When the team is struggling to complete work items in sprint, an alternative format from going around each person is to focus on the work items themselves.

Welcome everyone to the daily meeting and present the Sprint Burndown chart. This will show the team if they are on track, ahead or behind this sprint.

Then go through the work items that are in progress:

• Talk about the blocked work items first. Ask the people who know about that work item to talk about it. Ask them for a completion date. Compare that completion date to what had been said before and ask about any deviation.
• Next talk about work items that are closest to completion first (i.e. an example order might be work items in the following statuses: 1. Merge into Master Pending; 2. PO Sign-off; 3. QA Testing; 4. Code Review; 5. In-Progress). Ask about completion dates and compare to previous estimated completion dates if different.
• Encourage the team to say who will be taking on the next stage of that work item (e.g. who will be doing the testing, who will be doing the code review etc..)
• Encourage team members to help out with work items that are nearer to completion if possible.
• If someone hasn't spoken, give them the opportunity to say something
• Ask for any other comments, including what people will be picking up next if applicable.
• Once past the half-way point of the sprint, start to ask the team about their confidence in completing the sprint, highlighting work items that they believe will be at risk.
• Close the session.
• Timebox to 15 minutes

Its important to be aware of and therefore keep in mind that we miss out on several key aspects of the traditional meeting:

• We are not focusing on work competed, only getting work to completed - So if the team keep getting tripped up on changes they weren't expecting when they tried to merge we may need to talk about completed work a little more.
• It's a bit more work for the SM, as you need to keep in mind when people said they would get work completed in order to challenge them if that changes.
• Some team members may add little to the conversation as we are focused on the work, not the team members