Skip to main content

Elements of an Effective Scrum Task Board

Leadership desires - Info Radiators 
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.

Team desires - Info Radiators

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
    To Do
    Work In Process - (many teams limit WIP - label this or make the column very small)

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).

Trophy Model
Navteq data processing visualized
 components added to the model each sprint.
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 L 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.


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

Missing Affordances by David Koontz
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

Post a Comment

Most Popular on Agile Complexification Inverter

Where is Shakespeare When We Need Him?

We are desperately searching for a term for people that connotes the best of human kind.  The creative, sensing, combinatorial synergistic, empathic solutioning persons that have yet to been labeled with a role name that works.

Some of the old terms:
Staff, Workforce, Human Resource, My Team, Army, Company

Shakespeare created 1700 words in his time.  He mutated verbs to nouns, and vice-a-versa, transformed verbs into adjectives, and formed words from whole cloth never before heard.  This skill is rare, but there is a poet that can create the term we need in the twenty-first century.

What should this term define?

21st Century Human Resource; the generalizing specialist.

Yes, but what more?  What less?

Suggest your poetry in the comments, let us see if we cannot do 1/1700 as well as The Bard.

By-the-way; who create the phrase "coin a word"?

A TED Play List - How do you create new words
Erin McKeanGo ahead, make up new words! In this fun, short talk from TEDYouth, lexicographer Er…

Situational Leadership II Model & Theory

Have you ever been in a situation where you thought the technique needed to move forward was one thing, yet the person leading (your leader) assumed something else was what was needed?  Did you feel misaligned, unheard, marginalized?  Would you believe that 54% of all leaders only use ONE style of leadership - regardless of the situation?  Does that one style of leading work well for the many levels of development we see on a team?

Perhaps your team should investigate one of the most widely used leadership models in the world ("used to train over 5 million managers in the world’s most respected organizations").  And it's not just for the leaders.  The training is most effective when everyone receives the training and uses the model.  The use of a ubiquitous language on your team is a collaboration accelerator.  When everyone is using the same mental model, speaking the same vernacular hours of frustration and discussion may be curtailed, and alignment achieved, outcomes …

One Dark and Stormy during a Hurricane

I'm from the Carolina's where legend has it that our family commonly just hunkered down in the home on the coast and waterways than to head for inland shelter. Now that's from the old school days of barely improved (read paved) roads. They counted a storms severity by how high on the back porch steps (about 15 - top to ground) the water reached.  I don't recommend this action in todays world of long range forecast and transportation options.

I do recommend a drink or two in a hotel bar, far far away.

This is the week that Harvey came ashore in Texas.  I live on a hill in the little old town of Grapevine outside Dallas and Fort Worth.  And thank you all for letting me know that a storm is coming... I didn't get out and walk Malibu before the rain hit, so I grabbed a hat and we went anyway.  Much nicer walk with the drizzle, I'd say.

I'll raise a glass to you - if you were not smart enough to do the responsible thing, at the last responsible moment.

I do re…

Software Development terms applied to Home Construction

Let's Invert the typically wrong headed view of Software Development project management as a construction project.  We can map it the other way just to see if it works... to have some fun, to explore the meaning of phrases we toss around quite frequently.

Normally Project Management terms come from a construction domain.  We are going to apply the lexicon of modern software to the construction of a home.  We will follow the construction project and meet some of the people doing the work.

This is a very small (8 homes from $600,000 skyward) program in my 30-40 year old neighborhood.

About 6 months ago I saw the programs landing page go up.  It gives casual observers and some of the stakeholders a general idea of the intent of the program.  And most importantly who to contact for additional information if you happen to be interested in their products.

The Refuge program has 8 product projects and has them running independently.  Yet much of their DevOps infrastructure has already b…