How to read an Agile Team-Board
When working in an agile setting together with a team, most of the day-to-day planning happens on a so-called Team-Board. In this article, I would like to give a little guidance on the process of which ticket/task to w̶o̶r̶k̶ ̶o̶n (look at) next, once your current task is finished. So, if you are a member or lead of a such a team, this article is for you. ☝️
What is a Team-Board
A Team-Board (aka. Scrum Board / Task Board) is a special arrangement of tasks to work on. In its simplest form, there are three columns: ToDo, In Progress, Done, and in each column, there is a list of tasks that need to be solved. After a task is completed, it is moved over to the next column — accordingly, a column basically represents the state in which the task is currently in.
It does not make a difference whether the board is physical (usually with a lot of sticky notes) or virtual (using tools like, e.g., Trello, Asana, …), what is important though, is that the board stays up to date and plays a crucial role in day-to-day synchronizations with the team.
Which task to take next?
In the past, I’ve worked with many teams in different settings (face-to-face, partly remote, fully remote), but also using various frameworks (Scrum, Kanban, Scrumban, …). Also, I’ve worked in different roles: Developer, Agile Coach and Product Manager.
In our daily business, we looked at least once per day on our board — mostly during standup—to talk about achievements, status updates and possible blockers.
Most of the times, our board looked like the one below, where each column is sorted according to its priority (most important ticket on the top).
Now, the question for you as a team member is, once you finished the “I want to register with my email and password” task, is:
Now! Which task do I take next?
The obvious choice is to look at the top item in the ToDo column, move it into In Progress and start right away. However, there are tow flaws with this approach.
The first is, that this will increase the number of items, the team actively works on in parallel. This might not feel important, as you feel productive while you solve the task at hand, however, in the long run, this might complicate the work of the whole team. An example could be that your colleague is currently stuck with a problem in another task and you might know the answer. Now that you started the new task, you need to switch between their problem and your task-which in turn reduces your effectivity.
The second flaw is, that even though this might improve your own throughput, this might actually hurt the overall throughput of the team. Given the example above, if you first help your colleague that is stuck in the task, you can finish the ticket together and the team solves another task much faster — which usually correlates to a happy customer.
Between the lines, you now already know a much better approach to “read” the board:
Always try to read if from right to left!
In this way, it is guaranteed that you first look if you can help out another team member. This could mean that:
- you deploy a ticket that is “to be deployed”
- you could assist you colleague in QA’ing a ticket
- you could pair on another ticket to finish it together
- you could be a sparring partner for the UX colleague
- and so on and so on…
Only at the very end of your journey through the board, you should start taking the next item on the top of the ToDo column, as you can be sure that the team delivers with full throttle on the features.
For a better understanding, I sketched this in the following picture where you would finish your ticket in the Done column, then helping out in the In progress column. Only if you really cannot help out in those tickets, then you have a look at the ToDo column. As each column is sorted by priority, you should have a look at the top item and see if a colleague is in need for assistance.
Remember, this is a very generalized view on a board. The teams that I worked with usually had 5–7 columns to structure their work and make it transparent for everyone in the team what the current state of a task is.
Should that not be done by WiP Limits?
Sure… You could also manufacture this behavior through carefully crafted Work-In-Progress (WiP) limits per column. My personal take here is that while it is beneficial to have a WiP limit per column, it should not be misused to guide a working behavior of a team member. You might end up in micro-discussions for each limit instead of delivering value for the consumer. However, if each team member is aligned on what to work on next, there is not much need for institutionalized limits.
Long story short
If you work in an agile team, next time you are finished with a task go through the board from right to left and see first if you can help out one of your colleagues first, before you pull another task in the stream.
Discussion
I am very interested to hear your thoughts and experiences regarding this or other approaches.
- Have you established a rule in your team?
- How do you celebrate if a task/sprint is over?
- Do you rather embrace solo-work or team-work?
If you are interested in connecting with me, please do so and please drop me a short line where you are coming from.
