Is your backlog still relevant?

 photo loading-652297_1280_zpsmlmpdbv8.jpg

Requirements management is a problem for all fields. It is particularly hard in software where the end product is “soft”.

We have already discussed the dangers of going overboard with scoping and how to work with user stories for more concise and agile requirements. A user story simultaneously deals with the problem of over and underspecification elegantly.

A collection of user stories is organized into a backlog. We have already seen how a backlog looks like

Mike Cohn describes a backlog simply as:

    A prioritized features list, containing short descriptions of all functionality desired in the product.

The short description he is talking about is of course a user story.

Once your initial backlog is written out, your task as the scrum master is to ensure that it remains a valuable asset to the team and not left to atrophy and finally abandoned.

In this entry we shall be looking at some of the questions that you can ask yourself to gauge the health of your backlog.

Is the backlog prioritised?

Scrum is based on the belief that you deliver most value by working first on stories that have the most value to the customer. This is achieved by ensuring all stories are prioritized.

Most teams are disciplined enough to do this the first time the backlog is written. Over time, the order is lost as more stories are added or as change happens and other stories suddenly become more important. This by itself is not a problem, the problem is that the change in priority is not reflected in the backlog.

If this continues long enough, the client then loses faith in the backlog as a tool to express what is important to them.

Is the backlog and its stories easily changeable?

Scrum has no hard specifications on how the backlog will be encoded. It does however have a preference towards a paper based system, only because this kinds are the easiest to change. If a story is no longer useful simply rip it up.

Easily changeable here will depend a lot on context. Putting up your user stories in the middle of say a product strategy document is likely to introduce a lot of drag. Who wants to go through a monstrous document just to change one sentence?

Requiring multiple authorization levels to make changes is also likely to cause the same problem. Rather than go through the hustle of asking for permission, the team member who has noted the change would rather not document it.

Finally using an unnecessarily complex tool is likely to discourage any kind of engagement with it. We all have too much to deal with in our life, taking the time to master a new tool is just not likely to get done.

At this point I must emphasize that change still happens whether your tool accommodates it or not. In the unfortunate case that it does not then it becomes obsolete.

Are the stories estimated?

Estimates are incredibly important to any story and the resulting backlog. Typically estimates are given in story points. A story point is an arbitrary measure of effort required to implement a user story.

By its nature, story point estimation forces you to triangulate story size and have heated discussions with other team members so as to come up with an agreed upon estimate. This process then helps destroy any illusions of agreement that may exist and build alignment.

Eg if there is a story such as “As a new customer I want to be able to register using either my phone number or email” and the developer gives an estimate of 8 while the client gives an estimate of 1. A discussion can ensue upon which the client can understand why this is a hard feature to build and maybe rework it or the developer can see where she misunderstood the client.

Hence, a backlog that lacks this estimates and the discussions associated with them is likely to drift away from the client’s dream both in terms of scope and delivery time.

Are the stories detailed appropriately?

A common mistake I see is teams specifying to great detail work to be done in months or even years time.

Prudent as it may seem, you are likely guessing what is going to happen. Complex systems necessarily arise out of adaptive processes. By the time the months lapse, your story will probably be invalid.

Unfortunately, even when we discover that the story that was written months ago is no longer relevant, if enough effort was put into crafting it, then we will feel guilty about abandoning all that work. Thus the work will continue to stay on the backlog with no chance of ever getting done creating a drag on everyone’s psyche.

How do you keep your backlog relevant? Talk to me in the comment section below or on my twitter @jchex


Published by


Software Project Manager