There seems to be hundreds of agile planning tools out there, but in my most recent project we found ourselves using Google drive for more and more of our planning. It started out with using a Google spreadsheet to keep track of those final, small bugs that always seem to appear at the end of a sprint. Before we knew it we had moved all of our planning to Google drive.
The team consisted of 10-15 people: developers, testers and scrum masters. We were all working on one big project for the Swedish Transport Administration. The last few months we were handing over the project to another team on a different location, working as two distributed teams with 4-8 people in each team having to access the same backlog. Before using Google drive we had the traditional analog scrum board with post-its for the sprint backlog and KanbanFlow for the backlog.
Using Google spreadsheets for agile planning was a good experiment and as such it came with some good parts and some bad. What was the appeal then? Well it’s very easy getting started, anyone with a Google account can create a document and share it. It’s also very flexible, you can have whichever columns you want to keep track of your PBIs and bugs through your process.
At the end of the project our structure, or workflow, in Google drive looked like this:
We had one spreadsheet per sprint and one for the backlog.
The main backlog had the following tabs:
- One tab for new PBIs/bugs, which were discussed with PO and team before moved to the backlog tab
- One tab for the backlog
- One tab for epics (typically PBIs that would require more than one sprint to be finished)
- One tab for questions (that could wait to next meeting with PO)
- And two different tabs for tasks that mostly concerned POs, things they needed to sort out before the team could handle them.
It looked something like this:
Every sprint backlog had four tabs:
- To Do
- In Progress
In the picture below you can see the columns for the sprint backlog. The Backlog tab in the Backlog document had the same structure and that’s where the id came from (which we created manually by just increasing the numbers for new rows).
Most agile planning tools have some of these columns and stages for the workflow, but we haven’t really found any that supports all of the above in a convenient matter for our workflow.
I already mentioned two benefits of using Google spreadsheets: the ease of getting started and the flexibility it offers. It’s also cheap (free actually) and requires very little administration when you want to add new team members or invite product owners to access the backlog.
If you need any other kind of documents for your project it’s very easy to add them in the same folder where you already have your backlog and sprint backlogs, everything is in the same place.
Adding new stages in the workflow is as easy as adding a new tab to your document. Adding new columns takes a little more effort since you have to do the same thing to every tab, but it doesn’t take more than a couple of minutes. If you want to, you can use colors to visualize certain things, like making a PBI red if it’s blocked, green when the bug is corrected etc. Just make sure everybody understands what the colors stand for (we had an inflation in colors after a while, making it more confusing than helping).
The learning curve for already experienced computer users is practically non-existent, if you have used a spreadsheet of any kind and know how to cut and paste you’re ready to rock and roll!
What are the drawbacks then? This seems to be the most wonderful planning tool ever, right? Well we thought so too, at first, but there are things not working as smoothly.
It turns out not everybody is as comfortable with cutting and pasting in spreadsheets as you would hope, which makes it a bit cumbersome in the sprint planning meetings. It also exposed the risk of creating duplicates when moving a PBI from one sheet to another, since it doesn’t actually cut the old row when cutting and pasting in different sheets. It requires some discipline to follow the intended workflow, the tool doesn’t give any guidance on the intended workflow for a single PBI. That’s the downside of all that flexibility. But these things could be handled relatively easy with some practice and by talking in the team about how we wanted to work.
What was more of a problem was finding a particular PBI you were looking for, especially after a few sprints when we had a handful of different spreadsheets. I knew that PBI was somewhere, but I had to search every single tab in the documents to find it, and oh – did I spell it right…?
There were no way of getting a good overview of things, since everything was in different documents and different tabs. What if I want to see everything that’s in progress or in test for this particular sprint? Or everything left in “to do” at the end of the sprint together with what’s in the backlog? There’s really no simple way of doing that.
If you need to write a more lengthy description of a PBI or bug it takes up a lot of space in the spreadsheet. And where do you put screenshots? There’s no support for adding additional information in a convenient way. We didn’t suffer from this very often, but when we did it really hurt! Pasting screenshots in spreadsheets is possible, but after a while you have no idea to which PBI they belong. And scrolling through a spreadsheet where the description of every other row takes up the whole screen? Just try it, I dare you!
The final verdict on Google spreadsheets as an agile planning tool is that it works okay. It offers great flexibility which seems hard to find in other tools that are made especially for agile planning. I believe that in larger projects you’re going to feel the drawbacks pretty quickly, they seem to increase exponentially with number of PBIs and sprints. Small projects could probably do just fine with Google spreadsheets, especially if you don’t feel the need for lengthier descriptions or attaching files to your PBIs.