What are the individual elements that make a Scrum task board effective for the team and the leadership of the team? There are a few basic elements that are quite obvious when you have seen a few good Scrum boards... but there are some other elements that appear to elude even the most servant of leaders of Scrum teams.

In general I'm referring to a physical Scrum board. Although software applications will replicated may of the elements of a good Scrum board there will be affordances that are not easily replicated. And software applications offer features not easily implemented in the physical domain also.

Scrum Info Radiator Checklist (PDF)

Basic Elements

Board Framework - columns and rows laid out in bold colors (blue tape works well)

Attributes: space for the total number of stickies that will need to belong in each cell of the matrix; lines that are not easy eroded, but are also easy to replace; see Orientation.

Columns (or Rows) - labeled

Stories

To Do

Work In Process - (many teams limit WIP - label this or make the column very small)

Done

Rows (or Columns)

a column title label row (at the top)

one row for each story in the sprint backlog

one row for each unique action item from the retrospective

(optional) rows for company initiatives that team members will be working upon

Stories - the classic user story is typically written on an index card or large sticky note.

Attributes: title, description, acceptance criteria, effort size, delivery order (backlog priority), business value, dependencies, negotiated in/out of scope agreements, etc. See Also: One sentence does not make a User Story.

Tasks - a sticky note or index card for each task the team identifies or discovers in the sprint.

Attributes: each task should be specific (not something like "test it"), each task should be less that a day's worth of effort (when this is not true - the first action of the task should be to break the task up into a plan of action); each task should be estimated in relative units (different & more fine grained than story points) - for example "aspirin"- this is proportional to the amount of wall clock time between it's current state and done (not equal, but proportional to real time). See Also: What belongs on the TASK board?

Sprint Burndown Chart - task units remaining plotted per day; with sketches of the trend lines; annotated with events that impacted the sprint (ex: reduced scope on day 4; pulled in small story on day 8; holiday on Monday, flu hit the team, etc.). See Also: A burndown chart that radiates information.

Impediments List - the one guarantee that Scrum will deliver - and if you are not capturing these on a daily biases and the triaging these, recording the resolutions, reflecting periodically on the classification of root causes -- well then you are not doing Scrum. See Also: 7 aspects of a great Impediment Sticky.

Advanced Elements

Trend of Sprint success - Predictability graph - graph each sprints planned story points and the accepted (by PO) story points; the simplest form of this is a binary trend of success (sprint delivered on time, in budget, with planned scope) or not. See Also: Metrics for a Scrum Team.

Working Agreements - team working agreements are always a great way to quickly negotiate the forming, storming, norming phases of team development; these are living documents and should be posted in the team room, so that they can be mutated as understanding grows.

Definition of Ready & Done - a team with a shared understanding of their meaning of done will be much more likely to deliver potentially shippable working and tested software each sprint; a understanding of stories ready for sprint planning will lead to a robust definition of done; one is a precursor catalyst agent for the other. See Also: Exercise: Definition of Done.

Calendar - a very old planning tool; heck even the Maya used one. A great place to note holidays, and events that will impact the team (like the beginning of the next sprint, the time of the next demo, the projected release ship date, etc.)

Backlog - a wish list becomes a Scrum backlog when it attains three things: effort size estimates by the team that will do the work, a stack ranked deliver order made by the PO, visibility to the whole team (and by visibility I mean via an information radiator - not a spreadsheet on someones hard drive information cooler).

Release Plan - a backlog become a release plan when the team projects which stories will be slotted into which forecasted sprints within the release. Think of this as a tool - not a report. You will know it is a tool if it is updated frequently and if planning happens using this visualization - if not, sadly you have a report (reports are notorious for having stale information).

Day of Sprint - count down clock, I prefer to focus on the done so I like the days to count down to D-day (Demo).

