Agile Software Development

In this tutorial I demonstrate how you can manage your Scrum Product Backlog in a very simple Excel sheet based on a popular free template. Watch this screencast if you want to get started with Scrum. You will see how to get started, how to detail, inject and remove requirements, how to build burndown and velocity charts.

You can download the somewhat lower quality version of the tutorial from Google Video.

One of the mandatory artifacts of the Scrum process is a Product Backlog. In its simplest form it is just a flat list of things to do, quite often even without the complexity estimates. Its power comes from the strict order of elements. Customer can call many requirements equally mandatory or must-have, but in the list there is no way to position two items equally high. As a result a team is able to see the clear focus and sense the current expected direction of the project. Product backlog is not static. It changes over time: coarse grained items from the bottom are divided into smaller stories as team comes closer to them, some items are removed and some are added basing on the increased understanding of the area, technology and the market. Still, at any given point of time well maintained product backlog is the primary tool for communicating the current best understanding of the project direction.

Multiple backlogs for a team

Several times I've seen the situation, when there is no single product backlog for a team, but there are several "area backlogs" from which the top part of a real product backlog is dynamically assembled before or even during the sprint planning. Naturally it happens more often in the situations, when one team has to develop several projects simultaneously or many teams do many projects.