Scrum uses this term “backlog” – it has product backlogs and sprint backlogs and sometimes even technical backlogs – and the term really just means “a list of work”. In common usage (i.e. outside of scrum) I think of a backlog as a bunch of stuff that you should have done already but haven’t gotten around to yet. For instance “due to a computer problem, there is a considerable backlog at the airline checkin desk”. So the term “backlog” can be slightly confusing, but as long as you think of “a list of work” then you’ll be fine.
Now the product backlog is really just a list of work that could be done on the product (where “product” equals “your software project”). When the team does a sprint planning meeting, then they will take pick items from the product backlog and work out how they can deliver them.
Prioritisation and ordering
It’s a pretty well-established fact that developers can get side-tracked into building frameworks when they should be delivering application. In order to reduce this risk, scrum allows the product owner to exert some control over which items the team choose for their sprint by ordering the product backlog a way that highlights what needs to be done first. This helps the team to focus on the most important aspects and it tries to ensure that they don’t get side-tracked into doing areas that they think are cool but deliver little business value.
One of the most common scrum problems is a poorly ordered backlog. This typically results in the product owner get annoyed with the team because they aren’t focussing on the important items. Conversely, the team tend to get frustrated and disheartened because their work never seems to be appreciated.
What does a product backlog item look like?
Scrum leaves wide open the question about what exactly constitutes a backlog item, but it’s becoming common to make use of user stories. These are short sentences that express what needs doing, the benefit of the new functionality and which types of user will be interested in it.
Does a product backlog item need a lot of detail?
Now user stories are great, and a well-written one can express a lot, but fundamentally they are just a single sentence. And a single sentence is invariably too limited to fully express a piece of functionality. As a result, the user story should be beefed up with some extra detail. This extra detail can take the form of acceptance criteria, wireframes, screen mockups, additional descriptions or whatever. This detail should be captured in the product backlog and stored against the product backlog item.
It’s important, however, to bear in mind one of the agile principles:
What this means with regards to product backlog items, is that you should try to have just enough detail. Aiming to have loads of detail for each product backlog item is to miss the point.
What happens if there isn’t enough detail on a product backlog item?
This becomes an issue when the team tries to plan a product backlog item into a sprint and simply gets stuck because they don’t know what to do. The best way to deal with this situation is to actually talk to the product owner (get them into the sprint planning meeting) and have them explain. The additional can be captured if you like, but the important point is that the team should then be clear on what needs doing.
If the product owner is not available (a sad situation that happens all too often) then the team have a difficult choice. They can either put off developing the functionality which they have been told is important, or they can make some assumptions about what needs doing. Neither of these results is ideal.
To try and avoid this situation, the scrum master should be proactive and should be trying to get enough detail on upcoming stories before the sprint planning meeting starts.
Items get added to the backlog by the product owner
One of the great features of a product backlog, is that adding an item on it does not actually constitute a commitment to delivering that item. After all, the product backlog is the list of work that could be done on the product. Whether or not a given backlog item gets delivered depends on the prioritisation process.
Items get taken off the backlog by the team
Once a product backlog item is planned into a sprint, then it gets removed from the product backlog.
Product backlog items can get modified by the product owner at any time
The product owner is free to adjust any of the items on the product backlog at any time. He / she can remove items, change them and adjust prioritisation at any time. None of this will affect the team’s current sprint, because the items that they are currently developing have been removed from the product backlog. Instead, these changes will be taken in consideration by the team at their next sprint planning meeting.
It’s worth remembering that scrum does not actually give the product owner the ability to change product backlog items once the team has planned them into a sprint. The product owner can call an abnormal sprint termination, but this is not the same as changing the description of an in-progress piece of work.
Storing the product backlog
Excel (or even Word) can be used for holding the product backlog, and there are a variety of commercial products out there which claim to make life easier. The important thing to bear in mind is that, as with any software tool, the tool must fit the process. This means that the product backlog must be easy to access and read, however it’s stored.
Predicting delivery progress
This will be the subject of a number of future posts. Suffice it to say, that it is possible to make predictions about when the items on the product backlog will get delivered by the team. Concepts such as story pointing, team velocity and release planning are relevant. Of course all such predictions are subject to change … after all, this is an agile process we are talking about!