Agile: The Story Board

The story board…

If you have used Agile for Project Management or Software Development, and used Scrum, you probably have heard of the “Story Board”.

Funny thing though, I have talked to a few people that have came through and they saw the boards we have and it was “oohh I have never seen one in real life”.. but yet they have run or been involved with scrum before.

So what is the deal with the “board”?

• The Board is a focal/gathering point
  Every day at your standup/scrums, you should bring the board in and use it as a tool. Also at the sprint planning. Think of it as another team member. Talk to it. Talk in front of it, analyze it, adjust it, show it off, explain things on it to people
• The Board shows tangible evidence of results
  You should hang your velocity and burndown charts on the board, you should have a nice full current and next sprint that changes every day as people do things and new items get prioritized. Your backlog should be filling up. Communicate your iteration dates and maybe other key info, but most important, if someone walks up, they can see your burndown.
• The Board is a talking point
  People around the office start asking “What is that thing?” People in other teams want to know what is up. Other people might come up and ask where things are at, or where their “story” might be. You can use the board to start discussions on agile and also about your project
• The Board let’s your focus
  As a developer or “do’er” for your project, you can focus on just the current sprint. You can focus on the cards on the board. You see slightly what might be coming in next sprint, but you are focused. As a product owner or team lead, you can see progress and focus on the current 2 weeks.
• The Board makes it tough for distributed teams
  If your team has some members off site part of whole of the time, then it is harder for them to actually “use” the board. They need a virtual board as well. They need virtual stories or some way to update progress.
• The Board adds a little overhead for Scrum Masters
  With a online system or virtual system, the Scrum master can update things there, and so can the developers. With a board, and especially with a board + virtual system, the scrum master has to make sure things are in sync. What should they focus on? The board or the virtual system? Both. But since the board is visible to EVERYONE who might walk by, they need to make sure it is up to date and in working order.

My thoughts: The board *should* exist, you *should* use a board.

But, what if you run distributed teams? Then.. if majority of them are not on site, then use a virtual board. If it is a mix, use a physical and virtual board.

But what if we don’t have room for a board? Then make room.

But a board costs money. Not really. I made one out of things lying around the office. Minimal cost. You can expense story cards, etc.

But xyz.. well, I am sure there is an answer.

If anything, start with a board, and cards (another blog post on that) for at least one year, and then look at going virtual, *if it makes sense*. I still think the use of the physical board is a key part of the process, but like with anything Agile, the process always differs by team and project.

You can always roll the board somewhere to demo. You can show the board to anyone. Any worker, any executive, a group of many people, or small. You might not be able to do that with a virtual system: you might be limited by number of accounts or other system limitations.

The board might be a “relic” of agile, but I think it lends itself to running the process in a way many can understand, without having to learn any software, and also lets your team communicate progress and results easily. Use a board? Just do it.