Managing Scrum Backlogs Using Intervals Online Task Management Tools

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.