Skip to main content

The daily standup – How do you do it?

MSP cloud technology
(Image credit: Image source: Shutterstock/everything possible)

We’ve been rotating who runs our daily for over a year now. In general, there are four people who we cycle through. Each running the standup for a week at a time. That gives enough time to give the person running it context as the week progresses. Running a standup on a Monday (especially after a weekend) is far harder than when you come to do it the fifth time on a Friday.

Other people than the rostered four can get a look in as well. Sometimes we’ve had a DevOps/Senior Dev combo running the show, it doesn’t have to be one person.

In the past, we have determined who’s going to run the standup by roll of a die, but that can be a bit mean. 

Different types of standup 

The main advantage of having multiple people is that everyone conducts the meeting in a slightly different way. We all pickup hints from each other, which in turn makes the standup better.

Sometimes a person will use the same format for the entire week, or choose a different format for each day. It’s up to the person running the standup.

Which approach I take will sometimes be emotional. Whether myself or the team can handle a more involved “Walking the Board Session” or Business Led; Support may be on fire, so a shorter session would be in order. These are the main types that we currently use:

Round Robin

Usually, everyone would stand in a circle, and you’d speak after the person before you.

This isn’t as easy to do virtually, so the person conducting the meeting calls out people’s names in an order. There are many ways to come up with this order:

  •  Random
  •  Discipline – Support, Feature, SRE 
  •  Profession – Developer, QA, BA 
  •  Work Priority – Urgent, High etc 

This approach can feel quite directive and does have parallels with a status update meeting. While very easy to follow (great for a Monday morning) I wouldn’t use it all the time as it can feel quite disempowering. Especially if it’s the same person running it every day forever and ever.

I’ll mention “standup notes” at this point as well. Never, ever send out minutes of the daily standup, listing what everyone did yesterday etc. It turns the meeting into a reporting session, and that’s not really the point. The purpose of the meeting is to synchronize activities in a collective forum.

Nominate (pass the baton)

This gives the team a bit more control, in that they can choose who speaks next. With larger teams, people can forget who hasn’t had a turn yet. This can inject some fun into the meeting and break down some barriers, so I don’t view it as a negative thing. 

Walking the board 

The most thorough and intense of standups. Proceed with caution!

Starting right (the highest priority in Kanban) and proceeding left, you go through every ticket on that board. Of particular interest is the blockers, and the purpose is to get the entire team aligned to the exact state of play with every piece of work in traction.

It can feel like quite a pressurized meeting as people struggle to remember exactly where they are with all the various things in flight. No one can hide when walking the board.

The value of this meeting is very high, with regard to the delivery of work and exposing issues.

If you want to start the week with a bang then Walk the Board, if you want to get everything in a good shape for the next week then Walk the Board.

However, it can be very onerous and should only be conducted a couple of times a week. If you’re doing it more often, then you either have control issues, trust issues, or some fundamental process issues. So there!

No board 

In general, whoever is conducting the standup shares their screen. They either update tickets on the fly if appropriate, or just use it to help everyone visualize what people are talking about.

Sometimes it’s nice just to focus on the people. We don’t always share our screen, there’s a lot of value in listening to what people have to say. It’s generally a more relaxed approach and works well, especially after a milestone has been hit/issue been resolved etc. I tend to use this more at the end of the week, when energy is lower and a more personable approach is needed.


Sometimes it becomes apparent that things need a bit more focus. The team's support burden can spike, there could be an incident. There could be a large tranche of work that needs to be taken “over the line”. Use with caution, if you’re having to ad hoc swarm more than once a quarter, then something is going wrong somewhere else.

It’s great for getting everyone focused on one item, but it’s very disruptive for team members who had probably planned for their day to go very differently.

Eat your frog

Moving onto some of the more experimental styles, this is one I’ve only run once.

Basically, everyone needs to name the one task that they want to get done for that day. They don’t need to complete that task, but make extreme headway in getting it done. They need to break the back of this task, eat their frog. That’s it.

Some people say that it doesn’t matter if you state what happened yesterday. That’s in the past and cannot be changed. Unless it has a tangible effect on today, then it’s not worth mentioning.

Coming from a “productivity” background, I feel that this is less appropriate for people that have a prescribed amount of work to do. It’s easy to say “working on my current task, which is…”. However, for management – the POs and the Team Leads – where work can more reactive, and you can choose what the priorities are, it can really help with focus.

The next day, people had the opportunity to say how well they ate their Frog. Or they could choose not to. Remember, the standup is not a status update.

I need help! 

This was my latest experiment. I’ve mentioned how the standup isn’t a reporting session, and it’s really meant to enable the team to do their best work.

As a scrum master, the main thing which I care about is – what problems are you having trouble with? What are your blockers? How can you path be smoothed to allow you to focus on what you need to do?

From this idea, the “I need help!” standup was born. You only have to say one of two things (of course you’re always allowed to say a bit more if you wish).

·    If you need help and what you need help with


·    If you can offer help.

When we ran this one, we had a few people that needed help, with offers to help as well. Team collaboration went through the roof! A longstanding bug was resolved, and it felt like the team were really working together as a cohesive unit.

Certainly not one to run every day (there is a lot of value in Walking the Board), but if everyone’s getting a bit bogged down, then it could be exactly the thing the team needs to get unstuck.


I thought I’d put this one at the end. Our allotted time for standups is up to 30 mins. More than double the traditional 15 minutes. The team is only slightly larger than average, but we do like to talk. It’s not all work, sometimes we can chat, there could be announcements. We even refine some tickets if we have time at the end.

A longer standup can mean fewer meetings during the day, allowing for more focus time. We try not to go off-piste too much, as we don’t want to waste everyone’s time. Meetings are still scheduled for outside the standup if appropriate to discuss things in more depth. Sometimes our standups take only 10 minutes. That is also fine!

What works for our team currently is a mixture of standup approaches and people running the standups. If this stopped working, then we’d look at changing it.

This probably isn’t an exhaustive list of the different types of standup. But what is key here is that I would encourage everyone to experiment with their standups.

If everyone is stuck Walking the Board or only one person runs the meeting, then you’re missing out on all the glorious variety and practices that could bring far more value and enjoyment to a very mundane and repetitive meeting.

I’d rather be the person that has got a bit messy by trying to eat a cream egg off my own face. The alternative would be to unwrap it the same every day with my banal hands while I cry into my cup of lukewarm water.

Chris Sheldon, project manager, DataArt  (opens in new tab)

Chris Sheldon is a project manager working for DataArt UK Ltd. He started out as a Software Developer but now spends his days evangelizing about Development best practices. He’s worked with startups and multinational companies, and hasn’t decided which type of company he prefers.