Google Sheets Project Management Tool
Some time ago, I faced the choice of a tool for managing small projects using the SCRUM methodology. I had quite a lot of experience using various tools including Jira, Asana, Trello, etc., but none of them were fully suitable for my project: some was too monstrous, and some lacked features important to me. As a result, I had to invent the tool myself, based on Google Sheets.
The requirements made by me to the instrument were as follows:
Part of the requirements were dictated by the fact that in this project I combined two roles: a product manager and a project manager, so I wanted the time spent on managing the team to be minimal so that there was time for product management.
As a result, it was possible to create a really convenient and satisfying my requirements tool that has stood the test of time, has gone through several modifications and is now ready to tell the public about it. I believe that someone may well find it useful.
The general view of the tool is shown in the screenshot:
The numbers indicate the following main areas:
As mentioned above, one of the requirements for the tool was minimalism, however, the template was designed so that additional columns could be added (for example, a column with a link to a document describing a user story) and nothing would break.
The basic steps of using the tool are described below, all screenshots are clickable.
We open a virgin blank template and begin to fill it with tasks and user-pages. As a result, the sheet will take approximately the following form:
Backlog is prioritized by arranging tasks higher or lower in the list. And here an important point should be noted: Google Sheets, unlike MS Excel, supports dragging and dropping table rows with the usual drag-and-drop: just grab the mouse over the line number and move it where necessary. However, it does not overwrite other lines, but stands between them. Without this feature, nothing would have happened.
Before planning, set the sprint parameters: indicate the number of days (field sprint days), and also indicate the working days of the sprint in the table header. Initially, there was an idea to make dates stamped automatically, however, in the end I came to the conclusion that it’s easier to fill it out manually and not to worry about processing public holidays, corporate events, etc.
At planning, we evaluate and decompose tasks, assign them to performers and drag them to the sprint backlog, where we control the loading of each performer.
Here it is necessary to make a couple of explanations:
At the end of the working day, each developer puts down the number of hours remaining for each of their tasks. When the task is completed - set to zero. Based on these data, a burndown chart is built. In my opinion, this is the optimal type of reporting: it does not require much time and allows you to significantly more accurately assess the progress of sprint implementation compared to when burndown is built on closed tasks.
I would also like to draw attention to the convenience of monitoring the relevance of the data: just one glance is enough to understand for what tasks the developers set the clock and for which they forgot.
When the sprint is over, we begin planning a new sprint. For this:
Then we repeat all those actions that were described in the "Planning" section.
The approach with copying sheets minimizes manual labor and preserves the history of all previous sprints: sometimes it is useful to see what happened a couple of sprints back to us.
But what about testing? - you ask. Testing was organized as follows: we just created another clean sheet where all the bugs found were entered. And then we either fixed them within the current sprint, or entered them in the backlog of the project and planned their implementation along with the usual tasks in the following sprints.
You can download the template here . It is completely ready for use: just save a copy and start using it.
Just in case: of course, I do not urge everyone to quit and switch to project management using Google Sheets. However, life is a diverse thing, and it is quite possible that someone will meet with a project for which this tool will be the best choice.
The requirements made by me to the instrument were as follows:
- Low time-consuming use: entering a new task, prioritizing a backlog or changing the status of a task should take a minimum amount of time.
- Low entry threshold for all process participants.
- Visibility and minimalism: I wanted to see backlog, sprint tasks, and current progress on one screen. And while not seeing anything superfluous.
- Build a burndown chart, moreover, by hours (remaining work), and not by closed tasks.
- Possibility of clear and convenient control: whether all the hours are affixed, whether all the statuses are updated.
Part of the requirements were dictated by the fact that in this project I combined two roles: a product manager and a project manager, so I wanted the time spent on managing the team to be minimal so that there was time for product management.
As a result, it was possible to create a really convenient and satisfying my requirements tool that has stood the test of time, has gone through several modifications and is now ready to tell the public about it. I believe that someone may well find it useful.
General form
The general view of the tool is shown in the screenshot:
The numbers indicate the following main areas:
- Product backlog
- Sprint backlog
- Remaining hours for tasks
- Burndown chart
As mentioned above, one of the requirements for the tool was minimalism, however, the template was designed so that additional columns could be added (for example, a column with a link to a document describing a user story) and nothing would break.
How to use it
The basic steps of using the tool are described below, all screenshots are clickable.
The start of the project. Fill backlog
We open a virgin blank template and begin to fill it with tasks and user-pages. As a result, the sheet will take approximately the following form:
Backlog is prioritized by arranging tasks higher or lower in the list. And here an important point should be noted: Google Sheets, unlike MS Excel, supports dragging and dropping table rows with the usual drag-and-drop: just grab the mouse over the line number and move it where necessary. However, it does not overwrite other lines, but stands between them. Without this feature, nothing would have happened.
Planning
Before planning, set the sprint parameters: indicate the number of days (field sprint days), and also indicate the working days of the sprint in the table header. Initially, there was an idea to make dates stamped automatically, however, in the end I came to the conclusion that it’s easier to fill it out manually and not to worry about processing public holidays, corporate events, etc.
At planning, we evaluate and decompose tasks, assign them to performers and drag them to the sprint backlog, where we control the loading of each performer.
Here it is necessary to make a couple of explanations:
- Decomposition of tasks is carried out through a naming convention, when the task and the subtask are separated by a colon: " Task : subtask ".
A variant of the template was implemented, where a special column was selected for the hierarchy, where one could select the root task from the drop-down list (formed automatically from the backlog), but practice has shown that such complication is unnecessary.
- Of course, to control the loading of artists it would be possible to create a separate beautiful schedule, but I did not want to clutter up the interface with a schedule that is needed only once per sprint. Therefore, I settled on the option shown in the screenshot - it turned out to be quite convenient. If there are many tasks and developers, they can be selected using the filter so that it is more convenient to select with the mouse.
Sprint performance and daily reporting
At the end of the working day, each developer puts down the number of hours remaining for each of their tasks. When the task is completed - set to zero. Based on these data, a burndown chart is built. In my opinion, this is the optimal type of reporting: it does not require much time and allows you to significantly more accurately assess the progress of sprint implementation compared to when burndown is built on closed tasks.
I would also like to draw attention to the convenience of monitoring the relevance of the data: just one glance is enough to understand for what tasks the developers set the clock and for which they forgot.
Planning a new sprint
When the sprint is over, we begin planning a new sprint. For this:
- Create a copy of the leaf with the just completed sprint
- Delete all completed tasks from it.
- For unfinished tasks, we transfer the number of remaining hours from the last day of the sprint to the day 0 column.
Then we repeat all those actions that were described in the "Planning" section.
The approach with copying sheets minimizes manual labor and preserves the history of all previous sprints: sometimes it is useful to see what happened a couple of sprints back to us.
About testing
But what about testing? - you ask. Testing was organized as follows: we just created another clean sheet where all the bugs found were entered. And then we either fixed them within the current sprint, or entered them in the backlog of the project and planned their implementation along with the usual tasks in the following sprints.
Instead of a conclusion
You can download the template here . It is completely ready for use: just save a copy and start using it.
Just in case: of course, I do not urge everyone to quit and switch to project management using Google Sheets. However, life is a diverse thing, and it is quite possible that someone will meet with a project for which this tool will be the best choice.
All Articles