Everything on the Board

“So, when does your sprint end?”
“Let me check the calendar.”
“Will this story be finished this sprint?”
“I don’t know; Phil is working on that.”
“Where is Arthur?”
“Has anyone seen Arthur today? His day off is only tomorrow, is it?”
“Did we actually send this e-mail to Felix?”
“Arthur knows that…”
“What products is this team actually working on?”
“We have five projects, no six! But currently we only work on one. Or actually two…”

When watching cop shows, you often see the inspector stand in front of a big whiteboard that shows bits and pieces from the case they’re on. There’s a photo of the crime scene, notes and lists in various colors, and lines and arrows to try to create some structure in the murder case.

And indeed, after a while, when three more murders have been committed and the wall is full of bloody pictures, suddenly the hero gets an idea. Something clicks, and all the messy information in front of him suddenly makes sense… So now he has to jump in a car and drive at break-neck speed to the murderer’s house, to prevent another murder.

And often they find in the secret room in the murderer’s house another whiteboard, with photos of his victims and articles from newspapers from years ago, that give a clear insight in the murderer’s deranged mind. Criminal arrested, case closed.

Those white boards are not only there because they look good on television. It is actually helpful to make information visible like that. It is easier to think, to make connection, or to organize information if you can actually see it.

The Scrum board is where a Scrum team keeps track of everything happening in their sprint. It helps them to organize their work, and show anyone else how things are going. This is not restricted to the work flow; a Scrum board can show much more than that.

The Accessible Board

“What’s the URL of the Scrum board again?”

The best Scrum boards are available all the time, by just looking up. This will make sure the information is available at all times. But it will also make it easy to keep it up to date; because if you don’t, you might as well not use it.

Large and Near

The Scrum board should be large, close to the team, and readily available at any time. This allows everyone to look at it whenever necessary. There should be ample room around it, so that the team can gather around it at the daily stand-up; but it should also be possible to stand in front of it with a couple of team members without disturbing others. Many discussions take place in front of the Scrum board. Make sure they can happen!

A Scrum board can be a whiteboard or just a wall. If you use a wall, it is probably better to stick a large sheet of paper on it, as it allows you to move the Scrum board if necessary. If you have your own, large team room, this may not be needed.

Low-tech over Hi-tech

Electronic Scrum boards are not very good. They are not continuously available (unless you have a very large spare screen), they don’t allow you to stand in front of them and oversee all of it at once, and they miss the flexibility of the old-fashioned paper-and-pencil version.

Research shows that it is easier to remember things when they are different. So hand-written notes, not exactly in a grid, with drawings and ornaments are much easier to visualize when not in sight than square blocks on computer screens.

Scrum Board for Remote Team Members
There are various Scrum board applications that allow you to share a Scrum board over the internet. None of them have the power and flexibility of a wall with index cards and sticky notes.

But if you are forced to use some electronic means (e.g. because you have a distributed team) you can use a physical board during the day and transfer the changes once every day to the electronic version.

Using a high resolution web-cam, or publishing photographs may also work. You have to make sure that the remote team members can make their changes to the board, too. They can e-mail their changes to someone near the board, or use instant messaging.

If remote team members work together on another site, they can have their own Scrum board. It should be a copy of the main Scrum board; if each half of the team has a different Scrum board it may be better to split the team.

But that way, keeping the Scrum board up to date is a lot of work. If you want to avoid the extra work, get a Scrum board application, but get an extra screen in your team room that always shows the Scrum board.

Use Colors

Things that are different are easier to remember. In trying to make different things as different as possible, colored stickies and colored pens can also be very useful. Use them for tasks that are different, for stories that are not tasked yet, or for unplanned work. You probably won’t mistake a yellow sticky for a blue one.

The Board Has Two Audiences

On the Scrum board, you keep track of the progress of your work. But for whom are you doing this?

The first and most important audience is the team itself. They use the board to keep track of what they’re doing: using the familiar three columns (To Do/Stories/Not Checked Out, In Progress/Checked Out, and Done) they make every task and every story float from the left to the right. It is the principal tool for the team to keep track of everything; it’s theirs and they should use it how they see fit.

But don’t forget that other people may also take a look at the Scrum board once in a while: managers, to see how things are going; or stakeholders, worrying that their items are not ready in time. So be aware that you might need to answer questions about it once in a while.

