What's the ideal length of a standup?

[zoltanersek _outpostlabs_dev_]

I was part of many teams over the length of my career, and I keep finding 2 extremes when it comes to standups: they either last under 10 minutes or they go on for almost an hours. It's no surprise to anyone, that I prefer the first. 

Now, what do you think an ideal standup should take? 
What is your advice for optimizing long standups? Especially, what I can do as a relatively new member of the team. 

We don't have a scrum master or someone 100% focused on agile practices. 

[Amanda Barber]

We keep ours pretty focused and then have a post-standup for further conversation. I think it helps that I have a hard cutoff at the end of our meeting so it has to end, haha! At a prior company, we actually pivoted to required daily standups in Slack kept to the 3 basic standup questions and then our daily calls were brief times to connect on a more personal level. 

When using Jira, there's a timer option in the standup view if you want to try to keep people on time!

[zoltanersek _outpostlabs_dev_]

thanks, I wish we could be that disciplined, I'll try pushing for the hard cutoff as a start, I'll let you know how it goes 

[Stephen_Lugton]

HI @zoltanersek _outpostlabs_dev_ 

At some point you'll probably be told that:

A daily stand-up should be strictly timeboxed to 15 minutes maximum, regardless of team size.

If you take the view that Agile 

prioritizes adaptability, continuous feedback, and collaboration over rigid, long-term planning.

then sticking to a rigid 15 minutes maximum doesn't seem to be agile!

But saying that, a small team should be able to finish their stand up within 15 minutes.

I typically allow 1.5 to 2 minutes per person, so for my current team which has grown recently to 12 as we've recently amalgamated 2 teams to make cross training easier, I would expect the stand-up to be up to 20 minutes, but usually less.  And to be fair the first few minutes of that are more casual personal connections to kick off the day.

Any more than that and you're doing a status update rather than a stand-up, especially if it's an hour long.

And I'm also not rigid when it comes to stand-up content, and allow brief expansions on

• What did I do yesterday?
• What will I do today?
• Do I have any blockers (impediments)?

For example, if one team member gives an update where they have a blocker I will allow the rest of the team the chance to offer advice on how to resolve that blocker (but get the relevant people to pick up on it outside of the stand-up as needed)

[zoltanersek _outpostlabs_dev_]

Thanks @Stephen_Lugton our team is 10 people right now, and I believe that is on the higher side, and it's definitely one of the main reasons it takes that much. 

I agree with you, it's good to be flexible and adapt to the daily content, not just keeping to the 3 questions strictly.  

[Sarah Rank]

Yes! I think it's important to remind the team it's not a status report. Blockers should for sure be identified, if any. And an engaging dialogue - "here's where I need help" {others chime in on how they can help the team get to the finish line}

[Sarah Rank]

Ideally, 15 minutes of time well-spent. Valuable, productive conversation.

[zoltanersek _outpostlabs_dev_]

@Sarah Rank thank you, I agree with you, maximum 15 minutes. 

It would be awesome if that were the case

[Stephen_Lugton]

You've raised a good point there @Sarah Rank , the stand up needs to have value. 

I once took over a team that another delivery manager had been scrum mastering for and he just wanted a quick snappy response from everyone such as

"I worked on ticket Jira-1111 yesterday, I'll work on it again today."  

That was all he wanted.  I could have got that from the Jira board! 

To get value out of a stand up you need more than that, e.g.

"For ticket Jira-1111, I got the connector between the data and the dashboard working, it now shows monthly data but needs tidying up, I'll work on that today and demo to the PO later, there's nothing that I'm aware of that's going to block me."

As soon as the other delivery manager left I changed the format of stand ups to ask for that extra detail.

[Anwesha Pan]

As mentioned by @Stephen_Lugton and @Amanda Barber , we also we adopt a structured approach by focusing on three essential stand-up questions:

1. "What did I accomplish?"
2. "What are my plans for today?"
3. "Are there any blockers/obstacles?"

If there is more to discuss, we have something called "Parking Lot" so our team mates get to discuss topics beyond their usual Jira ticket updates. This way we do not spend more than 30 mins in SU.

[zoltanersek _outpostlabs_dev_]

We used to do Parking Lots in my previous teams, and we had folks from the team calling out if something went on for a long time to allocate it in the parking lot. I enjoy the format. 

[Luis Ortiz - Catapult Labs]

A 60-minute standup is not a stand-up anymore, that's a status report already. It is incredibly frustrating, especially when there is no dedicated Scrum Master to rein in the scope.

When a team hits 10 people, the math of synchronous standups completely breaks. If everyone takes just 5 minutes to explain their tickets, the meeting is basically over. The absolute best way to fix this is to transition the team to asynchronous Slack standups.

You can pitch it as an experiment, and need to define a strict slack format, though: a clean format, a dedicated slack channel, and a specific time of the day. 

Yesterday: (One sentence summary)

Today: (Direct links to the Jira tickets being worked on)

Blockers: (Explicitly tag the specific person needed to unblock it)

Making it asynchronous, it's particularly useful if you have teammates across time-zones. 

And, repurpose the Live Call for "Triage Only". Keep the calendar invite but change the rule: We only join the Zoom call if someone flagged a blocker in their Slack update. If there are no blockers posted by 9:30 AM, the meeting is auto-canceled and everyone gets an hour back.

And Introduce Automation:
(Full disclosure, I am the co-founder of Catapult Labs, and we actually build native Slack + Jira bots precisely for this workflow.) Once the team gets a taste of async standups, the next complaint will be having to manually type out their Jira ticket numbers. That is when you introduce a bot that automatically surfaces Jira ticket movements into the Slack channel, removing the administrative typing entirely, and formatting updates in a report. 

By moving the status reporting to Slack, you protect the team's engineering time, and any live conversations become purely about problem-solving.

[zoltanersek _outpostlabs_dev_]

Thanks Luis, I used to do async at one of my previous companies and I enjoyed it, so much more efficient that way. 

But the sync standup is engrained in the company's culture, not much I can do about that. 

[Brita Moorus]

Another approach is to avoid giving equal time to every work item. If something is progressing normally, a quick "on track" is enough. The standup time should mainly go to blockers, dependencies, risks, or anything that needs input from the team.

That way even with 10 people the meeting can stay useful without turning into a full status report 😊

[zoltanersek _outpostlabs_dev_]

Thank you @Brita Moorus I agree, I would keep standup only for blockers or unclear items as well, quick on track statuses would make this meetings go a lot faster