Most teams working with an Agile process like Scrum use a task board (physical or digital). Even many teams that only do a bit of Agile or Scrum will work with a task board. It’s a core practice in Agile software development, not specific to any methodology. So, it’s common practice.
So like all things in Agile it should be subject to scrutiny once in a while. A fair question is, why have a task board at all? Just because you’re doing Agile(tm)? No one benefits from blind adoption, so ask yourself this question. Not to get rid of your task board, but to find out if it really fits your purpose and to find room for improvement.
The previous board(s)
The kanban board:
One team had a kanban board, that had many lanes. It represented roughly our process. But since the team had 3 team members (2 developers and 1 tester), the team had some trouble keeping track of what story actually needed work. Also the meaning of the lanes became vague. For instance after the tests for a user story had been defined, it went into Implementing (make the tests pass), but what if more tests had to be defined along the way? Was this testing or implementing? Also some stories didn’t require formal acceptance, so the column was skipped. Some user stories popped up during development, so didn’t go through the explore & plan columns but also weren’t picked up immediately. So, in short, not very helpful.
The lanes were a result of months of tuning, so they did have meaning at some point in time, for some kind of work, but not the work the team was doing now. We did appreciate the visibility of the phase a user story was in and the wip limits.
The simple task board:
The other team had a task board which was almost the complete opposite of the kanban board. It didn’t even have a ‘done’ column! It was the bare bone task board with a twist, trying to keep the pull between the tester and developers by using two task boards, one for the developers and one for the testers. The main issue here is that it wasn’t clear what the exact tasks were that were being worked on. And as the cooperation between developers and testers tightened, having two boards didn’t always make sense. When we tried adding sticky notes (green ones) to track the smaller tasks within a user story, it became quite messy, it was hard to see which task belonged to which user story.
Having a board retrospective
Picking a theme for a retrospective is a good tip from the Agile Retrospectives book. For us the theme is sometimes the task board. When you hold a retrospective with your team, to discuss whether your task board really fits your needs, the format we used last time was:
- Define the goals for your task board (what would you miss when it’s gone?)
- Evaluate whether the current board meets those goals
- Brainstorm on new board formats that better meet the goals
- Decide how to change the board
So in our last task boar retrospective, the team defined the goals for the board. Based on the team’s experience and day to day needs, the main goals for any task board were defined as:
- See what’s left for a user story
- See what’s left for an MMF/Sprint
- See what we’re working on now
- Visualize loss of focus
The New Board
We brainstormed on new board designs. We introduced the ‘swim lane’ concept and tried to use it to fulfill our goals. At the end of the meeting we came up with this (the arrows shows a swim lane):
- Point 1 (what’s left for a us) is solved with one swim lane for each user story, showing the remaining tasks.
- Point 2 was solved by a vertical column of ‘todo user stories’ showing what’s left after the current stories.
- Point 3 (‘what are we doing now’) is visible in the ‘tasks in progress’ column, in this example 2 tasks are in progress.
- Point 4 is visible by looking at the ‘user stories in progress’ (us ip) and ‘tasks in progress’ column, that shows how many user stories and tasks are in progress. This is naturally bound by the limited space on the board.
So we’ve had many different boards in the past and many retros discussing the use of the board. We started with Scrum, switched to kanban and increased the number of lanes. Finally we ending up with a board that supports the goals we discovered along the way and now defined explicitly. It has two basic principles of kanban (pull & wip) strongly embedded while giving the team visibility of what’s ahead.
Perhaps you’ve had similar retrospectives or discussions? Do you have explicit goals for your board? I’m very much interested in your story regarding the development of your task board, so please share your experience!