feat(agile handbook): Add doc on Jira best practices

src/content/docs/agile-handbook/appendices/ticket-best-practices.mdx

@@ -3,4 +3,142 @@ title: "Ticket best practices: How to write a sprint-ready Jira"
 template: basicDoc
 topics:
   - Docs agile handbook
----
+---
+
+Jira, a project management tool made by Atlassian, is how we manage our projects and understand the work we are doing and have done.
+
+Jiras may seem at first to be simple to-do lists that we use to know what things to do for a project. But they are much more important than that.
+
+<Callout variant="tip">
+For Relics: Use the [docs.newrelic.com/jira](https://docs.newrelic.com/jira) template when you create a ticket! It'll automatically pre-fill your Jira with most of the necessary info to create a good ticket.
+</Callout>
+
+## Why do we use Jira? [#why_jira]
+
+We create Jiras to record work-to-be done for a project, scope new work, share information for any writer to complete a story, forecast our output and to estimate project timelines, and have a record of work done.
+
+In other words, Jira has a role at every point in a project:
+
+<table>
+    <tbody>
+    <tr>
+      <td>
+        Before a project
+      </td>
+      <td>
+        Scoping, syncing on expectations, giving tech writer instructions
+      </td>
+    </tr>
+    <tr>
+      <td>
+        During a project
+      </td>
+      <td>
+        Keeps team and management posted about project; allows for hand-offs and swarming
+      </td>
+    </tr>
+    <tr>
+      <td>
+        After a project
+      </td>
+      <td>
+        Understand what work we did, and helps researching on future projects
+      </td>
+    </tr>
+    </tbody>
+</table>
+
+## What work needs a Jira?
+
+There aren't hard-and-fast rules about what work needs a Jira and what doesn't. A good shorthand is that any project that takes more than an hour is a good candidate for a Jira. 
+
+However, the goal of creating Jiras is not to track writer time in detail (see section above). So many kinds of work (meeting times, ongoing minor liaison tasks, [Hero and CSAT Sidekick work](3379_INSERT_LINK_HERE)) generally do not need to go into Jira. 
+
+## Keeping Jiras up-to-date [#lottery_factor]
+
+In general, you should write your Jiras [as though you might win the lottery tomorrow](https://en.wikipedia.org/wiki/Bus_factor). That is, someone should be able to read your ticket and figure out within about ten minutes what the status is and what the next step is. This makes it easy for us to take vacations, pass work off to another docs writer if needed, and escalate blockers.
+
+These things help with lottery factor:
+
+- Update the Action Item list as you complete tasks and add or remove scope.
+- When you move a Jira to Blocked, include a note explaining the change in status.
+- When closing a Jira, give a summary of the work done and any relevant thoughts you have on the work and potential related issues.
+- Update the Timeline, People, and Resources sections as the project evolves.
+- Add important conversations (emails or Slack convos from SMEs) that give important context for the work done. (Note: It's a good idea to ask permission before doing this, because some people might not like their informal words placed in a public place.)
+
+## Add Jira context to PRs and commits [#links_to_github]
+
+When you edit the site, include the Jira issue key (DOC-1234, for example) in your pull request title and/or commit summary. That makes it easier for other writers to connect the dots later if we're trying to figure out why something changed or who knows about a particular subject.
+
+## Checklist for writing a good Jira [#jira_checklist]
+
+<table>
+  <tbody>
+    <tr>
+      <td>
+        Helpful title
+      </td>
+      <td>
+        - A jira name should be easy to find via search, understand the work at a glance, mention the product or feature, and describe the goal or issue. 
+        - Examples of good Jira titles: "Browser API: Update custom attribute-related docs" or "Distributed tracing: Add more detail about CAT relationship"
+      </td>
+    </tr>
+    <tr>
+      <td>
+        Action items
+      </td>
+      <td>
+        - An action item list describing the work to be done
+        - What docs are affected
+        - Links to drafts is applicable
+        - How substantial the writing work is in each doc
+        - How the resulting work should be structured
+        - Whether or not a peer edit is needed
+        - Anyone who should be notified when a doc is published
+      </td>
+    </tr>
+    <tr>
+      <td>
+        Proper sizing
+      </td>
+      <td>
+        - Story is scoped to the smallest reasonable size
+        - Can be completed within a 2 week sprint
+        - Delivers incremental value
+      </td>
+    </tr>
+    <tr>
+      <td>
+        Dates
+      </td>
+      <td>
+        - Publication date or due date
+        - Dates for other key events (betas, limited releases, etc.)
+      </td>
+    </tr>
+    <tr>
+      <td>
+        Resources and people
+      </td>
+      <td>
+        - People, including last names and roles 
+        - List of related or affected docs
+        - Other internal and external resources
+        - Related issues
+      </td>
+    </tr>
+    <tr>
+      <td>
+        Labels and fields
+      </td>
+      <td>
+        - Jiras: Component, Product Group, and Priority
+        - GitHub issues: `from_`, `pg_`, and `content` labels
+      </td>
+    </tr>
+  </tbody>
+</table>
+
+## 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).