Anatomy of a Task Board

One sign of a healthy Agile community within a work place is an abundance of varied physical task boards. By varied I mean that the boards are not identikit copies of each other in form and composition. For example, boards that do not have the exact same swim lanes, card types and information items on the cards. Just as all projects are different so their main information radiator, the humble task board, should reflect their different characters and requirements. Variation in task boards is an indication that teams are adapting to overcome their own particular issues and not just participating in an Agile cargo cult.

The task boards in my current workplace certainly demonstrate this kind of healthy variety. This is advantageous, not only because it shows each team exploring their own different path to improvement, but because seeing what other teams are doing can spark change in your own team.

In that same spirit of sharing, in this post I present an anatomical tour of my current team’s task board in the hope that it may spark ideas for other Agile teams. Note that in no way am I recommending our current task board set up as a perfect example. It is just the set up that works well for us at this moment in time.

Scrumban

Before going into the details of the task board I will explain our current development methodology as it has had a huge impact on our task board’s construction.

Until relatively recently the team utilised straight Scrum. The team was relatively mature and decided to move away from Scrum’s fixed iteration structure towards a more continuous flow approach. Kanban was an option we wanted to try. However, jumping straight to Kanban struck us as being a little risky. We instead decided to have a go at a hybrid approach known as Scrumban.

The Scrumban process is outlined in an article written by Corey Ladas. In summary the idea behind Scrumban is to start with Scrum and move towards Kanban step by step. Specifically the following practices and artefacts are introduced gradually over time:

• Break up existing work flow into clearly defined steps
• WIP limits on work swim lanes
• Introduce queue swim lanes
• Maintain a cumulative flow diagram to measure performance
• Limit the size of the backlog
• Use an order point to indicate when the backlog should be replenished

The idea is that if all of these transformational steps are followed then you will be able to shrug off much of the Scrum framework and emerge with a continuous flow process far closer to Kanban.

For example, with the introduction of the last change one of the main Scrum ideas, fixed iterations, can be eliminated. Planning happens when it needs to and not at the start of each iteration. The other Scrum ceremonies such as demos and retrospectives can also be demand driven or have a cadence potentially unrelated to the original iteration length.

As you can imagine the task board was central to making our way through the transition stages of Scrumban described above.

Our Task Board

The team is lucky to have exclusive use of three sizeable white boards laid side by side. This gives us a huge space to lay out our task board. In common with all of my boards I use electrical type to create lines as, opposed to drawn on lines, as the tape cannot be accidentally rubbed off.

Here is a picture of all of the boards that comprise the task board. I will describe the contents of each board from left to right.

Click to Enlarge

The first board contains two areas “Ready for Estimation” and “Waste Snake/Investment Ladder”:

Click to Enlarge

The bottom area is not strictly related to the task board and is used for waste and investment tracking. I have outlined the purpose of tracking waste and investment in a separate post for those who are interested.

The top area is more relevant to this article and contains cards representing stories that are deemed to be “Ready for Estimation”. This is a prioritised backlog of work for which the requirements have been defined to the appropriate level. The top priority stories from this area are estimated periodically before being placed onto the task board proper which starts on the middle board.

The middle board contains the bulk of the task board’s swim lanes:

Click to Enlarge

There are a number of features worth noting here.

Firstly are the numbers 8 and 2 in the “Ready” swim lane. The “Ready” swim lane contains stories that have been estimated by the team and accepted into the work flow but for which work has not yet started. The 8 represents the maximum number of stories that can appear in this swim lane. The 2 is the lower limit at which we schedule a planning and estimation session to accept more items from the “Ready to Estimate” area into the “Ready” swim lane. We are able to maintain a low Order Point value as our team in co-located and therefore our required lead time for planning and estimation sessions is low.

Secondly the numbers 6 and 3 for the “In Progress” and “In Verification” swim lanes represent WIP Limits for these work in progress steps. These numbers have been tuned over time to achieve optimal flow. “In Progress” represents the process of a story being implemented to a state that satisfies our Definition of Done. “In Verification” represents the process of checking that completed stories are truly up to scratch as regards our testing and UI standards. The “Done” swim lane acts as a queue between these two work in progress states. Stories can move to the “Verification Failed” or “Verification Passed” swim lanes (found on the next board) as appropriate. The team have a rule that states that a team member must remediate any of their stories that fail verification before starting a new story.

