Agile Project Planning

Agile Project Planning with Google Docs

Like a favorite pair of sneakers or an ideal life partner, I’ve been falling increasingly in love with Google as time passes. From my new Android phone to the recent improvements in Google Maps, the world seems to agree that they’re a company still on the rise.

Over the past few years, I’ve also been using Google Spreadsheet (part of the Google Docs family) as my project management tool of choice. It’s quick, simple, and particularly useful for sharing project status with geographically distributed teams, which is becoming more and more important in today’s global workforce.

Here are a few more benefits:

  • Much of the common Microsoft Excel functionality is mirrored in the Google Spreadsheets. If you know how to use Excel, you already know how to use Google Spreadsheets.
  • Very flexible in terms of visual formatting options (fonts, colors, row/column sizes, etc…). It will probably do anything that you need.
  • Changes and user actions are shown in real-time. When holding web conferences, all users can see as other members select and edit cells.
  • Built-in version control.
  • Built-in user permissioning. This allows you to give read/write access to specific users.
  • Does not require users to download and install plugins*.
  • Mobile friendly, and now available for offline editing.
  • And, of course, it’s free. You can start using it as a proof of concept and explore its benefits/limitations before investing in a paid tool that might fit your needs more specifically.

So let’s dig into some specifics of using the tool for Agile project management.

The following is a template that I’ve been developing over the years for both high-level and detailed Agile project management. Please feel free to use it for your own purposes.
https://docs.google.com/spreadsheet/ccc?key=0Ajmbl4dL3LJ-dGluZUFvT0IzRDJHdWF3RnBZQkZ2Mnc#gid=12

The template contains 2 sheets:

  1. Project Overview – Can be used for high-level planning and reporting of tasks.
  2. Individual Sprint Planning – This can be used for detailed day-to-day task management (ie. daily scrums). It contains a task list with estimates, a daily planner, and burn-down chart.

Project Overview

The first sheet, Project Overview, is a basic Gantt chart with the x-axis displaying the project timeline in quarters, project week number (week 1-n) and calendar week (ie. week of May 5, 2014). Project activities are listed vertically on the page and may be further categorized into sprints and sub-categories. Length and status of each activity is represented by the colored cells – green for “completed”, yellow for “in progress”, and blue for “planned”. Unfortunately, I haven’t linked this sheet to the remaining sheets, I might tackle that in a subsequent update.

Agile Project Plan Overview

Sprint Planning

The second sheet contains three parts that are linked and work together. This is the sheet that you can use for daily task management and stand-up scrums.

Agile Project Plan Daily Planning

The first table (Task Estimation) is the task list with time estimates for each task. In an Agile environment, you might collect these from each responsible team member by using the planning poker method for task estimation. We would typically anchor each task to a specific wireframe (Wireframe ID column) or perhaps a numbered visual design.

The second table (Daily Planning) shows the daily work planned for the life of the project. Day/dates are listed vertically, and the total estimated hours for the project is taken from the sum of all tasks in the previous table. Estimating the hours in the “Daily Work > Planned” column is a tricky art – it must take into account how much time your resources are dedicating to this project vs. other responsibilities, vacations/holidays, and how many productive hours each person has in the work day. For the latter, we would typically assume 5 hours (in a typical work day of 8 hours, we allocated 3 hours for resources checking email, watching YouTube videos of bears falling out of trees, etc…)

The Burn Down chart at the bottom of the page is automatically generated from the Daily Planning table. The graph follows the planned remaining hours in the project vs. the actual remaining hours in the project. The closer the two lines are to each other, the more accurately you have planned.

So that’s it! Hope these templates can be useful for your future projects, and let me know if you have any questions.

– Charles


* This attribute is actually quite important – I can’t begin to estimate how much time we’ve lost and frustration caused over the years trying to get screen-sharing apps like GoToMeeting, WebEx, etc… to work on everyone’s computers, some with slow internet connections, company firewalls, lack of administrative rights for plugin installation, etc… With Google docs, you can simply have a phone conference and collaborate white-board-style using nothing but your browser.

8 replies
  1. Dahlia BERISTAIN GIL
    Dahlia BERISTAIN GIL says:

    Thank you so much for sharing this template!
    We need more people willing to share their good practices with the community.

    Kind regards from Montréal!

  2. Kaustubh Vaidya
    Kaustubh Vaidya says:

    Hey very good article, this is exactly what I have been looking for. Thanks a lot for sharing.

  3. eg0maniac
    eg0maniac says:

    I have a question please.. what is the definition of a sprint as per the gantt chart? I was under the impression a sprint encapsulates a set of deliverables to be submitted within a certain timeframe like ranging from a week to a month..

    • Charles Shimooka
      Charles Shimooka says:

      Thanks for the comment eg0maniac. In the chart, the sprint can encapsulate any time period that your organization uses. In scrum, teams generally use a fixed delivery cycle, typically around 2 weeks. In my previous company, we didn’t have a fixed delivery cycle – I believe this is called “Kanban” methodology. So we would define a set of requirements or functionality into a sprint and it would get done when it would get done. We purposefully did not promise a specified delivery date. It was a hard transition for stakeholders initially, but we won them over when they saw that we were producing things constantly and at a faster rate than before. Hope this answers your question.

Comments are closed.