Jan

2

Agile Concept of the Week: Backlog

Posted by Keith McMillan

January 2, 2013 | Leave a Comment

Agile practitioners like to use lightweight project management approaches. We still need a way to keep track of what needs to happen, even if we don’t use a Microsoft Project plan.  One approach, favored by Scrum practitioners, is the backlog. So what’s a backlog? Is there more than one type? And what goes in them?A backlog is simply a list, in order by business value, of the things that the team is going to work on. The things may be user stories (a topic for another post), use cases, bugs, or whatever makes sense as a logical unit of work for the team. Some teams even go so far as to call them Product Backlog Items (PBIs for short), just to maximize the non-specificness.

There are different types of backlogs, and not all teams use all types. Most teams will use a product backlog, which contains all the items the team will work on. For most teams, this backlog also contains items that the team will not have time to get to, which is why the ordering by business value is important: we want to work on the items with the biggest payoff first. If we don’t get to the lower business value items, then we’ve delivered the best value for the organization given the time and resources we had.

Incidentally, I prefer the non-standard term “project backlog” rather than “product backlog,” because a product has lifespan that’s longer than a project. Your mileage may vary…

Another type of backlog is a sprint backlog, which contains all the items the team has committed to complete during the current sprint. If you’re not working with sprints (such as if you’re using some variety of Kanban) you might not have a sprint backlog at all. You’ll notice I said “complete.” It’s important, that the item in the backlog have a definite way of evaluating it’s “done-ness,” I’ll talk more about that in a bit.

Another form of backlog that’s used less frequently is the release backlog. This backlog is used to keep track of all the items for a given release. This backlog fits between the product backlog and the sprint backlog, if your project has multiple releases in mind.

As I mentioned earlier, it’s important that your items in your backlog have a definite “done-ness” to them. I’ve seen teams get into trouble when they have a backlog item that can’t be completed before the end of the project. They need something to keep track of every sprint, but they repeat that activity every sprint. For example, if you want to do a code review for the team, you might have a generic backlog item “perform code review,” but you’re going to do that every sprint, maybe for each story. We want our sprint backlogs to be empty at the end of the sprint, but we’re going to need to do code reviews next sprint too…

I encourage teams encountering these sorts of backlog items to think of them not as items to be included in the sprint backlog, but as “generators” of items that go in the sprint backlog. Thus, “perform code review” in the sprint 3 backlog becomes “perform code review for code changed in sprint 3.” This allows us to treat the sprint backlog as something that can be emptied every sprint.

Emptying the sprint backlog is a good practice for a number of reasons: it provides us with a better measurement of what the team can accomplish in a sprint; it allows the team a sense of accomplishment; it highlights where we are having problems (the items that aren’t getting completed).

 


Comments

RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll