Managing an Backlog as a Funnel.

Introduction

Various Scrum Backlogs I have seen in my career have become a 'Black Hole' of issues. They contain 500+ open issues and sometimes having issues, which have been open for more then 2 years, where in initial issuer already has left the company.
Finding proper things to work on becomes a 'needle in a haystack' and having such a backlog does not provide any insight any longer.

Although Mary Poppendieck makes a suggestion to 'Just Burn Your Backlog' and only accept issues with one of three possible priorities: "Now, Next, Never", not all organizations are willing / brave enough to do that (yet).

Managing a backlog

A working Scrum team

From the entire backlog a Scrum team picks items to include in the current sprint. During the sprint they are responsible for working on the issues and getting them done.

Refinement and analysis

Unfortunately issues do not magically become 'Ready for development'. Most of the time issues need some kind of refinement for that. The purpose of those refinements is to talk about some issues on the backlog in order to comprehent the issue and split them into smaller items, so that those items can be accepted to be worked upon in the current sprint. In order to prevent creating 'waste' by spending time to refine an entire backlog of stories, the organization needs to prioritize what issues needs to be made ready. This process of prioritization can be look at a like Sales Funnel, where issues progress from stage to stage in a controlled manner.

Overview from 'Getting things done'

In this article I will explain the stages in the funnel, which takes some inspiration from 'Getting Things Done' by David Allen.
I envision a backlog where all issues in a backlog have been assigned to one of following four core priorities / stages.

1. Current
2. Next
3. Sooner
4. Later
5. New / Inbox

This fifth item is a default stage for all issues, which have been added to the backlog recently, but did not have a priority assigned to them yet!
Assigning the priority is the primary responsibility of the Product Owner

The current sprint

Rules

• All items must meet the Definition of Ready

Activities

The team should focus:

1. on getting all items to done
2. in the order of priority.
3. Keep the number of issues in progress as small as possible.
   ‘A short conveyor belt’

Ready for the Next sprint

Rules

• All items must meet the Definition of Ready
• Ready for Next Sprint should always contain some items, which the team can do in the Current Sprint if everything gets to ‘Done’

Objectives

• During the current sprint the team should refine enough issues into 'Next sprint' fill an entire sprint, so that during the Spring Planning session the team just needs to figure out the amount of work they can commit to.

Issues in the Sooner sprint

Rules

• Issues in ‘Sooner’ will not be done within the next 2 sprints
• These items in 'Sooner' should be prioritized.
• Only the PO can add items to Sooner

Objectives

• Allows the Product Owner to focus on the top of this stage for finding issues for refinements and scheduling conversations
• Provide some manner of expectation management.
  Issues in 'Sooner' are likely to be implemented the next quarter of a year.

Issues in the Later sprint

Rules

• Only the PO can add items to Later
• These items in 'Later' do not have to be prioritized.
• Items are allowed to be oneliners representing entire epics

Objectives

• Allow the Product Owner to ignore these items during frequent backlog grooming sessions
• Provide some manner of expectation management.
  Issues in 'Later' are likely NOT to be implemented within the next 6 months.

Roughly once every quarter the Product Owner should browse through it items in the 'later' stage to select some to be promote to 'Sooner'.

New issues

Rules

• All created issue will end up here.
• The PO needs to look at these, understand them and give them a priority by moving these items to Sooner or Later.
• Everybody can create new items.

Objectives

• Make sure the PO sees and understands all items in the backlog.

Anybody adding an issue to the backlog SHOULD talk to the Product Owner, preferably in advance, about the business value and scope of the issue.

Tooling. Creating and managing the issues in backlog frequently gets done in a tool like Jira, Github, Gitlab. In most of these tool you can create the stages of this approach either as 'Iterations', 'Fictional Sprint' or use Label to tag the issues with the appropreate stage.

Related articles

• Why You Should Just Burn Your Backlog by Mary Poppendieck
• Getting Things Done by David Allen
• Conversational patterns in BDD by Liz Keogh

This work is licensed under a Creative Commons Attribution 4.0 International License.