Healthy Team Backlogs

What is a backlog?

Agile product owners use a backlog to organize and communicate the requirements for a team’s work. Product backlogs are deceptively simple, which can sometimes make them challenging to adopt for product owners who may be used to working with lengthy PRDs (“project requirement documents” or similar).

Scrum most commonly uses the term product backlog. However, many product owners who are new to Scrum are confused by this term. Reasonable questions arise: Does this suggest that a team working on multiple products would have multiple backlogs? If so, how do we prioritize between them? Where do bugs get recorded? What happens if work needs to be done, but it isn’t associated with a product; do we create a placeholder?

Therefore, we prefer the term team backlog. Our working definition of team backlog is “the maintained, ordered list of work that the team plans to do now or in the future.” This is a dense description, so let’s unpack it a little.

“The” and “Team”

• We say the and team because each team needs a single source of truth to track their current and future work.
• If a team is working on multiple projects or products, all of the work for those stories should appear on a single, unified, team backlog.
• Teams do not generally share backlogs.

“Work”

• Work includes almost everything that the development team needs to do.
• Features, bugs, technical debt, research, improvements, and even user experience work all appear on the same backlog.
• Generally speaking, recurring team meetings and similar events do not appear on the backlog.

“Maintained”

• We say maintained because the backlog is a “living” artifact.
• The product owner and team must continually update and refine their backlog. Otherwise, the team will waste time doing useless work and chasing requirements.
• This requires several hours per week for the product owner and 1–2 hours per week for the team. It involves adding, ordering, discussing, describing, justifying, deleting, and splitting work.

“Ordered”

• We say ordered list rather than prioritized list because the backlog is ordered, not just prioritized.
• If the backlog is only prioritized, there can be multiple items that are all “very high priority.”
• If the backlog is ordered, we communicate exactly in what order those “very high priority” tasks should be worked on.

“Plans to Do”

• We say plans to do because we regularly delete everything from the backlog that we no longer plan to work on.
• Deleting unnecessary work is essential. Unnecessary work clutters up our backlog and distracts from the actual work.

What makes a backlog healthy?

Now that we know what a backlog is, what makes a backlog healthy or not? While what makes for a good backlog is somewhat subjective — in the same way that what makes a good PRD could be subjective — there are 10 characteristics that we’ve found to be particularly important.

Would you like to know if your backlog is healthy? Download this handy PDF checklist, print it out, then open up your backlog and follow along. For each criterion, take note of whether your backlog currently does, doesn’t, or only somewhat meets the criterion. In exchange for less than half an hour of your time, you’ll have good sense as to the health of your backlog and a few ideas for improvement.

1. Focused, ordered by priority, and the team follows the order diligently
   • At all times, anyone can look at the backlog and know what needs to be worked on next without ambiguity.
   • Even if you have several “P1” issues, the team needs to know which P1 issue needs to be addressed next. Simply saying “they’re all important” will paralyze the team.
   • Although the PO is responsible for the product backlog order and makes the final call, the PO should be willing to negotiate the order with their team. The team often has good insights that can mitigate dependencies or help the PO deliver more value.
   • Stay focused on one thing at a time when possible to deliver value earlier and reduce context switching waste.

 

2. Higher-value items towards the top, lower-value items towards the bottom
   • In general, do high-value, low-cost work first (“lowest hanging fruit”).
   • Next, do high-value, high-cost work because it is usually more strategic.
   • Then, do low-value, low-cost work.
   • Finally, eliminate low-value, high-cost work. You will almost always find something better to do with your time and resources, so don’t waste your time tracking it. It will be obvious if and when that work becomes valuable.
   • Hint: You can use Weighted Shortest Job First or a similar technique if you’re having difficulty prioritizing.

 

3. Granular, ready-to-work items towards the top, loosely-defined epics towards the bottom
   • Items that are at the top of the backlog will be worked on next, so we want to ensure that they are the right size to work on.
   • The typical team’s Definition of Ready recommends that items take ≤ ½ of a sprint to complete.
   • Delay decision-making and commitments — manifested as small, detailed, team-ready items — until the last responsible moment.
   • There is little value specifying work in detail if you will not work on it soon. Due to learning and changing customer/company/competitive conditions, your requirements may change or you may cancel the work altogether.

    
   What is an Epic?

   • An “epic” is simply a user story that is too large to complete in one sprint. It gets prioritized in the backlog like every other item.
   • JIRA Tip: “Epics” in JIRA do not appear in the backlog for Scrum boards. As a result, they behave more like organizing themes than epics. Therefore, we suggest using JIRA’s epic functionality to indicate themes and user stories with the prefix “Epic: ”  to indicate actual epics.

 

