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

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.

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

David's notes on "Drive"

- "The Surprising Truth about what Motivates Us" by Dan Pink.

Amazon book order
What I notice first and really like is the subtle implication in the shadow of the "i" in Drive is a person taking one step in a running motion.  This brings to mind the old saying - "there is no I in TEAM".  There is however a ME in TEAM, and there is an I in DRIVE.  And when one talks about motivating a team or an individual - it all starts with - what's in it for me.

Introduction

Pink starts with an early experiment with monkeys on problem solving.  Seems the monkeys were much better problem solver's than the scientist thought they should be.  This 1949 experiment is explained as the early understanding of motivation.  At the time there were two main drivers of motivation:  biological & external influences.  Harry F. Harlow defines the third drive in a novel theory:  "The performance of the task provided intrinsic reward" (p 3).  This is Dan Pink's M…

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…

Innovation in the Automobile Industry

In the 1900s the automobile industry was the most important and innovation industry in the USA.  But one could question if this was good for our society in the long run.  And one could question if they actually innovated.

In the early 1900s there were few automobiles, very little infrastructure created to support the industry.  For example the road system was still designed for horse drawn wagons and the wagon wheel (remember a steal rim and wooden compression spoke wheel).  The future US Highways, or the 1950s Interstate Highway System at the cost of $425 billion were decades and many innovations away. There was no gas service station, there were however horse stables, farriers, and blacksmiths in each town along the roads.  There was no real "road map", there was no road naming system, like was created in 1926 - the United States Numbered Highway System.

The industry employees millions of people, and was a large factor in the economy of the USA.  It created or was created b…

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"?