Thirdly note that stories in the “In Progress” and “In Verification” states have avatars attached to them with paper clips. The avatars represent the team member currently working on the story. Each team member has chosen a South Park character to represent them. Task board avatars are a great communication method as, at a glance, anybody in the team can see who is doing what.

The third board contains the remaining swim lanes that make up our flow:

Click to Enlarge

The “Verification Passed” swim lane forms a queue for items awaiting demo. As this queue fills up we schedule demos with the Product Owner. Stories which are accepted by The Product Owner move into the “Demoed” swim lane.

The “Demoed” swim lane represents my biggest disappointment with our current process. As you can see it is double the width of the other swim lanes. This is to accommodate the large number of stories that are potentially ready for release but have not yet been released. Unfortunately in our organisation the high coordination costs of UAT and Production release means that releases are not as frequent as we would like. The positive thing about the swim lane is that this issue is made very visible on the task board which may itself help to spark change in this area.

Accessibility and Visibility

Besides the rich information conveyed by the task board two other things make it highly effective: its accessibility and its visibility.

The task board’s accessibility refers to there being unobstructed space around it. This means that the team can have their stand ups around it. Having the task board present at stand ups eases communication during the ceremony as the project’s current state is right there for all to see. The task board’s accessibility also means that team members can take responsibility for keeping the board up to date at all times during the day. This takes discipline but is achievable if team members can see the benefit.

The task board’s visibility refers to it being in a prominent position viewable to all team members while they work. Coupled with the fact that the board is always up to date this visibility means that the board makes for a powerful communication medium at all times of the working day. I especially like it that the positive act of a team member moving a card through the flow is seen by everyone and has a motivating effect on the team.

Story Cards

Just as important as the information the task board conveys is the information that individual story cards make available. Here is a typical story card from our task board:

Click to Enlarge

I prefer to use large 6″x4″ cards for task boards as more information can be fitted onto them than stickies. Larger writing can also be used aiding the overall readability of the task board. In concert with a magnets (and a magnetic whiteboard) it is easy to move the cards through the task board’s swim lanes and they never fall off the board. We display the following information on our story cards:

• The release name
• The issue tacking number
• The story name
• The story point estimate
• The avatar of the team member working the story is attached

The size of the cards means that we can introduce new items of information in future as required.

(Note that we continue to estimate in story points. This illustrates that we are still very much in the Scrumban transition stage rather than having become a Kanban project. This is one of the things I like about Scrumban: you don’t have to go the whole way all at once.)

Our stories are cross-cutting and so most of them inolve the creation of a UI screen. To guide the team member in the creation of the UI we create simple wire frames of the UI layout which are stapled to our stories for easy reference:

Click to Enlarge

Using the same technique any type of relevant attachment can be added to cards further improving their utility.

All other specific detail about the story including test examples are included in the electronic issue tracking system. The appropriate tracking number is referenced on the front of the card.

Avatars

While the primary use for avatars is to enhance communication they can also add a bit of fun for the team. The first thing to do is pick a theme for the avatars. Cartoon or comic books characters work well because they are usually easily recognisable. Next let team members choose their own avatar in line with the theme. This will engage them more than if you just pick an avatar for them and will encourage use of the avatars on the task board.

For example, for my team I decided on South Park characters for the theme and had team members chose the characters to represent them:

Click to Enlarge

I coach another team and in this case Mr Men characters were used for avatars:

Click to Enlarge

You can see from the pictures above that the avatars have been laminated. I recommend that you do this as otherwise, if the avatars see normal use, they quickly become tatty and unreadable.

Task Board Sharing

I hope that this post will help spark inspiration in other teams to change their task boards to enhance their communication. On the flip side I am always interested in what others have done with their task boards so I can learn new tricks. Please share your ideas and task board pictures so that others can benefit.

Advertisement

Explore posts in the same categories: Agile, Scrum

Tags: Agile, information radiator, Scrum, scrumban, task board

You can comment below, or link to this permanent URL from your own site.