Scrum is an iterative approach to collaboration and software development, but you’ve got to start somewhere. In this post, we outline how to create a list of new features or improvements - a product backlog in Scrum terminology.
The Scrum framework all hangs on the product backlog - a list of features drawn up by the person (or people) who will eventually put the developed software in to use. This article guides you through how to create a product backlog in Google Documents.
There are numerous ways of storing a product backlog (from pen and paper to dedicated full blown applications), but let’s start simple. An online spreadsheet is available to all with a browser, and can be viewed and edited by multiple people at once. We also get version control for free. So let’s get started.
Backlogs explained
In The Scrum Book, a product backlog is defined as:
an evolving, prioritised view of business and technical functionality that needs to be developed into a system
A product backlog pulls together an ordered list of requirements which are ‘queued’ to get rolled into the software in the future. The list can be reordered and edited as necessary, which ensures that the rapidly changing nature of research can be easily mapped to the backlog. Before each development cycle, the most important of these items are selected and implemented within a relatively short time frame.
Once the product backlog has been built, a project leader can meet with the development team to decide which items will be included in the next development cycle (often referred to as a sprint).
What makes up a product backlog?
In short - stories.
Stories are short vignettes describing how the project leader would like the software to operate. They are non-technical, and written from the point of view of the project. For example, if we are thinking of a patient management system, the following stories would be likely:
All patient records should be unavailable until the user’s hospital staff number and ward code have been verified.
Once verified, the staff member should only be able to edit their own patient’s records.
All staff should be able to look up drug names in an online pharmacopedia.
In addition to these stories, the development team may add some additional ‘tech stories’, which are usually more along the lines of setting up servers, or stress testing systems.
Once the stories have been written, they should be ranked in order of importance by scoring each story with an ‘importance’ value. These values don’t need to be sequential, or even within the same order of magnitude. Indeed, it may help if they are not when planning what shoud be included in the next development sprint. Ideally, all the important stories should have unique values.
Looking again at our patient management example:
All patient records should be unavailable until the user’s hospital staff number and ward code have been verified. Importance: 1000
Once verified, the staff member should only be able to edit their own patient’s records. Importance: 500
All staff should be able to look up drug names in an online pharmacopedia. Importance: 10
With a few more stories, we’ll have enough information to start building a prioritised short list for the sprint. Ideally, product backlogs should contain as many items as necessary - don’t stop at the number you think the developers will be able to handle within the time frame of the sprint.
What happens next
Once the project leader is happy with the backlog, they and the development team meet to create a sprint backlog of items to be worked on (in order of priority) by the developers.
During a sprint
Although the product backlog can be updated at any point, the items marked for development during the next sprint can not be altered once the sprint has started. This is to ensure that the developers can work unimpeded by changing scope, altered priorities and moving targets. Newly important items on the product backlog can be scheduled for the next sprint, but cannot be inserted into one that has already started.
The Spreadsheet
As we mentioned earlier, an online spreadsheet is a good place to start putting a backlog together. We’ll use the Google Documents spreadsheet. You’ll need a Google account to sign in and get started.
Once logged in, create a new Spreadsheet by clicking on New → Spreadsheet. An empty spreadsheet will open in a new window.
Go ahead and create three columns, adjusting the columns as necessary.
| Name | Description | Importance |
Save the spreadsheet by going to File → Save, and then start adding some stories!
| Name | Description | Importance |
| Staff verification | All patient records should be unavailable until the user’s hospital staff number and ward code have been verified. | 1000 |
| Read only access | Once verified, the staff member should only be able to edit their own patient’s records. | 500 |
| Drug name look up | All staff should be able to look up drug names in an online pharmacopedia | 10 |
Continue until you have the makings of a fine backlog. Should others want to contribute, you can share the spreadsheet by clicking on the Share tab.
Finally
The product backlog is the starting point of the Scrum process, but can be kept up to date with changing needs as they occur. The next step is to meet with the development team and plan the sprint, which is the topic of another post.
