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



Post a Comment

Most Popular on Agile Complexification Inverter

Exercise:: Definition of Ready & Done

Assuming you are on a Scrum/Agile software development team, then one of the first 'working agreements' you have created with your team is a 'Definition of Done' - right?



Oh - you don't have a definition of what aspects a user story that is done will exhibit. Well then, you need to create a list of attributes of a done story. One way to do this would be to Google 'definition of done' ... here let me do that for you: http://tinyurl.com/3br9o6n. Then you could just use someone else's definition - there DONE!

But that would be cheating -- right? It is not the artifact - the list of done criteria, that is important for your team - it is the act of doing it for themselves, it is that shared understanding of having a debate over some of the gray areas that create a true working agreement. If some of the team believes that a story being done means that there can be no bugs found in the code - but some believe that there can be some minor issues - well, …

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…

Team Performance Model - by Drexler and Sibbet

Many of you have all heard of the Tuckman model of team dynamics (Forming, Storming, Norming, Performing).  It was created in 1966 and has become the most popular model for describing team behavior.  Is it time to level up in your mental model of team dynamics?  Are you ready for a richer more functional model?



Introducing the Team Performance Model by Drexler and Sibbet



Orientation - Why am I here?
"Orientation is about understanding the purpose of a team and assessing what it will mean to be a member.  you need to understand the reason the team exist, what will be expected of you and how you will benefit from membership.  In a new team, these are individual concerns, because the group is only potentially a team.  that is why these concerns are illustrated as occurring in your imagination at an intuitive level.  As a team leader it is important to provide time and space for people to answer these internal questions themselves."

Keys to when Orientation challenges are resolve…

Do You Put “CSM” After Your Name?

I’ve noticed a new trend—people have been gaining titles. When I was younger, only doctors had initials (like MD) after their names. I always figured that was because society held doctors, and sometime priests (OFM) in such high regard that we wanted to point out their higher learning. I hope it was to encourage others to apply themselves in school and become doctors also. Could it have been boastful?

The Wikipedia describes these “post-nominal initials”:
Post-nominal letters, also called post-nominal initials, are letters placed after the name of a person to indicate that the individual holds a position, educational degree, accreditation, office, or honor. An individual may use several different sets of post-nominal letters. The order in which these are listed after a name is based on the order of precedence and category of the order. That’s good enough for me.
So I ask you: is the use of CSM or CSP an appropriate use of post-nominal initials?
If your not an agilista, you may wonder …

Refactoring - examples from the book

Martin Fowler's book Refactoring:  Improving the Design of Existing Code has a simple example of a movie rental domain model, which he refactors from a less than ideal object-oriented design to a more robust OO design. Included in this Refactoring_FirstExample.zip Zip file are the Java source code files of the Movie, Rental, and Customer classes. Along with a JUnit CustomerTest class. Using these example source files you too can follow along with the refactoring that Fowler presents in the first few chapters of his book.