It’s a good idea to organize the board clearly, with the three columns on one side and a status area (with the burn-down chart for example) on the other side. In the status area, you can also put more information for that other audience: the time of the daily stand-up, the names of the people in the team, the products the team is working on and so on.

Everything Flows

After the team tasked the story, they conveniently put names on most of the tasks. Tim got all the tests, Giulio, as a DB administrator, was assigned the creation of databases and tables, and Neil, who did a similar story before, was going to implement the business logic.
The sprint progressed nicely. But near the end, it became clear the story was not going to be finished. Because the team had been waiting for the database to be ready, they started late on the other tasks. Tim really didn’t have time, but nobody picked up the task that had his name on it. And now Neil called in sick…

One reason why a sprint can fail is when tasks or stories get stuck. The board can help you in preventing that, or at least in noticing it early.

Use Names on Tasks

Never assign tasks. The team should have the freedom at any time to decide what to do, who does it, and works together with who. If tasks are assigned to people, the flexibility of the team is killed; you create a critical path where there wasn’t one.

It might come as a surprise when a certain member of the team picks up a certain task, but this is a good thing. People learn a lot when they get out of their comfort zone. The knowledge about a certain type of task is spread more evenly over the team. And the person who always did this kind of tasks is now free to do something different.

Whenever you take a task in progress, mark it with your name or initials. That makes it clear you took the responsibility to finish the task. Alternatively, create a marker (a colored stick or a magnet) for each team member. This has the added advantage that it becomes difficult to work on more than one task at the same time. Now, everybody can see at any time who is working on what. This will make it much easier to offer help or discuss impediments.

Use Dots for Days Spent on Tasks

If you think that some tasks are stuck in “In Progress” for a long time, you can put a mark on each task in the “In Progress” column at the end of the stand-up meeting. Tasks that are in progress for a long time will accumulate a lot of dots. It will be a sign that something needs to happen; you can discuss it in the stand-up.

Shortest Path from To Do to Done

“Why is that story still not done?”
“Because Mark still needs to review my code. Look, the task is there, in To Review.”
“There, below all the others!”

Some Scrum teams use four or five columns on the board. Apart from “To Do” and “In Progress” they have “To Test” or “To Review” before “Done,” or even other columns.

Don’t Use Extra Columns

The idea of the “To Review” is that developers review the code written by other developers. The idea of “To Test” is that every task passes through the “To Test” column before it is done. The problem with extra columns is that they don’t necessarily apply to every task that is on the board. How do you test an e-mail that is written? How do you review a deployment that was done?

When some tasks skip over those columns and some don’t, it is actually less clear what needs to be done. There is an easy solution for this: write an extra task for every test that needs to be done. This can just be added to the story in the “To Do” column and moves through “In Progress” and “Done” just like any other task. Every task imaginable will be in progress at one time and done at another, so that always works.

All extra columns also have the disadvantage that the ownership of a task changes when the task goes from one column to the next. If Harry completed code and puts it in “To Review,” John will need to pick it up. If Alice finished a feature and moved it to “To Test,” Phil will need to test it. Those tasks are more likely to remain orphaned than the tasks in the “To Do” column. When there is an explicit task for everything, it is much clearer who took responsibility for it.

Pair Programming Instead of Code Reviews

Should you review code at all? There certainly are benefits to code reviews. Some other person looking at code with fresh eyes might spot bugs at first sight, and come up with obvious improvements. And a second person trying to understand the line of thought will easily discern the pieces that are hard to get, and thus require more work or comments.

There are drawbacks as well. If one person is doing all the code reviews for the team, he or she can become the “teacher” or “boss” handing out the “grades” in the eyes of the others. This is certainly not good for team spirit.

On the other hand, if everyone is taking an equal share in reviewing code, you cannot expect all reviews to be equally good. Reviewing code is hard, and for many people it is much less entertaining than writing new code, so some people will skim over the code and make some general comments instead of trying to really understand it.

There is also the danger of people assuming that there code doesn’t have to be good because they know it will be reviewed. They can then conveniently move the blame to (or at least share it with) the reviewer.

There is an alternative: pair programming. If you program together, you are effectively reviewing each other’s code continuously, back and forth. Also you are fixing the issues you find, and learning from it continuously, without putting it off till later. And since you are doing it together, you feel much less like someone is grading you. It is a lot more fun than reviewing code, too.

But There Is More

