Managing a clean and useful backlog

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

  • 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

  • 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.
Figure 3: Intentionally blurred image of the format of user stories found in the inherited backlog

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

Regularly prioritise the backlog

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

--

--

--

A Product Consultant at Kainos working with UK Public and Private sector clients. All view are my own.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Top 5 Tips For Gateway Deployments

Terraform variable validation

Learning Unreal Engine 4: Implement Cel-Shading w/ Outline Using Custom Shading Model in UE4.22 (1)

Console.WriteLine(“Hello World!”);

Python Decorators — 5 Advanced Features to Know

The Best Resources for Learning to Program

How to Publish a Jupyter Notebook as a Medium Blogpost

On Untestable Software

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jayti

Jayti

A Product Consultant at Kainos working with UK Public and Private sector clients. All view are my own.

More from Medium

Product development, and managing scope

User Story; a requirement or a backlog item?

What does product management look like across different industries?

What does product management look like across different industries?

How to Design and Implement an Innovative Solution in Nine Months