In this post, I take a short sail through the waters of refining an Agile Team’s backlog.
The ideal condition for a team’s backlog (of both user stories and non-stories) is for it to be:
- Owned by the team
- High with signal
- Low on noise
From this state, the crew can plan their next iteration quickly and efficiently, with a focus on the delivery of real business value, the optimization of their customers’ experience, as well as the removal of “viscosity” that will lead to ever increasing team performance.
Backlog Refinement Principles
So often a team’s backlog becomes like the kitchen junk drawer or the attic. User feedback, product ideas, bug/feature reports, chores, etc., all stashed away for “some day” so they don’t get lost. And before you know it there will be hundreds of cards to sort thru at planning, many of them in no particular order. There will be more noise than signal. Sprint planning becomes a dreaded chore. Teams just look at the User Stories to the detriment of their chores.
Refinement to the rescue!
…From “The Scrum Guide”
[Guide has a focus on product backlog items (user stories), but applies to intangibles like tech debt as well, imo]
Product Backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog grooming, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. How and when grooming is done is decided by the Scrum Team. Grooming usually consumes no more than 10% of the capacity of the Development Team.
The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping understand and select trade-offs, but the people who will perform the work make the final estimate.
…From Kanban
Grooming the backlog with a regular triage to reduce the size [number of items] improves the effectiveness and efficiency of prioritization meetings.
…From Mike Cohn’s Scrum Repair Guide
Backlog Grooming / Refinement
- What’s in the backlog that needs regular grooming and refinement: Features, Bugs, Knowledge Acquisition (Discovery), Technical Work – Chores (Debt clean up, Refactoring, Test Coverage)
- “Defer” things that will never get done…get them off the radar, to cut down on the noise
- Adjust priorities based on new information since the previous grooming session
- Split larger items near or at the top of the backlog out into smaller ones
- Assess items near or at the top against the team’s Definition of Ready –
- sufficient, high-level definition, and just enough preparation, not perfection,
- there should be just enough information thought so that in <10 mins during Planning, the stories at the top can be tasked out
- Estimate/Size
- Allows the PO to prioritize based on value and “cost” in advance of the planning meeting;
- allows business to make long-term projections;
- ideally all items are sized, even the “big, fuzzy ones” at the bottom of the backlog
- Chores: Quantify the effort/ROI, allows for easy justification for ~10% of plannable capacity
- Who does grooming and when:
- Option a) Thru-out the course of a sprint
- Option b) On a designated day near close of sprint with flexibility in full vs partial team participation
Avoid Feature-itis
Create BALANCE, i.e. not having too much of anything in the backlog. Review the backlog and look for collections of things – beyond simply a list of user stories. Look for things being considered like: dependencies, technical complexity, architecture, quality and testing, defect repairs, innovation and experimentation.
Refinement Mechanics
So, how actually to keep things tidy and relevant? Each time a team looks at or touches a ticket in their backlog, it consumes time, energy, and focus.
One of the solutions to this is a custom workflow that allows for “one-touch” triage with the goal of keeping the actual “backlog” actionable.
Here’s a sample JIRA workflow:
This workflow is applied via a Workflow Scheme to only specific issue types. (For example task, bug, technical debt… but not Stories). Then we set up two boards – a kanban for refinement, and a scrum board for planning. The team’s planning board is set to not display anything before “backlog” status.
Then during periodic, mid-sprint refinement sessions, the crew can, with no wasted touches, move things along the way to signal…
- Raw – Newly created cards of a certain type start in this status, which means the card has not been evaluated in terms of current relevance, or potential business value. Once evaluated, the card can either be closed by simply dragging it to a “Closed” column (see close resolutions below) or moved to “unprioritized” with “one-touch”
- Unprioritized – Cards in “unprioritized” are periodically reviewed to ensure they meet the team’s Definition of Ready. Once they do meet DoR, they go to “backlog”
- Backlog – as mentioned above, only in this status does a card show up in the team’s sprint planning view.
- Close Resolutions – When “closing” a card, the team assigns an appropriate resolution and provides a comment for historical/reference purposes. Resolutions can be something like:
- Won’t Fix / Incomplete: The problem described is an issue that will never be fixed. (Provide reasoning, e.g. end of life, value vs effort consideration, works as designed – i.e, feature not a bug.) If necessary team can always reopen the issue at a later date.
- Duplicate: The card is a duplicate of another issue. (Link to duplicate.)
- Deferred: The issue will not be addressed at this time. There’s probably some business value, but not in the near term. This resolution “closes” the card and puts it in a “special attic box” which can be examined at a later date. The card will not be visible in the team’s planning backlog, nor in the refinement kanban. It can be found by query.
- Cannot Reproduce: All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produced no clues as to why this behavior would occur. If more information appears later, we reopen the issue.
Who Attends Refinement Sessions?
The Team “owns” refinement (and planning as well.) Stakeholders, Business Owners, and Gold Owners should only attend if invited by the Product Owner or Team because they are needed to answer questions (e.g. clarify details needed to get a card to meet the team’s Definition of Ready – or to clarify an Acceptance Criteria during planning. Other than that, all refinement and prioritization is best channeled thru the team’s PO.
Chart a Course
The way to arrive at the paradise of a meaningful, actionable team backlog is thru having a clear vision of the team’s goal, and applying a consistent refinement effort – a little rudder far from the rocks. And in this way, you’ll prevent the need for a lot of rudder next to the rocks.
Explore More
- How to Manage a Product Backlog with Ease
- Scrum Repair Guide
- Backlog Refinement – The Rodney Dangerfield of Scrum Ceremonies
- Solve for: Painful and ineffective Sprint Planning
- Repeated “undone work” pattern at the end of the Sprints.
- Poor Quality and higher Defect rates
- The 3 C’s of a user story
- Patterns for Splitting User Stories
- How to Split a Story – Graphic
- How to improve our grooming meetings?