4. Solutions towards the top, statements of need towards the bottom
   • Teams can decide to start working on an item as soon as they know what customer needs they hope to solve. However, collaborating between product, design, development, and stakeholders to translate customer needs into solutions takes time.
   • As with other commitments, defer solutioning decisions until the last responsible moment:
     • Your ideal solution may change through learning or changing conditions such as customer, competitors, company, or even technology options.
     • You may decide not to work on the problem after all.

 

5. 1½ to 2 sprints worth of work that’s obviously ready to work on at the top
   • Teams sometimes surprise the product owner by having more capacity by expected.
   • Having enough ready stories ensures that the team is:
     • Unlikely to run out of work to pull into their sprint backlog during sprint planning.
     • Able to pull in additional work during the sprint if they complete the rest of the work on their sprint backlog.
   • It should be obvious what work is and isn’t ready to work on so that the team doesn’t have to waste time figuring it out each time they look at the backlog.
     • Some teams prefix a story title with a “* ” to indicate a ready story (or a story that isn’t ready).

 

6. The value of each piece of work is clearly articulated
   • Your team should be able to understand why the work is important to work on.
   • There are three primary sources of value (and you can define your own):
     • User/Business Value: Increase revenue, reduce costs, make users happy
     • Time Criticality: Must it happen soon due to competition, risk, etc.?
     • Opportunity Enablement/Risk Reduction/Learning: Is it strategic? Is it necessary to enable another valuable item (for example, a dependency)?
   • You won’t usually need a complex financial projection, just a reasonable justification as to why the item should be worked on next relative to all other known possibilities. Time previously spent with complex projections can instead be used to talk to customers and identify other opportunities.

 

7. The customer persona for the work is clearly articulated
   • The “As a” part of the “As a ____, I can ___, so that ____” user story isn’t a mere formality; it’s an essential part of user-centered product development.
   • Who is the customer? Who are you completing this work for? Even if you’re on a “back-end” team, keep the end-user in mind.
   • Partner with your designer to identify your personas and reference them whenever possible. Is this feature for “Serious Seller Sally?” Can you imagine her personality and needs just as well as any of your friends?
     • Example: “As Serious Seller Sally, I can list items using a ‘advanced’ flow so that I can get the options I need without the guidance for casual-sellers that only slows me down.”
   • Tool Tip: Most teams and POs find it best to put just the “I can” part the user story (for example, “List items using a ‘advanced’ flow”) in the planning tool’s title field. Otherwise it can be harder to read the backlog. Put the entire user story at the top of your tool’s description field.

 

8. ≤ 100 items (a rule of thumb), and contains no work that — realistically — will never be done
   • This is a general rule. If your team works on many very small items or has considerable work that you must track, your backlog could be longer.
   • Assuming that each backlog item takes a minute to read and understand, 100 items alone would take over an hour and a half to process. Keeping our backlog limited like this makes it easier and faster to fully understand.
   • A longer backlog is more likely to contain features that will never be built or bugs that will never be fixed. Keeping a short backlog helps us ensure that we triage effectively and delete items that we are unlikely to work on.

 

9. The team backlog is not a commitment
   • A Scrum team cannot make a realistic, firm commitment on an entire team backlog because:
     • It has not been through high-level design (for example, tasking at end of Sprint planning).
     • The risk of missed dependencies and unexpected requests/impediments is too great.
     • “Locking in” a plan that far into the future considerably restricts flexibility
   • A Scrum team can make a valid commitment on a sprint backlog if there are no mid-sprint scope changes and few unexpected requests and impediments.

 

10. Backlog reflects the release plan if available
    • If the team has conducted release planning, create pro forma sprints with items in your planning tool to reflect the release plan.
    • If there are production release, moratorium, or similar dates, communicate those too.
    • Update the release plan at end of each sprint as you learn.

What does a healthy team backlog look like in JIRA?

Glad you asked. Here are four sample “sprints” that take good advantage of JIRA’s built-in functionality.

Sprint 1 (active sprint)

Sprint 2 (next sprint)

Sprint 3 (future sprint)

Sprint 4 (future sprint)

Conclusion

Now you know what a healthy team backlog looks like. If you’ve filled out our printable checklist, mark off up to three items that you’ll work to improve over the next week or two with your teams. We hope this is of use to you!