• Log in

Backlog review

About once a quarter, the Docs team reviews our entire backlog in Jira and GitHub. This ensures that we actually know what's in there, and that we're bubbling up the right stories from the backlog into upcoming sprints.

Goals of backlog review

  • Fix easy issues: If you can fix something quickly, just do it.
  • Find broken windows: What are the small (or big!) broken windows lurking in our backlog? What should we consider bubbling up into a future sprint?
  • Identify gaps in the backlog: Discover important issues that are not at all covered in the backlog.
  • Clear out cruft: Find duplicate issues, things we'll never fix, or issues that are just no longer relevant.
  • Check labels and fields: Is the ticket assigned a correct priority score? Do we have the correct labels for other fields?

Who reviews the backlog

Sometimes we'll involve the whole team in a backlog review; other times, just the managers will handle the review.

The most useful time to involve the whole team is when we're onboarding a new writer: Talking through issues promotes a lot of knowledge-sharing about the product, docs, stakeholders, and how to write a good ticket.

Otherwise, we'll usually assign the review to the managers. This saves time, and it also tends to make it easier to close out issues (since our managers are also our product owners). If we don't involve the whole team, we'll prepare a spreadsheet of which issues we closed and list writers who might care so they can weigh in on whether the issue should have stayed open.

What to look for in a backlog review

When you review an issue, perform the following checks:

  1. Check if the issue can be closed:
    • It's already resolved, or you can't reproduce the issue
    • It's old, and we have little evidence anyone cares
    • It's not important enough to fix
  2. If the issue doesn't have a clear goal/task, try to discover one (but don't feel obligated to rewrite the whole issue).
  3. Add context and update as-needed.
  4. Review fields and labels and ensure they're accurate.
  5. Add a label to the issue once you're done with your review.
    • Use this format: year_month_backlog_review. For example: 2021_october_backlog_review.
    • This helps keep track of which issues you've reviewed on this round of backlog review
    • It's also a useful nudge for future round of review: If an issue has more than one or two review labels, you should probably close it.
← Appendix: Project scoping cheatsheet

Tip

We welcome thoughts or questions on our handbook! The easiest way to get in touch is to file a GitHub issue.

Copyright © 2022 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.