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.
- Current
- Next
- Sooner
- Later
- 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:
- on getting all items to done
- in the order of priority.
- 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.