Agile consultants love sticky notes.
I think it’s because using sticky notes, during the initial agile training, makes for a great group activity. Everyone is sitting at the table, writing out user stories. Each person gets a turn to go up to the wall and stick their note. Everyone gets to collaborate with the prioritization. Agile practitioners love post-it notes so much, they even have blog posts dedicated to proper post-it note technique.
“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.” – Mike McGarr
Physical Scrum boards work great when everyone is sitting around the same table. However, they fall apart when you walk back to your desk. You can’t quickly access your tasks without getting up, and looking at the board.
It’s even worse if you have a distributed team. I’ve seen companies set up all sorts of wacky systems to support their physical boards: webcams pointed exclusively at the board (including spotlights so developers working at night can see it).
The other problem with physical boards? You lose all of your project’s history after each sprint. Your team’s only record of a task is the sticky note, and those are thrown away once completed. Need to find out when a story was completed? Who approved it? When was it deployed? All that data can be recorded automatically with software.
In my experience working with software teams, even co-located ones, the preference for physical Scrum boards is more religious than practical.
“I decided to implement a SaaS service to provide an online board, but after speaking with Agile coaches it appears they don’t like this virtual solution because it breaks the real interactions promoted by the Scrum framework.” – Olivier Hory
Many teams blindly accept the Scrum coach’s advice, even though it’s not a good fit for their team. Open source projects have shown us that you can have healthy interaction without needing to be physically co-located. These projects are run over mailing lists and GitHub, and often involve a high level of complexity.
Physical boards become even more impractical when it comes time to generate reports (burndown, timelines, team focus, etc..). The poor Project Manager is often relegated to manually copying data from the board each day, and creating reports in Excel.
“One of my teams now uses a physical board and I have to go in every day and copy the points remaining from the board into an excel spreadsheet so that I can generate a burn down chart.” – Night Man
Which approach is right for your team?
The key is to let your team decide. Don’t choose a physical scrum board because a consultant told you to; likewise, don’t use a digital tool because I told you to. Talk to your team. Figure out which workflow works best for them.
Also: use the tool that best fits your reality. If you have a distributed team, use a digital tool. Likewise, if everyone’s co-located, and working in the same fishbowl, it might make sense to have a physical board.
Be aware of how the tool you choose affects different team members: does it add unnecessary work for your Product Manager, developers, or QA people? Reduce friction wherever you can.
