Scrum is one of the most popular methods of Agile web development in practice today. Scrum focuses on breaking down a project into small pieces, called stories, that can be designed and developed in short iterations, called sprints. To manage this process, Scrum uses multiple backlogs to keep all of the stories organized. Each backlog is a bucket where we place stories that might be developed at some point in the future. We want to move stories from backlog to backlog, with the end goal being for the story to end up in a sprint. This short tutorial will demonstrate how to manage Scrum backlogs using online task management software.
Note: To illustrate the process of creating and managing Scrum backlogs, we’ll be using our online task management software, Intervals. If you’d like to follow along, sign up for a free 30 day trial.
Defining the Scrum Backlogs
To get started we’ll need to create the backlogs. The above diagram shows the backlogs for flowing stories from beginning to end — the product backlog, bugs backlog, and sprint backlog. Each of these backlogs contains stories at different times in their life cycle, from inception to completion.
- Product Backlog
The default backlog where every story starts out. When we do our sprint planning meetings, we’ll be pulling stories out of the product backlog. - Bugs Backlog
Bugs are the inevitable byproduct of any software development process, including Agile. They get their own backlog so we can keep track of our bug count over time. The best way to keep our bug count down is to pull a few stories from the bugs backlog into each sprint. - Sprint Backlog
This contains every story we should be working on in the here and now. The daily Scrum meeting and all of our team’s design and development efforts are focused on the sprint backlog. Our goal is to complete all of these stories by the end of the sprint.
Creating the backlogs
Intervals is a task management application that does not subscribe to any particular method of project management. It’s flexibility is what allows us to use it for Scrum in this tutorial, or any other Agile or waterfall project management style for that matter. The only caveat, and this is going to be true for any task management tool we use for Agile, is that the labels are not going to be specific to the methodology of our choice. We’ll be using Modules as Backlogs, Milestones as Sprints, Tasks as Stories, and Summaries as User Stories. The labels are different, but the concepts are the same.
To set up our backlogs in Intervals, we create them as Default Modules (Found by navigating to Options -> Settings & Defaults).
Adding stories to the Product and Bugs Backlogs
Each story is synonymous with a task in Intervals. To create the task we edit just the fields required to put this story into the Product Backlog, where we can leave it until we are ready to pull it into a sprint. For the Module field we select “Product Backlog.” If this story happens to be a bug, we’ll select “Bugs Backlog” instead. The other fields depend on how you want to further classify the story. Status can be used to denote whether or not any work has been done on it, and the priority helps the Scrum team prioritize what they pull into future sprints. And finally, the Summary field is where we enter the User Story.
To create a new story in Intervals, we create it as a task by clicking on “Create a new task.”
Planning the Sprint Backlog
When it comes time to move a story into the Sprint Backlog (most likely during a sprint planning meeting), there are three steps we need to complete. First, we move it to the Sprint Backlog module. Second, we estimate the number of points, or hours, to complete the story. And thirdly, we move the story into a milestone so we can track our velocity and burndown rate.
During the sprint planning the team will go through the list of tasks in the Product and Bugs Backlogs. The task listing in Intervals is an ideal interface for this meeting because of its search, sort and filtering capabilities. To begin, we filter the task list on the Product Backlog module and start selecting tasks for inclusion into the sprint. If we’ve already estimated points for stories in the backlog, we can sort on the Estimate column to collect stories of a certain point size. If we are planning our sprint based on a theme, we can use the search functionality to locate stories in the Product Backlog that meet our criteria.
To move the task into the sprint, we simply update the task, changing the Module to Sprint Backlog, the Hours Estimated to the number of points, and the Milestone to the sprint we created for this project. Click save and the story now resides in our current sprint.
Now that the story is part of a Milestone, we can log in to Intervals to monitor progress on the sprint. The milestone page will show us two important bits of data. The Time Remaining field is roughly equivalent to our burndown. It shows how many points are left in the sprint. The Actual Time field shows us how many points have been completed thus far. Points completed are calculated using time tracking data. As our team works their way through stories they track their time. This data not only gives us burndown rates, it also gives us an accurate measure of our velocity for future sprint planning.
As our stories go through their life cycle, they are eventually marked as being done. The way we do this in Intervals is we update the task and set the status to Closed. The sprint is considered finished when the milestone shows all of it’s tasks having been closed. Depending on how our team works on each story, the corresponding tasks will go through various status updates. The milestone view in Intervals shows us a pie chart comprised the number of tasks by status (Note: We will be replacing this pie chart with a bar graph soon to make it more Kanban-esque).
By grouping all of our tasks into one milestone, Intervals provides us with a refined work space and the tools we need to work through each story and complete the sprint. We are able to query useful information, such as how many stories are completed, how many points are left, and how many days are left in the sprint. And while we are focused on the current sprint, anything on the periphery is sent to the Product and Bugs Backlogs, to a place where we don’t have to think or worry about them until our next sprint planning.
Conclusion
This tutorial is just one example showing how Intervals can be used as an online task management tool to manage the Agile software development cycle using Scrum principles. You can, and should, remix and adapt our process to dovetail your project management workflow. One of the great things about Agile is that it isn’t rigid. It’s better to bend Agile and do what works for your team, than to bend your team to fit Agile. Your team will snap, Agile won’t.
Actually, a task in Intervals is really not a good counterpart of Scrum user story. A user story, in 99% of the cases, needs to be broken down into several tasks (analyze, code, test, deploy, etc). So, the one best alternative here is to use Milestones as user stories — milestones can be broken up into tasks and each task can be accounted for independently. Milestones in Intervals is the deliverable that Agile teams understand as user stories.
With this in mind, technically, in Intervals a Sprint would need to be carried out as a separate project. A Sprint would have to be represented as a sub-project of a project, or something like that. Maybe you guys can think of adding an explicit “Sprint” option in there somewhere.
Hmm, I guess we can’t really have it all perfect under one roof. I am switching my company to Intervals still, as we are a mixture of Agile and Waterfall for many purposes (development, biz management, etc).
I do like the suggested way of keeping backlogs per projects and I see how it can serve a good purpose… probably even a better alternative to the mechanism that some Agile tools offer (such as Rally, for example).
German,
Thank you for the feedback. Those are all good points. Another way we have seen our Agile customers break down user stories into multiple tasks is to preface the task title with the user story number or name. For example, if the user story was to create a customer login for a web site, the tasks might be:
Customer Login ~ Login Page
Customer Login ~ Forgot Password Feature
Customer Login ~ Lock out failed attempts
BY doing this the tasks for this user story can easily be grouped, search, and sorted in the task list, or in the milestone view. This way the milestone can still be used as a sprint.
One thing we’ve learned about Agile is that it allows for a lot of flexibility. Each team can practice it a different way. Thanks again for the input!
John,
Right… That is a way to accomplish this, but it is taking you, Pelago, back to where you designed the Milestones — to get out of the need to have to use convention by words to group tasks together. :)
In order to pull together a few iterations in one project, one can use the modules, just like you suggest for backlogs. This way, if you have a project ABC and want to split it in backlogs and iterations, you will have modules for backlogs and for, Iteration 1, Iteration 2, etc. All user stories fall under the same project and they get pulled back and forth via modules. Deal solved.
Regards, and keep on keeping it up!
German
German, great insight. Modules are indeed a great way to manage backlogs and treat the current sprint, the release backlog, as just another backlog. It’s great to hear about these different ways our customers are using Intervals to do Agile.