I’m Not a Fan of Task Boards and Spreadsheets
I’m Not a Fan of Task Boards and Spreadsheets
By Sean McHugh
As a group, we Scrum people seem to have a phobia surrounding Agile and Scrum software solutions. Here’s an example:
“I hate the tools. OK, hate is a strong word, but I’m generally anti-tool when it comes to managing Scrum artifacts and data. I strongly prefer more manual techniques (Scrum Boards, sticky notes, story cards, white boards, wikis, etc).” – Charles Bradley
We tend to view them as too much overhead, needlessly constricting and far too expensive. We then proceed to spend tens of thousands of dollars on Scrum coaching which teach us how to use whiteboards to keep work visible as if walking into another room to move a card involves no overhead. When that’s all done we fire up excel and spend the next two days figuring out how to make it create a burndown chart for management.
Let’s take a moment to talk about two Scrum tools that are really cramping our style: Task boards and spreadsheets.
Why task boards are used
Task boards are great because they are incredibly simple to use, you look at a board and immediately know everything about the current sprint, including the work done, the work in progress and the work left in the queue. It’s also super easy to update the task board, you simply get out of your chair and move a card.
Why task boards suck
Task boards are not very transparent. They’re not transparent because they don’t communicate a thing to anybody outside of the dev room. True, stakeholders can always look at the task board if they can get to physically it. Honestly though, the task board communicates nothing to those who are outside of a certain physical radius from the team.
Task boards are also inflexible. Did you want swim lanes for team members? Groups for high priority features? Where do we put bugs? Better get it right the first time or you’re going to spend quite a bit of time re-taping the board next sprint. You could also have several task boards, one for user stories, another for tasks, and another for epics and themes. I’ve seen these rooms, you don’t want that mess… midway through the sprint it looks like somebody shot an office supply cart with a shotgun.
The picture below is actually a really good and simple board but it’s got some problems:
What if we wanted to do a 6th story during a sprint? What if we had two urgent stories? What if we had a team of 10 instead of 3? What if we had 10 teams of 10 each with the same board, how would we aggregate that information visually to get a sense of overall progress?
The Task board solution
Software task boards work better than physical ones. A software based task board allows the person viewing it to reorganize, filter it and make changes that roll upward to a Scrum of Scrum and/or an overall release. They’re available to anybody with a computer and a login (not just the folks within walking distance of the Scrum room) and they are stupid easy to update.
This is not to say that software task boards aren’t without problems; the format and information in your task board will be limited by the programmers that made it. However, most of the software boards that I’ve seen are pretty flexible.
Why spreadsheets are used
First and foremost, spreadsheets are available. They are like the giant opened bag of Doritos for the corporate world. Leave an opened bag in front of someone long enough and you can bet his or her keyboard is going to be covered in cheese dust sooner or later.
Moreover, you can do anything with a spreadsheet, update this cell with your estimate, change this cell to complete when your done, some spreadsheet tools can even build you a burndown or help you track whatever esoteric metric your boss wants you to report on. There are macros and pivot tables that you can write for your really exotic needs and to share it amongst the whole team and your stake holders all you have to do is drop it on the most convenient shared drive.
Why spreadsheets suck
Spreadsheets are a little bit like pictures of children. So long as it’s your own creation, you think it looks great and you’re only too proud to show everyone else. The problem comes when the spreadsheet is not of your own design. Usually, these things are hard to read, hard to update, are overly complex and take forever to set up.
It gets more complicated when you have multiple teams and multiple scrum masters. Each scrum master will have their own spreadsheet, which they will have to update their team spreadsheet in addition to the overall spreadsheet tracking all teams. In my experience, this almost always ends with a scrum master who spends their whole day updating and tweaking and reporting off of the spreadsheet. If you’re a good scrum master you should most certainly be spending your time in places other than excel.
The spreadsheet solution
There’s no such thing as a feature-rich spreadsheet. You need a database for a flexible dataset and a front-end for ease of use, both of which typically mean a feature-rich software solution of some type. In my mind, feature rich means custom fields, custom workflows and reporting, automatic burndown charts and a polished front-end. Feature rich also means that you’ll want to spend a day or two getting familiar with the front-end so that you can iterate and improve between sprints. Most of these software solutions (with a couple exceptions) make changes easy to get done.
Final thoughts
Any time we enforce process there’s going to be an overhead cost associated with it. There are no perfect solutions, but I like good software. They’re easy to set up, feature rich and very powerful. I think we’re sometimes afraid of these tools because of the ways they’ve been misused in the past. These are professional tools and they are capable of allowing you to make bad decisions if you ask them to. Being Agile ultimately benefits you more than adopting any type of tool but a good tool can help you be more Agile if you use it right.
Sean McHugh is one of the Scrum Masters at Axosoft, whose flagship product is the OnTime Dev Suite. He provides help to new and experienced agile teams from around the world who are beginning to implement an agile project management software solution for their development teams. You can read more posts by Sean at Axosoft’s blog.
