Managing a clean and useful backlog

For the first time I inherited a backlog that left me completely speechless, and not in a good way. I have managed multiple backlogs over the last 8 years but I have never seen so many anti-patterns of backlog management and story writing in a single backlog.

This post talks about the learnings over the last 8 years and ‘what not to do’ when it comes to managing backlog.

Treat epics as large user stories and NOT as buckets of things

Epics are just ‘large’ user stories that need to be broken down. One of the reasons product teams end up with very large and never ending backlogs is because they think of epics as a way “categorising things or as buckets of stories”.

Instead…

• Define Epics in the form of user stories. This way everyone in the team and outside the team is clear on the ‘what, why and the boundary’ of the epic. Figure 2 below shows an example of how I usually describe epics. The acceptance criteria describes a high-level scope for this epic. Whereas ‘value delivered and impact of not doing an epic’ allows the PO and stakeholders to communicate the priority and urgency around the epic. Depending on your stakeholders you could also add a section of ‘not in scope’ to explicitly state what will NOT be part of this epic to avoid any grey areas.

Figure 1: An example of the description of an Epic

• Only tag those stories that relate directly to the ACs of a given epic. New stories will be elicited throughout the life of the product. If you keep tagging new stories to a single over-arching “bucket” then a given epic will never be ‘done’. Figure 2 is an example of one of the epics I inherited. To find a story in this epic I have to resort to using Cmd+F. The management of this epic will become an overhead as compared to the epic in Figure 1. A lot of these stories in Figure 2 below will never be done because they are ‘nice to have’ yet they will remain tagged to this epic and the epic itself will never be completed. Ideally we want to aim to complete an Epic within a few sprints time.

Figure 2: Intentionally blurred image of 43 user-stories linked to a single epic

• Track value delivered by a given Epic so you can trace it back to your roadmap and KPIs. Each epic will serve a purpose and when that purpose is met, you can simple close the epic and claim the value delivered. This also helps in maintaining a cleaner backlog and reporting on completion becomes much easier.

Add enough detail to your user stories

We all know that user-stories should be treated as a commitment to communicate. A card should be talked about with the team and together a solution should be defined. However, this should not negate the need to document the outcome of that conversation and have a well structured and bounded acceptance criteria. This should also not negate the need to elaborate the user story by attaching additional information such as — journey flows, technical discussions, how-tos, designs, understanding of where the story sits within the wider flow, possible test cases/ scenarios etc.

Figure 3 below shows an example of how user-stories were defined in the inherited backlog. There are some obvious things missing here:

• Value statement is missing.
• The description is the same as acceptance criteria.
• There is no clarity on — where the said event is occurring, who is initiating the event, is printing the only outcome of this action, what if the action fails, what does the outcome look like etc.
• Story is just too small and vague. The backlog contained a lot of such small user stories which ended up creating a ton of inter-dependencies in an extremely long backlog.

I am sure that the team spoke about this ticket at the time and the above questions were answered. However there is no record of this conversation or a retrospective update to the user story. Wanting to keep the backlog lean does not translate into vague user stories.

Figure 3: Intentionally blurred image of the format of user stories found in the inherited backlog

I am not recommending we write pages of detailed specifications in the form of user-story. No. I am a fan of agile and lean ways of working.

What I am recommending is that we provide enough information such that anyone who picks up the story can get the gist of it. A product team or development team will remain intact without any personnel changes throughout the product lifecycle or development cycle is a myth that needs to be debunked. We also need to consider the possibility of having to revisit a past story for reasons such as: making improvements to a past story/functionality, to jog your memory on what was done, handing over the support of a story/feature etc.

Differentiate between stories that add value and those that are wish-list

I was surprised by the number of user stories that were created in the backlog that were essentially ‘wish list’ items. The question of whether certain stories were really needed or the impact of not doing a given user story was never asked.

Anytime a new story (placeholder story) is added to the backlog, I like to capture the following:

why is this story being added?

why is it being added now? what has changed?

impact of not doing this piece of work

where this sits in the backlog

what value is this adding to the users or business?

How much effort is this likely to be?

For example, a story might be added to enhance the current user experience of a ‘search functionality’. The value it might add will be qualitative, i.e. improved search functionality and hence user satisfaction. However the impact of not doing this piece of work might mean 10sec of additional time spent on that page. Now this puts the story into perspective — do we really want to spend a certain number of development effort to reduce 10sec of additional user time spent on a page or do we want to focus on a different story elsewhere?

The answer of the above question might still be in favour of improving the search functionality, however, at least the team would have gone through the thought process of validating its value before investing more time, effort and money.

Furthermore, realise that every single “idea” does not need to be added to the backlog straightaway. These ideas or requests from users and stakeholders need to be tracked but they do not necessarily need to be tracked in the product backlog.

Regularly prioritise the backlog

Backlog is ever evolving. It therefore needs constant up-keeping. The backlog I inherited had not been prioritised in over a month. I did not know which stories I should focus on first and why. A lot of the stories were flagged but no clarity on why they were flagged and how to resolve the flagged status.

Ideally a backlog should be prioritised every week or at least every sprint. in addition to ensuring that the highest value items are at the top, you also want to make sure that you (as a product person) is investing your energy on elaborating and refining the high priority stories with the team. Remove or archive the items that never got team’s attention. If they are important enough then they will come back.

Sometimes the priorities will need to be defined by technical dependencies and in those cases the PO may not have much a say. For example, setting up of an email template in the email component will need to be done before the system is able to send automated emails to users. However, you should still review it every so often as new things emerge and new information comes to light.

I would love to hear your thoughts on this and how you go about managing a clean, lean and useful backlog.