Backlog pitfalls

I’ve written previously about how you should ensure that the items at the top of your backlog have the following qualities:

• They are small — they can be built quickly
• They are independent — can be deployed on their own, not in a batch
• They add value to the user/organisation

If this is the case, then when the team pulls work bit by bit from the top of the backlog, it won’t be hard for them to put valuable work live at short notice and move on to something new, as well as getting feedback on the work they have done.

However, I’ve seen many teams with backlogs that aren’t structured like this. Here are some of the common issues I’ve seen:

Backlogs of 100s and 100s of tasks

I have come across backlogs that had over 1000 tasks in. This becomes really difficult to manage, by anyone. It often happens when a team treats the backlog as a to do list of tasks — they create a ticket whenever they come across something that could be done, or improved, and then put it in the backlog for later. In reality, as it is so hard to manage, the tasks often just go there to die; it becomes a largely pointless exercise.

Very few of these tasks would independently add value — they often need to be grouped together to be useful. But with so many there, it becomes very hard for anyone to group them and decide what should be done next.

Tasks grouped by type

When a team approaches a big new piece of work, they might decide to group all their tasks by type. They could split them into groups like Front-end styling tasks, Javascript tasks, Back-end API tasks, test automation tasks etc. etc. This might make it easy for a team that has different members with different specialisms, but it often means they are unlikely to be able to deploy anything quickly. The different members will probably get on with their tasks independently, discussing at stand-up which other tasks are blocking them. Not until everyone completes all their tasks (and the extra ones they found along the way) will something be able to go live.

This team isn’t really working together here. Instead, they could group their tasks by outcome — the thing they want to achieve for the user or the organisation. Something that adds value. If they do this, and attack one outcome at a time, then the whole team will be focused on creating something useful. As a result, they will create value a lot more quickly.

Tasks written as user stories

Here’s an example of “user story” I have seen:

As a Product Manager

I want a design for the payment journey

So that a developer can implement it

The user story format is usually used to express the value that the the end user of the feature will get. It explains

• who the user is
• the outcome they desire, and
• why they will benefit from it.

In the example above, this isn’t really being done. This “story” was written because the team had a rule that “all backlog items should be written as user stories”. However, a better rule is that “all backlog items should express the value to the user”, in which case the above wouldn’t be possible. With this rule, the backlog could still be filled with “user stories” (ones that explained the outcome for the end user), and the “design for the payment journey” would be a task that is required to deliver one of these.

Outcomes that are too big

Just having a backlog that is made up of outcomes for the user/organisation is not enough if those outcomes take 2 months to develop. Big features can often be broken down into separate bits that give value to the user. If that isn’t the case, then there is usually a way to break it down to allow some form of testing, whether it be manual QA, integration testing or user testing.

If a user story takes longer than a sprint (if you work in sprints) to be completed, then it is probably a sign that it is too big, and can be broken down to something smaller. If you are taking several months to build something, then you aren’t getting feedback that you are progressing in the right direction.

Stories that can’t be deployed independently

Sometimes this is very hard to avoid, and arguably impossible with a brand new product. However, it is often more possible than people think. It is often possible to “slice” your new feature into smaller features and order them in a way that can be deployed and add a small amount of value on their own.

For example a team was adding a feature to collect a user’s address, using a postcode lookup tool. This involved the user typing the postcode into a field, hitting search, selecting the address, then extra fields would appear with the full address filled in automatically.

Initially the team created the following 2 user stories:

As a user trying to enter my address

I want to search for my postcode

So that I can select my address without having to type it all out

As a user trying to enter my address

I want to edit the output of the postcode lookup

So that I can ensure my address is accurate

If we deploy the first story without the second, then the user would not be able to enter their address if the postcode lookup can’t find the correct one. A Product Manager is unlikely to deploy this on its own, as it could lead to a broken journey for users.

However, we could instead go with:

As a user trying to enter my address

I want to enter my address in editable fields

So that I can submit the correct address

As a user trying to enter my address

I want to search for my postcode

So that I can select my address without having to type it all out

In this version, we can actually deploy one before the other. The user would be able to enter their address, and later we add improved functionality allowing them to do so with less typing. The two approaches actually amount to a very similar amount of work, but with the second approach we can add value to the user earlier and also allows us to pivot on to something else if necessary without wasting any work. The stories are much more independent.

If we can avoid all of these pitfalls then you have a backlog of small, independent items that deliver value to the user/organisation. Now this isn’t always easy, but if you have a backlog like this, then it makes it easy for the team to:

• Build things that can be put into production quickly
• Deploy often
• Pivot quickly to a different direction without wasting work
• Get regular feedback on new features
• Continuously improve the product based on feedback

The above points are all great things to do, and would create a great team with a fantastic agile mindset. However, with an unsuitable backlog these are all quite hard to do.

So get your backlog right, full of small, independent, valuable outcomes, and everything else will follow. Good luck, and let me know if you want help!

If you enjoyed reading please give some 👏 and/or leave a comment. For more stories like this check out my publication, The Agile Mindset.