Disclaimer: There are many ways to run a standup. I’m not claiming this is the only or best way. I merely want to share why I do what I do.
Let’s start with a short overview: I start by sharing the board on screen with everyone in the room, and filtering it to show only the tickets that changed since yesterday. Then we go ticket by ticket and shortly discuss what we achieved yesterday. Then we remove the filter to show all the tickets, and ticket by ticket, review what is currently in progress. When done, I ask “Does anybody have anything outside the board to share?”.
Now let’s break this down:
Show the board
Why? The board shows what the team agreed to work on. Running the standup without sharing the board, you risk loosing everyone’s attention (especially when remote).
Furthermore, when you methodically review the tickets on the board it makes it hard to forget discussing tickets.
By task, not by person
Instead of going person by person and asking something (what have you done yesterday? What are you working on? Are you blocked?), go over the tasks. Pick a task by the order on the board and let it’s owner speak. Ask leading questions if needed (is something blocking us?).
Why? I believe focusing on the tasks instead of the person has these “side effects”:
People feel less “under the spotlight”. It shifts the focus from the person to the task. It’s the difference between “Itamar, what are you working on today?” and “How are we doing with task X?”.
It cultivates a cooperation feeling. It’s not you (running the standup) against another team member. Rather it’s you as a team against a task on the board. I believe this feeling of working together towards a common goal is very important for the health of a team.
First celebrate what’s done
It’s easy to forget mentioning what you achieved and only focus on what’s left to do, letting tasks be completed in silence and never celebrating them.
Instead, start the standup by reviewing the tasks that were done yesterday. Sometime there is not a lot to say about them (I deployed it and tested it in production) and sometimes there is an interesting takeaway to share or some detail the team should be aware of.
Nevertheless, I believe merely mentioning a completed task contributes to the team’s feeing of achievement. Seeing something under the “done yesterday” filter every day is a great feeling that the team is moving forward.
On the flip side, seeing an empty list under the “done yesterday” always feels bad, so be careful not to use that to scold anyone. It should be a warning light. But you fix it not by saying “let’s try to have something here tomorrow”, but by focusing on the tasks in progress (see below).
Review what’s in progress
Now it’s time to review what the team is currently working on. Again, task by task (not person by person) discuss the tasks in progress.
We try to break down tasks to sub tasks that take at most a day. We never get it perfect, and sometimes one day tasks end up taking more because of bad estimation, dependency on another team, meetings — reality. But it’s something we strive for.
Why? First of all breaking down to sub tasks enables the team to work in parallel because it clarifies the interfaces — where one sub task ends and another starts. This has another important effect — it allows whoever is picking the sub task to be laser focused on one thing. Lastly, the smaller tasks you have the more you experience that small dopamine rush of moving a task to done.
So when a sub task takes more than a day we need to understand why. If it’s because it turns out to be more complicated than we thought it’s time to either pair or split the task even further.
Anything outside the board?
After reviewing the done and in-progress tasks, before ending the meeting, ask if there is anything outside the board we should discuss. It could be personal errands, it could be an interesting learning from yesterday, it could be a “surprise” task that never made it into the board (like supporting a customer), it could be a request for help.
It’s important to give a space for these topics to come up.
In Progress until it’s Done
How should you structure the board anyway? Sounds trivial, right? Well every task starts it’s journey in the sprint in some sort of a To Do or Upcoming column, and gets its wings in the Done column. But what’s between those? And when do you move a task to Done? It’s important to have a common understanding of these in the team.
I like the super simple model: after being picked up, a task is either in progress or done. Notice that there is no “in review” or “testing” or “waiting for deployment” state. The task should stay “in progress” as long as it’s not tested in production. It should sit there looking at you during the standup even if you are “done” and it’s “just” waiting for review from your peers. It should annoy you even if it’s “just” waiting to be deployed, or to be tested in production. After moving a task to done and celebrating it you should forget about it.
I admit I had a hard time with this rule when it was first introduced to me. I wanted to reflect the “real” status of the task to the team. It took me a while to realize that if I finished coding it’s not time to throw it over to the next column and pick a new one— it’s my job to collect and apply the feedback (yeah, ping my teammates if needed). And that if I got it merged and it’s being deployed it’s not done yet- it’s my responsibility to test it in production. Only then I can say it’s truly done.
Summary
The board and the standup are tools, and the way we use them can make a great difference. I found these rules help the team to
- Increase the feeling of achievement
- Improve the sense of responsibility
- Improve the focus
Let me know what has been working for you in the comments below!
