In Scrum and other flavors of Agile, the task board represents the team’s plan for the sprint. Where I work, we have a rolling whiteboard for each team. They use one side for their task board, and one side for the release backlog and other artifacts. The board is an amazing information radiator. It contains the team’s stories, broken down into tasks. It has their written Definition of Done. It has their Sprint Burndown chart, showing the task hours remaining on each day of the sprint. It has a place to note unavoidable distractions, so that the team can make them transparent and management can detect patterns and potentially make changes to better insulate the team.
My colleagues and I have found in our collective experience that the physical wall board keeps Scrum operating more smoothly and efficiently. Whenever we try to figure out why, we always come back to “there’s just something about the physical board.” But what is that something? Giving it some thought based on my experiences, here’s some reasons we get tempted by the tools, and reasons why we should resist urge to use them in most cases.
Top 10 Reasons You Might Be Tempted to Use an Electronic Task Board
10. They are like shiny new toys
9. They have a lot of cool features
8. We won’t need to beg the office manager to let us hang unsightly sticky notes on the walls
7. We can integrate it with our other tools
6. The tasks will be neater without everyone’s scribbled handwriting
5. Upper management can see the task boards without having to walk through the development space
4. Tools increase our productivity
3. They’re electronic!
2. You have a geographically distributed team
1. Did I mention they are electronic? And shiny? And have features out the ying-yang?
Top 10 Reasons To Use a Physical Task Board Instead
10. The team is more likely to keep it updated. Why? It’s right in front of your face. You have your standup in front of it. You pass it on your way to the foosball table. You drag your teammate in front of it to make a decision – together – about what task should be started next. Guess what? That decision? With a tool? I’m not asking my coworker what he thinks, I’ll just stay at my desk, with my tool. In fact, I may not look at the task board at all.
9. Keep it simple: tape, index cards, sticky notes and markers are all you need. What’s the simplest possible thing you can do that can possibly work? These piles of school supplies remind me of elementary school again, in a good way. It must be pretty darn simple.
8. They’re faster to read AND to change. Tools may seem fast but scratching out that 8 with a marker and making it a 4 will beat logging into to a tool, finding the task, clicking the edit button, making the change, saving, waiting for the page to refresh…you get the point. Picture Sprint Planning, when stories are being tasked out. When we are discussing a story’s tasks, developers, testers, and technical writers all grab color coded sticky notes and write out the tasks for the story as we discuss. It’s parallelized! One projector in the conference room means one person serially entering those suckers in, and everyone else getting tired of correcting the exact language the team agreed on.
7. About that office manager – if you are having trouble getting permission to modify your space to support the team’s needs, you might have a bigger problem on your hands. I’d go ahead and fight that battle.
6. Tool integration is overrated. At least for stories. Tracking stories to defects? Why? Tracking stories to test cases? Again, why? Keep it simple, is what I say. In my opinion, we sometimes integrate tools because we can, but when we don’t have it, we — gasp! — find we do fine without it. If there is truly a need to keep information electronically and tie it to another system, we can usually find a different – and simpler – way to do that.
5. Teams I’ve worked with have been more productive using the physical board. I think this is because we made the effort to stand in front of it when we had our daily scrum. Also because interest in using the board doesn’t fade with time. Because monitors get turned off, applications get minimized, other information is displayed instead or additionally. Because picking up the sticky note and moving it to the next column is a very specific, meaningful, and descriptive action. People also seem to like doing it.
4. Change is easier. No matter how great the UI is for your tool of choice, nothing beats moving cards or stickies up, down, around. Adding new ones, taking obsolete ones off. It’s just…easy.
3. No need for your VP to log into a tool and have to click around team by team to get an idea of where each one stands. Our VP walks down the row of wallboards in the morning, spending a few seconds at each board, and gets what he needs at a glance. This helps the team too, for the same reason.
2. No tool constraints. One tool I used in the past would only let the person who the task was assigned to drag it across the electronic board. That’s a real pain when sitting in front of a keyboard logged in as the ScrumMaster. ”I’ll move the task to in-progress when I get back to my desk” is the common refrain, and wow does that change the momentum of the meeting. On a physical board, you want to draw arrows pointing to a particular task? Do it. Want to add or remove a column because it’ll make more sense for you team (or for this release)? Go for it. Want to tape the mockups for a story right to the index card? Do it. Want to stick a red dot on there to indicate (choose one) [this task is blocked | this story has a defect | waiting for some information | this story was brought into the sprint after planning]? Be my guest.
1. Believe it or not, the physical task board can be more accurate. Why? The English language is subject to much interpretation. When one person controls the keyboard, what gets entered into the tool will be written or worded the way the keyboarder feels it should be. I have witnessed and heard of instances where that meaning ends up different from what the team intended or thought they agreed on.
Now, the one reason I might be swayed towards an electronic task board is if I was working with a geographically distributed team. In some cases it might be the only way to keep all team members in synch. My thoughts on that, however, are that keeping a distributed Scrum team running requires so much more effort than a collocated team, the tool is the least of your worries. An article for another time. In the mean time, I’m going to go stock up on sticky notes. See ya!

Very interesting post!
I think the number one reason I might want to use an electronic board would be an extension of point #3: since they are electronic, they are searchable. In practice, though, that’s not important. The fact is, in scrum, what’s important isn’t what is on the backlog but rather what are we doing _this_ sprint?. That’s all the team should care about, right?
The last place I worked at used an electronic board that was slow and cumbersome. What little was gained by the whole “it’s electronic!” thing was lost many times over by the fact it simply wasn’t usable. Time was spent switching views, adjusting filters, opening, editing, saving, etc.
Your point about not needing to link stories to tests initially struck me as wrong. I’m old school and like the linkage. Yet, when I think about it, I’ve never actually needed that function. Besides, who cares what story triggered the creation of a test? All I really care about is whether a given _feature_ has test coverage.
So yeah, I agree. +1 on the physical board.
Hi Bryan -
I know where you are coming from on the story –> test linkage. It took me a while to come around to this point of view. My logic is that it’s best to run all the tests all the time. If for some reason you want to run a subset of the tests, like you said it’s not the story that’s important, it’s the feature. Test are usually organized physically by feature or area of the product anyway, so running a subset could be done that way. I also think about coverage – how do we know a feature is covered, or that we have enough tests? We know the same way we know developers have written the ‘right’ code – through the transparency of conversations within the team and with the Product Owner, code reviews, and demonstrations of the working functionality. We trust our skilled developers and test engineers to to do ‘just enough’ testing coverage to meet the quality requirements of the business.