Advice on how best to maximise stand ups?

Kate Hiscox

March 27th, 2014

I've been doing a lot of reading on this of late and would appreciate input from the FD community. The bulk of the team are remote and we'll shortly commence with a second hackathon. Any tips and advice on what has worked well for others when it comes to stand ups would be great.

Rohit Talwalkar Uber Stack Software Engineer

March 27th, 2014

Also, for remote teams - I found it exceptionally helpful to use a video-call.  It will allow for non-verbal communication + you can tell if people are really standing up (I'm assuming you *do* stand for the meeting...)

Luis Avila Owner/Fullstack Architect at IdeaNerd LLC

March 27th, 2014

The basic structure of a stand-up meeting is for each individual to answer these questions (with examples):

1) What did you do yesterday. (Yesterday I created the tests for the new shopping cart)
2) What do you plan to do today. (Today I plan to create the shopping cart html and code)
3) Do you have any impediments. (I will need our card processing service API for integration tests.)

And ditto Bill S. Any talk beyond answering the 3 questions above should be done outside of the stand up and should only include the relevant individuals.

Lastly, the meeting organizer (aka scrum master if you are following the scrum methodology) should be the gatekeeper and should guide the meeting so it does not devolve from the above structure.

George Diab Co-founder & CTO at WorkingOn

March 29th, 2014

There will be people who want to ramble on, or take over the standup to flesh out a requirement, or prolong the standup in some way that is "out of scope" for what should take place in a standup. Someone needs to make sure everyone stays within the "rules" (whatever they might be) of the standup and keeps it all on track.

You should shoot for no more than 2 minutes per person, and if there is a need to, take anything offline that might stretch any longer than that.

Consistency is important.

Bill Snapper Owner Principal at SammyCO, LLC

March 28th, 2014

Actually "standing" isn't required. I've got a situation with one that appears on google hangout from his bed. He doesn't understand why this bothers the rest of us.  Plain and simple, it shows disrespect.  This is in core business hours and during the same time zone.

As long as the people are participating professionally that's all I ask for.  I do agree that using video calls do help. It gives people ore of a sense of community and collaboration when they see each other.

Bill Snapper Owner Principal at SammyCO, LLC

March 27th, 2014

Focus.  If someone has nothing to report on don't let them ramble on about "I did xxx and yyy".  Focus it on what they did that might be significant or if there might be a significant problem that came up they might need some help with.

Keep them as short as possible.  If you've schedule an hour and you can get it done in 15 minutes, perfect.  Standup over.

Taylor Dondich Vice President of Engineering at MaxCDN

March 28th, 2014

I lead technical teams that have members in remote locations.  When performing your standup, it's important to sandbox it to 2 minutes per member.  Use an egg-timer to get used to it.  Ensure that nobody exceeds this and is prepared to give only this information:

1) What have they worked on since last standup
2) What will they work on now
3) What additional information do they need, or if they are blocked on something

The pure goal of an effective standup is not to micro-manage. You should have tools in place to actively monitor team member's movements (I use JIRA for this quite a bit).  The real goal is to ensure progress doesn't stall silently. You want to avoid members being blocked and not speaking up.  You want to ensure that people are not veering off in a different direction of what they should be working on.

In our teams, we have someone who is dedicated to ensuring each member is quick with their progress report. Maybe it will be you. This role requires the tactful skill of cutting people off and redirecting discussion when it veers off course.  It's a learned skill.

I hope that helps!  Remember I mentioned tools.  With the right compliment of tools to support an effective workflow, your standups should be a breeze!

Ian McLean Developing Startup Grunt, Tech Co-Founder

March 31st, 2014

Many great points here. I was a developer in agile teams for nearly 8 years before managing one. I usually ask the following in addition to the standard questions:


Knowing what we know now:


1.    Are any small estimates now large?

2.    Are any large estimates now small?

3.    Are the acceptance criteria of the user stories still accurate? Obtainable?


If these aren’t voiced daily you’ll often hear them in the 11th hour of and iteration as excuses as to why features aren’t getting done rather than warnings that they are in jeopardy while there is still time to do something about it. #1 and #2 are often omitted because of estimation guilt. #3 Is a common occurrence where product had too limited a view of a system to write an accurate or obtainable feature and developers were only able to identify this upon deeper inspection once the iteration began.

Kate Hiscox

March 28th, 2014

Excellent - thank you Taylor! Sent from my iPhone

Kate Hiscox

March 27th, 2014

Thanks for your responses.


March 30th, 2014

The way I see standup is a platform for the product development to communicate problems and blocker of what they currently work on.  Id suggest all developers speak briefly about what they are working on and raise red flags if there is any blockers. Product, ux and design shares what they think is important for the whole team to know. And it should not take more than 5 mins.  And all issues raised in the standup should be followed up right after.  Basically, if you see it as a communication platform to improve efficiency of the whole team and you can easily make decisions on what you should and should not talk about in standups. - Sent from Mailbox for iPhone