Scrum Boards: Physical or Virtual

I'm lucky enough to have spent the last two years immersed in a culture that strongly endorses Agile Software Development.  Not only does my employer, Excella Consulting, strongly believe in Agile, we also have a number of strong Agile experts who are significant contributors to both the local and national Agile community.  Most project teams at Excella implement some variation of Agile and the project I currently work on is no exception.

When our project started, there was some debate as to whether we should use a traditional physical Scrum Board or utilize a web based virtual solution.  Our team's ScrumMaster, Richard Cheng, advocated using a traditional Scrum Board comprised of index cards for each user story or task posted on the board.  The user stories and tasks would initially be captured and maintained in an Excel spreadsheet, then exported into a printable card format and posted to the Scrum Board.  The spreadsheet would then be stored in version control for posterity.  Whenever the team wanted to know what to work on next and determine the progress made over a sprint, then they would have to reference the Scrum Board.

Concurrently, we were using JIRA for defect tracking and I recommended that we store all of our user stories and tasks in JIRA.  I advocated that this would provide a number of advantages over the physical Scrum Board, including remote accessibility, search and eliminating the need for printing the cards from Excel.  The team agreed and I got to work adding custom workflows, fields and plugins to JIRA to support our Scrum process.  After some work, our team was set up to use JIRA as our Agile Project Management tool, and without any incarnation of Scrum Board.

Problems Arise

One of the first problems we had was when we conducted daily stand-up meetings.  For those who don't know, in Scrum, the team meets daily for 15 minutes to talk about what they worked on yesterday, what they are working on today and if they have any impediments.  During this meeting, the team stands in front of the Scrum Board talking to the cards and moving them through each of the status columns (open, in progress, ready for review and done).  Since our team was using JIRA without any Scrum Board, our stand-ups lacked a central focal point.  Team members had trouble remembering the work that was still open since it was back at their desks in JIRA.  We considered projecting JIRA during stand-ups, but we were limited in space and resources, so we decided against that solution.

The second problem we encountered was our inability to evaluate our progress mid-sprint.  When using a Scrum Board, all the work that needs to get done for a sprint is right in front of you.  Work on the left of the board in the "open" column hasn't been started and work on the far right is complete.  Additionally, if you use colors to denote priority of tasks, it makes it very easy to ensure your team is focusing on the high priority items first.  A physical Scrum Board is a simple data visualization tool that makes it easy to gauge progress.  Since we had eliminated the use of a Scrum Board, we had trouble getting JIRA to show us this same information on a single screen.  While there were plugins for JIRA that allowed us to use similar features, we found that most out of box features lacked the same impact.  The result of this problem was we began to find ourselves woefully behind schedule with only 2 days left in the sprint on a regular basis.

Best of Both Worlds

In an attempt to address these issues, we developed a hybrid approach.  Our team conducted all sprint planning and closeout meetings in a conference room, where JIRA was projected and updated in real time based on conversations in the room.  Once a planning meeting was complete and the stories for a sprint were set, the ScrumMaster would then use JIRA's built in export to Excel feature to create an Excel spreadsheet of the work for the upcoming sprint.  Then, a Microsoft Word Mail Merge template was used to read the data from the spreadsheet and to create a card for each User Story, Task, Spike, etc.  The stories were then printed out on colored paper, which we used to quickly denote priority (red for high priority, yellow for medium, green for low priority and blue for stretch tasks).  Once printed, the ScrumMaster would then cut the cards out and post them to the Scrum Wall.  It may seem like a lot of work to duplicate JIRA data on a physical board, but it only took one person less than an hour per sprint, an acceptance burden.

By using this hybrid approach, we were able to solve both our problems.  The team now had a physical Scrum Board which they could interact with on a daily basis during meetings, which also reflected the work assigned to the sprint in JIRA.  We also were able to access progress being made on a sprint in real time quickly by inspecting the physical Scrum Board.  Team members still had their personal task lists in JIRA, and we could still (and do) search through old stories from previous sprints to find out what happened in the past.  Using JIRA to record our project's complete history is extremely powerful, but having a physical Scrum Board makes managing work during a sprint critical.  By marrying these two solutions, we were able to achieve the best of both worlds.