Introduction 

In this blog, I’ll be sharing my experiences when it comes to building a backlog from scratch. As BAs we’re all familiar with the backlog and its purpose but one of the biggest challenges I’ve faced over the years is actually creating one from nothing as I feel that if you don’t start the backlog in a structured, disciplined way, it can lead to a lot of pain and confusion further down the line e.g. the dreaded ‘bloated backlog’. Remember, the backlog is the centrepiece of project delivery so it makes sense to ensure it’s started off in the right way and evolves and iterates from a solid foundation.

Taking the reins

For this blog, let’s assume you’re a BA on a project that’s starting from scratch and therefore does not have a backlog in place. As the BA, you will have a significant say in the backlog and its initial inception. After all, you are the one writing the stories right (or ‘should’ be) and therefore should be instrumental in its development. 

I’ve worked on several projects where backlogs have been created and I’ve seen it go well and not so well. When it’s not gone well is where the backlog is seen as a place where the team captures every single little nuance of the project and before you know it, there are dozens, or hundreds of tickets that bear no relation, or very little relation, to the aims and objectives of the project. It was seeing this approach on a project recently that inspired me to write this blog as what that approach did was to cause confusion from the very start and in the end, had to be completely reworked which meant unnecessary work for the team and pushed the project back several weeks.

Prepare

Before the team goes gung-ho and starts creating a load of tickets to meet the need of ‘having a backlog’, you, as the BA, need to formulate how the backlog should be organised. To start the setup of the backlog, you need to articulate the user journey. Not in any particular detail but at least the steps to get the user from end to end. Below is a very basic user journey for an online shopping app that illustrates where we start when creating the backlog. 

Browse items

Add items to basket

Pay for items

Deliver items

You can elaborate further like adding the above features but be careful not go into too much detail too early as you will find yourself and the team debating what should/should not be included instead of getting started.

Creating this user journey should not be done in isolation and should involve all members of the delivery team, particularly the product owner/manager, and come to a broad agreement as the starting point. Once agreed, you can now put pen to paper, so to speak, and start creating the first backlog items.

Start small and iterate

The skeleton journey has been agreed and you’re now ready to start creating backlog items but before you do, consider how broad you’re going to go with the initial set of items. This means agreeing items at an epic level before creating depth with user stories and tasks. Using the online shopping app, we could create an epics under each of the phases (create, select, pay, deliver) such as;

• Browse items epics
  • Search function
  • App layout
  • Item categories
  • Add images of items
• Add items to basket epics
  • Add items to basket
  • Remove items from basket
  • Go to checkout
• Pay for items epics
  • Select payment method
  • Select delivery method
  • Enter payment details
  • Confirm payment
• Deliver items epics
  • Confirm items dispatched 
  • Confirm delivery timescale
  • Confirm delivery successful

As you can see, just from those basic 4 user journey steps, we can see how the backlog is starting to develop and build out. If you picture this in a linear fashion instead of top-down as above, you can also see the start of a user story map. Creating a user story map early in a project  is, in my opinion, critical to getting the project off to a positive start. Not only for its ability to clearly organise work but also provides a great visual aid for the team and stakeholders.

Instilling good habits and backlog discipline in the team

When I’ve seen backlogs get out of control, it invariably stems from bad habits within the team. Some of these bad habits include tickets:

• not being assigned to an epic
• that have a title only and no description
• older than 6 months
• being added to the backlog with no team consultation 
• being added by people outside the delivery team

To alleviate these bad habits, good ways of working need to be instilled early on in the project or if the project is already up and running, having a ‘Ways of working’ session to define good habits and disciplines.

Good habits I’d recommend instilling in the team are to:

• Ensure every ticket is assigned to an epic. If a ticket doesn’t fit within an epic, create one. Note, before an epic is created, discuss with the Product Manager/Owner to ensure it fits with business objectives
• Ensure every ticket has a clear description of the purpose of the ticket, what the ticket will achieve and there is enough information for someone to pick up and progress. The detail should include
  • The rationale for the ticket
  • Key contacts and their contact details i.e. email address
  • Relevant attachments
• Ensure any tickets that are added to the backlog and don’t meet these habits are raised with the ticket creator and the tickets is amended to include the above

I believe if you instill these disciplines with the delivery team then all the activities related to the backlog like planning, prioritisation, refinement, etc will run much smoother.