Board games

Physical boards rule

Most of us, weathered SCRUM practitioners use SCRUM boards to represent Sprint Backlog. Some use an “analogue” board hung somewhere in the room, others content themselves with digital tools (e.g. JIRA). Personally, I’m a great supporter of the first type, as boards:

–  provide a natural “muster point” for the team, when the action plan must be discussed.
–  are irreplaceable during daily SCRUMs and provide ideal background for discussion (everyone knows what is being discussed, can point to a note with a specific task, and can review their notes to recall what they’ve recently worked on)
–  are close enough to let you take your eyes off the keyboard to learn how the work is progressing (instead of searching for yet another tab in the browser)
–  are far more flexible than any e-system.
–  And there is pleasure in the “manual” shifting of the notes. Yes, I am serious about it! 🙂

I’ll be honest: it’s hard for me to imagine a decent daily SCRUM without a board. Unless you have a gigantic touchscreen 🙂 If your team includes a handful of “remote” people, you can work on analogue and digital boards at the same time. The few minutes a day necessary to synchronise them seems a ridiculously low price for all the advantages of the physical boards that I have listed above. On the other hand, why don’t you try this tool: https://jimflow.jimdo.com).

Flexible board: colours won’t hurt you

Further in the post, I’d like to discuss the “flexibility” of physical boards. A SCRUM board doesn’t have to be a table with TODO, In Progress, and Done columns with no more than yellow post-it notes pinned on. You’ve got a plethora of marvellous tools that will make your Product Backlog more legible and pleasant to use. Remember that post-it notes come in various colours, shapes, and sizes. It’s an opportunity to exploit! Remember that you can also use the magnets with images, stickers, printouts, game tokens, badges, avatars, photographs, colourful sellotape, bookmarks, markers: virtually any stationary you can lay your hands on. An interesting example: my team needed something to flag the tasks whose processing encountered a problem/blocker. All they had at their disposal were the “regular” post-it notes as well as hearts, stars, and moons.
You’ll probably agree that none of them brings the word “problems” to mind. What did they do then? Well, they took the hearts, posted them upside down, and decided that from now on they are a symbol of “the arse” 🙂 Then they briefly wrote what problem made them arrive “up there”.
What you find below is a list of various options to modify the regular, drab, and unattractive SCRUM board to make it useful, legible and “brill”. I’ve drawn my ideas from concepts that we employ or used to employ in our team and from spying on the work of others.

Marking the User Story in colours: jot down all the tasks connected to a single User Story on notes in the same colour. Every User Story (US) in a single sprint should be marked off in a different colour. This will greatly help to assess how many tasks still have to be done within different USs, and what USs the team is currently elaborating.

The vertical position (height) of a US on the board defines its priority in a sprint: the US placed highest on the board is obviously the highest priority. Right mind being the limit, the team should start working “from the top” of the board, and continue “downwards”. This reduces the risk of failure to deliver the key USs.

Additional symbols on the task cards: use symbols to signal “specific” statuses connected to tasks. Apart from the aforementioned “arse” our team has also come up with printed magnetic badges for the following statuses: blocked task, task not following the plan, task doing really badly, and FUBAR.
You can order your own, tailored magnets for a few pennies at eBay, or Polish Allegro.

Avatars to represent team members: instead of writing who does the given task, you can print out avatars representing individual developers. Avatars can be made here [https://southpark.cc.com/avatar].

Signal the maximum number of tasks that a team can work on in parallel, or to make it less obfuscated: to define the Work in Progress (WiP) limits for the In Progress column. This can be done in various ways: enter the WiP limits in the column header, draw spaces for notes to be attached (and make sure a creative individual won’t post them outside these areas), or physically limit the amount of space available in the In Progress column.

The size of the note bearing a task corresponds to how complex a task is: something we haven’t yet tried in practice, but which seems to be an interesting option 🙂
I really encourage you to experiment with your Sprint Backlogs. Just remember that the overarching goal is to increase the legibility rather than to overload it with gadgetry and doodads.

Our spring backlog

Our team uses whiteboards for running spring backlogs. We post A5 sheets on the left hand side of the board to represent user stories, making sure we place higher priorities are at the top. Next to the USs, we place the tasks. All the tasks related to a single US are written on the notes of the same colour. The tasks are ordered from right to left, which means that the ones to do first are closest to the In Progress column.
Additionally, when a task is ready to be reviewed, we put a capital R on it, with the avatar/name of the person who volunteered to run the Review. There are only three columns in our Sprint Backlog: TODO, In Progress and Done. We don’t have Review and Test columns frequently found in other teams. Instead of Test being state, we have Test tasks.
The reason is simple: we test funcionalities and not individual tasks (like “add column to the database”).