Whiteboard for task management

Having a physical whiteboard for managing tasks is an interesting phenomenon amongst agile teams. Amazingly low-tech solution can bring unexpected results into the highly technical oriented environment.

How does it work

You keep a whiteboard somewhere close to the team, rows represent stories or deliverables and there are three columns in each row – to do, in progress and done. After that, you use post-it notes to represent small tasks and put them into appropriate columns.

An example of such task could be Test in QA, Fix issue X or Refactor Y. Task are supposed to be small and clear to everyone.

Whenever you start working on a task you move a post-it note from to do column to in progress and when done you move it into done section. When there are no tasks left you put a special note on the story that it’s finished.

Task could be marked with laminated avatars that represent each team member (I highly suggest a set of your favorite 80’s action movie heroes – Arnie approved) so you can see what everyone else is working on at the moment and who is involved in the delivery particular story.

Additionally you can have a list of testing environments and track which features are deployed in each one of them.

What’s good

The major benefit of having a physical board is the team engagement. Physically moving the task from one bucket to another increases your satisfaction and motivation. It enhances the spirit of getting things done and achieve the sprint goals.

Secondly, it provides the visibility over a complex piece of work of your teammates and reveals blockers. Everyone knows what is everyone else doing, can offer help and start pairing. Also, it is great for the product owner to have a high-level overview of the current sprint progress.

Lastly, the whiteboard serves as a water cooler fountain where interactions between the team members happen. Better communication, better results.

What’s bad

There is no history recorded along the track and if the post-it note falls down it might be hard to put it on the right position. The board must be treated in such way as it is not a proper log of the software process.

You can’t have a board in fully distributed teams and you’d have to switch to an electronic alternative. As the benefits are mostly social and team bonding I don’t think it’s worth the effort. When the team is partially distributed, remote members might be left out of the process and it depends on your judgment whether to have the board or not. You can always take a photo, but that’s kind of stupid.

As the board doesn’t serve as a proper work log, you probably have another system for tracking the project (e.g. JIRA). So when you are working on a feature, you have two places to update the progress. It’s a different amount of information, but it brings more overhead to keep everything up to date.

Integration into daily process

Instead of the usual “what have I done yesterday, what I’m gonna do and whether there are any blockers” have one person go through each line on the board and ask the team who is working on those tasks and how can we move them forward. People that have nothing to do will grab a next available free task and any blockers will be revealed sooner.

Conclusion

Whether the whiteboard is right for you and your team highly depends on various things – complexity of the project, size of the team and structure of the team, location, personalities and your current change process – but I’d recommend you to give it a try, it’s not a big investment and it can increase the happiness in your team.


Would you like to get the most interesting content about programming every Monday?
Sign up to Programming Digest and stay up to date!