The Team had a retrospective meeting, and they were discussing why they finished only two stories.
“So why didn’t we finish that reporting functionality again?”
“Well, we were waiting for the template, but in the mean time, we had the production issue, you remember?”
“Yes, and don’t forget that Gary was busy for a week to fix that bug we discovered last sprint. That wasn’t planned, but we had to do that first.”
“But actually I forgot to send that mail to ask for the template…”

The Scrum board is not only there for stories and tasks, it is there to make visible what everybody is working on. That way it is clear for everybody if things change.

If you put everything on the board, there are no surprises. You get much more insight in how the sprint is going than by just looking at the burn-down chart (which doesn’t tell you why) or by just attending the stand-up meetings (which only talk about today and yesterday.)

Unplanned Work

Whenever some unplanned work comes up, you should make a sticky for it and put it on the board. The Scrum board is not only there to show what the status of all the work is. It also works the other way round: at any time, you can see what the status of all the team members is. That doesn’t work anymore when people are working on tasks that are not on the board. It might lead the team into thinking that Philip is doing this, while in reality he is working on that; and then this is not done until it is too late.

You can make a special section for unplanned work on the board. This is especially useful for work that is not related to any story already on the board. This is assuming that the unplanned work is more important than all the other work in the current sprint. It should be; if not, it should wait until the next sprint.

Never take in unplanned work just like that. It is disrupting your sprint and endangering the work you committed to. Try to limit the amount of unplanned work as much as possible, postponing until next sprint what you can.


If any impediments come up during the stand-up (or at any other time), it is probably a good thing to keep a list of them on the board. That way the whole team can track if they are cleared, and the Scrum Master can go over them in the daily stand-up.

If the Scrum Master is swamped with impediments, the rest of the team might offer help. After all, if every member of the team is blocked, they cannot work anyway; it’s better to help clearing the impediments early, to prevent this from happening. A clear (and visible) list of impediments helps noticing this in time.


Sometimes you realize some work needs to be done while you are working on something else. A “Next” corner on the board can be used to hold these. The Product Owner should pick them up and work them into the product backlog as soon as possible, but in the mean time they are at least not forgotten. And if there is a little time left in the sprint, and the Product Owner agrees, you can pick them up right away.


In a stand-up, you shouldn’t discuss things for too long; you should decide to discuss things outside the meeting. If there are a lot of things to discuss, you can make a list of them in the “Issues” corner. Also things that need to be discussed later (when the release is done, or when the Product Owner is back from holiday) can be parked there.

Improvement Items

If you came up with some good resolutions in the retrospective meeting, it might be a good idea to have them on the board as well. This way the team will read them at least once every day (at the stand-up.)

It will also be easier for anyone in the team to bring it up if needed: “Hey, according to the list of good things there we check in working code daily. Are we still doing that?”

Don’t forget to remove them after the next retrospective, and replace them with new ones. If you don’t touch the stickies with improvement items for a long time, you will no longer see them, and then they don’t help anymore.

Holidays, Reminders, Cartoons
There are more things that can be useful to keep on the board, although by now you might need a second board:

  • Especially in the holiday season: who is gone from when to when?
  • “Team event tomorrow!”
  • “Source code repository not available from Friday 17:00 to Monday 8:00 because of maintenance.”
  • Last week’s XKCD.

The Scrum Board: Getting It Right

“So, when does your sprint end?”
“Will this story be finished this sprint?”
“Where is Arthur?”
“Did we actually send this e-mail to Felix?”
“What products is this team actually working on?”

“Look at the board!”

The Scrum board is your one stop source of information about the progress and state of the sprint. Anything that has to do with the working process can be stored there. This is not design, documentation and code, they go somewhere else.

Try to put everything that is relevant on the board. If the board is used for everything, you never have to guess where to look. If you can’t find some information you expected on the board, put it there. Others might be looking for it as well.

Organize the board clearly. Create sections on it for:

  • “To Do”, “In Progress”, “Done”
  • Impediments
  • Burndown chart
  • Unplanned items
  • Issues
  • Next
  • Team members and holidays
  • Improvements items
  • … and anything else.

Empty sections will invite the team to fill them. Just by creating them, you will improve the completeness of the information on the board.

Keep the Scrum board rigorously up-to-date. Wrong information is even worse than no information. Make the information clear, well-written and well organized. You will look at it often; make it a pleasure to look at.

Most of the Scrum board can be wiped entirely after each sprint. Only unfinished stories are carried over from one sprint to the other, but they are taken off the board, re-sized, re-prioritized and put on the board again. What is left from the last sprint is the velocity. And lots of working software.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.