The Ideal Agile Board

What does your ideal agile board look like? Simple: one that dispenses Krispy Kreme doughnuts and coffee for free. Unfortunately, the recent meeting of the London Agile Discussion Group considered more process-driven matters around how a good agile board should look.

The original plan was to discuss each other’s boards, but we decided that this was too problematic due to everyone’s implementation being tailored to their own circumstances: some don’t code review, some have separate testing and UAT instances, some use e-boards, et cetera.

So, after splitting up into groups with representatives from each discipline (developers, testers, analysts, project managers, and so on), each was given the same simple scenario with the aim of agreeing a structure for a physical agile board.

Building an agile board

Breaking from many traditional, minimal board suggestions (such as the task board in Mike Cohn’s Agile Estimating and Planning), all teams opted to have an ‘In test/QA’ column; some even had separate columns for pre- and post-testing statuses. Avatars were also popular across most teams, although many don’t use them currently. I love avatars, and have yet to find a team that didn’t benefit from using them.

Probably the most hotly contested discussion involved how to handle ‘blocked’ items: some gave such tasks their own column, others their own row, whilst two teams employed ‘blocked’ stickers to mark individual stories or tasks as having impediments. Even after we regrouped and discussed each team’s board further, I still don’t think we resolved this, with all solutions receiving criticisms:

  • Having a column for blocked items doesn’t help to explain where the blockage is occurring (i.e. is the blockage with the business, developers, testers or somewhere else?)
  • Having a row for blocked tasks causes confusion because the task is removed from the story’s swim lane (or row)
  • Having a row for blocked stories doesn’t help because it won’t explain where the blockage is (and moving the story and task cards is time-consuming)
  • Blocked labels or stickers don’t highlight the impediment sufficiently

Personally, I’m not convinced by the last argument and I think a great big red ‘BLOCKED’ sign covering a post-it is sufficient.

One of the team’s column choices

An interesting suggestion was to display the main action points from the last retrospective somewhere on your board. I think having a constant reminder of your recent commitments for continual improvement is a great idea, and is something that we implemented straight away.

After an hour and a half we had covered a lot, but without much consensus; the only point we all agreed on was that there is no single ‘ideal’ agile board. I can’t wait to hear what comes out of our next session: “Scrum Sucks! Kanban Rules!“. If it generates half as much discussion, I’ll be happy.

Comments are closed.