feat(agile handbook): Add doc on backlog review

src/content/docs/agile-handbook/appendices/backlog-review.mdx

@@ -4,3 +4,40 @@ template: basicDoc
 topics:
   - Docs agile handbook
 ---
+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 [#review_goals]
+
+- **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? Find issues you want to champion for Input Queue.
+- **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 [#review_who]
+
+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. 
+
+Most other times, we'll just 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 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 [#review_checklist]
+
+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 not important enough to fix
+    - It's very old, and we have little evidence anyone cares
+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.
+
+## For more help
+
+We welcome thoughts or questions on our handbook! The easiest way to get in touch is to [file a GitHub issue](https://github.com/newrelic/docs-website/issues/new/choose).