Here is an example of how or Scrum Board looks. It’s not the real one as they’re not a fan of taking pictures at work, bit it gives you the idea. While the focus on Scrum Board is always on moving post-its from “To Do” to “Completed”, there’s more to it than that if you want to effectively communicate the progress of the Sprint.

The Scrum Board

The board itself is a pin board. While tasks are usually represented by post-its, previous experience has taught me how even a slight breeze can cause a disaster to a Scrum Board. Therefore, every piece of paper is also pointed to the board, to stop it going awry unexpectedly.

Items on the Board

  • Sprint Number
    This is just a label so everyone knows where we are. This, perhaps unsurprisingly, started at 1 and just increases every time. It also allows for easier tracking on the Task List.
  • Calendar
    Each day in the Sprint is represented by a post-it. This allows team members to show when they are on holiday or have other commitments, and when they are able to work on the project.  We also have a walking today post-it that moves every day that clearly shows how far through the Sprint we are.
  • Story Progression Grid
    Each story has its own Swim Lane (a row). We try to restrict this to 8 Stories (including the Overheads story) partly so we don’t get swallowed by things to do, and partly because this fits nicely on the board.This grid is then split into 4 columns.

    • Story Description
      The title, description, and other properties of the Story, are printed from the Storybook, via an MS Word mail merge, onto an A6 paper (well, 4 stories per piece of standard printer paper, then cut to size).  These describe each row, to assign tasks to.
    • To Do
      These are tasks that the have not yet been started. Each task is labeled with its story number, task number, description, and estimated hours. This information is from the Task List, again via an MS Word mail merge, this time printing 8 tasks to a standard printer paper page, then cut to size. This is pretty close to the size of a post it note.
    • In Work
      When a team member picks up a task they move it to the In Work column, and initial it using a board marker. I also encourage that long running tasks regularly have the number of hours spent to date recorded on them, even if the post it itself is not moved to Completed.
    • Completed
      As expected, this column lists all the tasks that have been finished. When a task is moved to Completed, the total number of actual hours spent to complete the task is recorded. After each daily stand up meeting I note the newly completed tasks and the hours spent and record this back on the Task List.I then mark the tasks with a red marker pen to indicate they have been recorded already, and that I can ignore them in the next meeting.
  • Progress Charts
    Updated daily these show the burndown in outstanding Stories, and expected hours. I’ll cover how these are created in a later post.
  • Problems and Other Work
    Potential impediments to the delivery of task completion are encountering problems, which require assistance from either others in the team, or people in the wider business, or the need to complete other commitments outside of this project, such as standard support calls.  It is worth adding these as notes to the board, in a bright post it so it is obvious that these issues exist.
  • Product
    Finally, it is worth keeping in mind where we are in the build process, and what has been created to date.  This is particularly useful once the project starts maturing, and feedbacks are raised, to be able to talk around the problem at the Scrum Board, and to be able to see what it is that is being discussed.


Finally finally, I also have a document sleeve pinned to the bottom corner of the board.  This contains new post-its and Board Markers in it.  This means they are always available and we never run into the problem of standing at the board, and not being able to write or add anything when needed.


This is how I set up our Scrum Board, and over 6 months later there don’t seem to be any obvious improvements.  Everything has a purpose, and is there to demonstrate to our team, the Product Owner and to the wider management the progress of the project.