The project I’m currently working on gave us an opportunity we rarely get – a room to ourselves to setup any way we liked. And as we’re a scrum team, the first thing we needed was our Scrum board. At the beginning of the project we had a few different styles. As a former scrum master, I’d found that sticking cards on a white board worked well, while the scrum master on this project came from a team that used magnetic strips instead of cards, also on a white board. But when we started the project, our white boards hadn’t been delivered yet. We spent the first 4 days of Sprint 1 staring at magnetic strips on the floor, while we were waiting for our boards to be delivered. By day 5, following a minor temper tantrum over not being able to visualize what was going on, I got in my car and raced to the stationery shop to buy string and some Prestik and put up a make shift scrum board until our white boards arrived. Well, we’re in Sprint 6 now, the white boards have arrived, and we’re still using the string based system. It’s given us the functionality to adapt and change the board as our needs and process evolve.

Here’s our basic template for our scrum board:

ScrumBoard - Basic

The lines are created by using prestik to stick the string onto the wall. All stories are written on index cards and stuck on the wall. We write our acceptance criteria on the back of the cards. As we need, we add stories onto the product backlog, and prioritize them. The stories at the top of the board are most important, from left to right. During sprint planning, we break them down into smaller stories where necessary, and move those into the Sprint Backlog column.

When a story gets worked on, it moves into a swim lane in the Active Stories column. The developers then add their tasks for that story using stickies (Post-It notes) in the Story Tasks columns for that swim lane. When the task is being worked on, it is moved into it’s In Progress column, and again, when the task is complete, we move it into the Completed Tasks box on the swim lane. Once all the task stickies are in the Completed Tasks column, it’s ready for testing, and we remove all the stickies for that story, and move the story card into the Testing column. This does not mean write the unit tests, they should be there already. It just means that the Tester in our team starts the functional testing, and only he can move a story to done. If there are issues/bugs, he moves the card back into an active swim lane, and adds a sticky per bug, and the normal process continues. Once he’s happy, he moves the card to done.

This process is obviously up to you, and should suit the way your team wants to work. The beauty of using string on a wall is that you can change and adapt it at any time, and you can use the whole wall, and are not limited by the size of your white board.

We’ve adapted it ourselves as we’ve gone along. For instance, in our Product backlog, we set up different columns for each area of the system so that we could manage the priorities per area (you could use the same approach if you had multiple projects). We then started reflecting our release planning by separating the product backlog into future sprints, and at the moment, our board looks more like this:

If there’s one thing you take from reading this, I hope it’s that old school is still the king. To run an effective, productive scrum team, you don’t need expensive digital systems, in fact, I advise against them. A good scrum master can easily mirror whats on the board in an excel sheet, and manage stakeholders by constantly distributing it. Or even better, get your product owners to manage the backlog on the board itself.