How do you prepare for standup meetings?

"Standup" meetings, or whatever your org might call them: Regular check-ins where you describe what you're working on.

How do you keep tabs on things and come to this meeting (or Slack check-in, etc.) prepared?

Comments

[Ben Halpern]

These meetings are much more than literally "what code did I commit yesterday" — but this tool is a really pleasant utility to have around:

Git standup, how did I ever live without you?

Ben Halpern ・ Mar 21 '17 ・ 1 min read

#git #gitextensions

[Parker Waiters]

I wish I had more of a system

[Gnanasundar Gopalakrishnan]

Will be ready to answer three questions

1. What are you currently working.
2. Any impediments you are facing.
3. What is the next one you are going to take after completing current task.

[Andrew Baisden]

We just have to answer 3 simple questions. I usually know what I am going to say before hand or I could write down a few bullet points and then talk through them. It usually takes less than 60 seconds to give my status up date.

1. What did you work on or do yesterday?
2. What are you going to do today?
3. Are there any blockers?

[Jeremy Friesen]

I have a daily Todo list that I update. I copy and paste that list into our Slack stand-up.

Works well, often includes links to the PR or Issue or Slack thread.

[Suzanne Aitchison]

Same for me - I create a todo list for each day at the end of the day previous. It gives me the majority of my stand up update, answering the questions "what did you do yesterday? what will you do today?".

The only problem is that I always keep this todo list in a notebook (can't beat the satisfaction of scoring out 'done' items on paper!), and since our stand ups happen in slack threads I have to type it up 😄

[Maddy]

I'm trying to improve on this, I tend to be shy during standups, and I treat them as status updates.

In my company most of the time we do them via Zoom, or in case of any clash we post our updates on Slack.

In short, you should mention:

1. What you did yesterday.
2. Your plan for today.
3. Any blockers.

Regarding #1, you should include meetings and code reviews, not just the work on your ticket.

[Burt Macklin]

I've got a doc that I update most mornings to cover any interesting points on the ticket I've got on the board. I like it because it gives me a moment to really think about the things I'm working on and note down any issues I'm facing. Plus it's pretty useful as a historical document for stuff that I've been working on and

I try not to mention any meetings the rest of the team are in, or any they won't care about(1-1's etc) either