Project Goals / Objectives / Elevator pitch - this is typically the release level objectives or release acceptance criteria - how will we judge each story as moving us closer or further from these objectives for this release - how do we know when the release has accumulated enough value to ship it? See Product Positioning Statement in Beyond Software Architecture by Luke Hohmann.

Trophy Wall - big game hunters like trophies. They can take many forms, like the data flow model done at Navteq. It does wonders for the team moral.

Trophy Model

Navteq data processing visualized

components added to the model each sprint.

Annotations

Avatars - photos of each team member (including the PO & SM); these should be small but instantly recognized as that person - even by an outsider or stakeholder (don't use Bill-the-Cat)

Impeded - bright colorful attention getting contrasting sticky - noting the reason the story/task is impeded. See '7 Aspects of a GREAT Impediment Sticky'.

Theme Dots - colored sticky dots to indicate themes (well know to the team - with a reference key and labels)

Dependency - sticky annotation to label the item as dependent upon another task/story.

Orientation - Horizontal or Vertical

I find that everyone starts a task board with a horizontal flow, task moving from left to right. This is easiest to conceptualize when beginning to adopt the practice. However it will soon create an impediment. I've found it amazing that few teams are capable of realizing this impediment and solving it. The problem with the horizontal board flow is that the available space for stories is then limited by the human hight ergonomics. We don't like to stand on step stools or bend over - therefore we have about 50 inches of useful space located about 2 feet above the floor. This impediment will lead many teams to start creating smaller row heights for each story.

A Scrum task board in need of 90 deg. rotation.

Step back and visualize the problem. We humans have a small range of vertical space that is within our ergonomic comfort zone - yet a large range in the horizontal direction (use your feet). The answer is to rotate the task board by 90 degrees. Make the flow of tasks from top to bottom; stories in columns.

Physical vs Software Application

Let's discuss the pros & cons of this aspect of the tools. Ah... don't get me started. There is no comparison, physical, tactical, haptic boards have far superior affordances than the expensive software doppelgänger. When I'm teaching a team new to Scrum there is no replacement for a physical board. The information that flows when one knows how to watch and read the negative space of interaction during the stand-up meeting is phenomenal compared to the stand-up using a projector and application. And this level of observation is what the beginning scrum master needs to learn to pick up upon, it is orders of magnitude harder for me to teach using a virtual Scrum board.

However for a team that has mastered the basics of the process, and understands the reasons for most all of the behaviors they are practicing, moving to a virtual Scrum board will add a few affordances that are not available in the physical realm. These affordances are portability, time dislocation, multi-site collaboration, etc. All very advanced stages of team dynamics - WARNING - do not start with these attributes at the top of your team dynamics desires.

Google Ventures' Jake Knapp wrote about their war room - here are just a few of his reasons that resonate with this post:

Spatial Memory > Short-term Memory

To solve a complex design problem, you need to track lots of moving parts. As humans, our short-term memory is not all that good--but our spatial memory is awesome. Plaster a room with notes and you take advantage of that spatial memory. You begin to know where information is, which extends your ability to remember things.

Physical Ideas are Easier to Manipulate

We all know it’s better to re-order a prioritized list of sticky notes or re-draw a diagram than to make the same decisions verbally. That’s why there are whiteboards in meeting rooms and why people love agile trackers with sticky notes. War rooms take those tools to the next level.

See a video tour of Google Ventures' War Room: Your Design Team Needs A War Room. Here's How To Set One UP Want to foster creativity? Skip the foosball table and opt for a war room instead.

Want an example of affordances on a dashboard or infographic?

Affordances and Signifiers: applying design theory to your dashboards

References:

Missing Affordances by David Koontz

Components of a Good Team Backlog - NetObjectives

Master's thesis paper: "Analysis of a paper- and software-based Scrum task board" by Jan Segers

Agile For All blog - Building a Useful Task Board by Richard Lawerence

Visual Management Blog by Xavier Quesada Allue Elements of Taskboard Design

Task Boards: Telling a Compelling Agile Story by Tom Perry