Agile planning with Google spreadsheets

with 3 Comments

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:

Backlog

 

Every sprint backlog had four tabs:

  • To Do
  • In Progress
  • Test
  • Done

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).

 

sprintbacklog

 

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.

 

The good

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!

 

The bad

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 verdict

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.

Follow Maria Eriksson:

Latest posts from

3 Responses

  1. Johan Classon
    | Reply

    Since I heard about that your team was planning in i a spreadsheet (!) I have been curious about how it worked out… To me, it sounds nice to have a tool that can be easily customized to fit the team workflow, rather than have to be forced to do the opposite. Thank you for your insights!

  2. Anders Sahlin
    | Reply

    Great post!
    I agree that the lack of an overview is a problem. When we started using spreadsheets for planning it was contained in a few, three at most, tabs which kept it manageable. Perhaps in combination with another tool for long term planning with better search capabilities, a spreadsheet could be used for the “quick and dirty” day-to-day use in a distributed team.

    A solution for the “attachment” problem could be that you upload the screenshot / lengthy description to Drive, get a shortened URL to the uploaded asset and then paste that URL in the PBI row instead. Not the best if you want a quick glance at something but better for the purpose of a good overview.

  3. Andrei Nistor
    | Reply

    This was a simple, yet powerful blog post, as I see it.
    It gave me an idea what to use when starting a new project and all the “tool setup” is in progress. You guess it: office live from Microsoft, because we use this online set of office tools :)

    Best of wishes from Romania!

Leave a Reply