Scrum board. What's the best taskboard and information radiator?

About the last 10 years of my Agile experience I have been using various tools to monitor progress and keep an overview and radiate information. Some were more successful than others of course.
Some of the "best" products were not always helping. Now at Backbase we use a set of JIRA tools. Before that I used mainly Super Sticky Notes and a whiteboard. To keep track of the numbers and print a burndown I used a simple but effective spreadsheet and some counting on a daily basis to sum the work "done" and work "not done". Works great and is a good way to keep the taskboard up-to-date and clean. As a ScrumMaster I feel accountable for what's on the board.

Strawberries' Wall

For a bigger project and team we didn't have enough space for the sprints and whiteboards were not immediately available. We used a wall (Strawberries, red) as a taskboard and that worked also quite well.

Initially there was not too much trust that the notes would still be there after the cleaners came, or some non-project co-workers would make funny changes. All those imaginary "horror scenarios" didn't happen because the project was just too important to mess with. Sometimes an incorrect note was used (not a super sticky note), but was replaced by me then and I made sure we had only the right stickies around.

JIRA/Greenhopper

The JIRA/Greenhopper set works but I don't have the feeling to be in control and the tool is not easy as an information radiator. For stand-ups we used a laptop and beamer to have the actual taskboard available.

Doable but not my preferred way. As an information radiator you could use the Wallboard plugin/product but that requires an extra fixed display/TV/computer and I doubt a positive impact in the long run. It just becomes an expensive wall decoration is my guess. Nice to show off, but that's not what Scrum is about.

Homebrew tool

In the early days (in about 2002) for a project we built our own task management solution which was mainly a story/task management system to register the stories, the estimates, the remaining time and the percentage done. A very lightweight but usable webapp was the result after a couple of days development + thinking about it (<= 5 mandays using Java, yes that was no problem at all). The consequence was that for a few weeks it was used as intended but then the added value disappeared. We started to work in a mixed XP/RUP way and that worked very well. A number of use cases (with a focus on the happy day scenario's) was committed to by the team after estimation (in a story points like approach) and delivered a month later. Lot's of work was accomplished due to a fair amount of flexibility and negotiation space. This approach worked well with the small team. The lesson learned from this project was that building your own process supporting tool should be eliminated. It's never done and the process is more flexible than your homebrew tool. The positive aspect was that the team was thinking about how to make progress and manage that, before the project. That was absolutely worth a few days! The attitude to perform can't be bought, but can be created. We did that while not being consciously doing that. Looking back that's a nice lesson learned.

Pivotal tracker

During an other project I did in 2009, we used an early version of Pivotal Tracker (very stable and still free in those days). That was one of the easiest and -actually supporting- tools I used for Scrum. Just define your backlog, choose a sprint length, estimate your velocity and the tool helps you to do your sprints and project. That's the nutshell summary. I found it the easiest tool to use and we were able to import/export our stories (which is not always possible in other tools). And all kind of littele smart but very usefull features will be discovered in the first period of use. Great! From a information radiator perspective it's still not good enough for me. But for distributed teams I would say it's very recommended. I saw that they host public projects for free. I was very surprised by the number of public projects running and how active some are. If you have nothing to hide or keep secret, try it!

Conclusion

My conclusion is easy. Scrum is about openness and clarity. The physical boards helped me best to manage the progress and visibility was never an issue. In 5 minutes you can explain nearly everybody how the board works, easy. The openness of a physical taskboard gives a Product Owner or customer also confidence that the reports are based on actual progress.

So what's the good thing of having a taskboards with super sticky notes?

• Very visible
• Hiding work is hard
• Team peers see easy what's being worked on
• Updating is easy, add or remove a note or adjust the estimate
• Not closing Tasks and Stories is visible (no change on the board) and results in actions to solve that
• Closing Stories is very visible and gives team satisfaction (and PO/customer of course)
• I used Task notes and Story notes and wrote on all related ones the UserStory number/id. A Task without a number is clearly not 1:1 related to a UserStory (and not allowed)
• WIP/Work in progress can be limited easier due to visibility
• ... and more

If the team is distributed, things change. Then use a tool to support the distributed nature.

If the team is most of the time on the same location I managed it by sending pictures to the team members working remotely. Make sure you have a compact camera available which makes good readable pictures of a set of sticky notes. A smart phone could work but I have better experience with camera's.

Happy Scrumming!

<<