style(agile handbook): Copyedits and add context for non-NR folks

src/content/docs/agile-handbook/appendices/project-scoping-cheatsheet.mdx

@@ -46,7 +46,7 @@ We use this cheatsheet to help us scope projects in a consistent way.
 
 + Who is writing?
 + When is it due?
-+ Do we need JIRAs?
++ Do we need tickets?
 + Who is following up with who?
 
 <ButtonGroup>

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

@@ -7,15 +7,15 @@ topics:
 
 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.
+Jira tickets 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.
+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 ticket 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.
+We create tickets 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:
 
@@ -48,29 +48,29 @@ In other words, Jira has a role at every point in a project:
     </tbody>
 </table>
 
-## What work needs a Jira?
+## What work needs a ticket?
 
-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. 
+There aren't hard-and-fast rules about what work needs a Jira ticket and what doesn't. A good shorthand is that any project that takes more than an hour is a good candidate for a ticket. 
 
-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](/docs/agile-handbook/sprint-mechanics/liaisonships/), [hero work](/docs/agile-handbook/heroing/what-is-a-hero/)) generally do not need to go into Jira. 
+However, the goal of creating tickets is not to track writer time in detail (see section above). So many kinds of work (meeting times, ongoing minor [liaison tasks](/docs/agile-handbook/sprint-mechanics/liaisonships/), [hero work](/docs/agile-handbook/heroing/what-is-a-hero/)) generally do not need to go into Jira. 
 
-## Keeping Jiras up-to-date [#lottery_factor]
+## Keeping tickets 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.
+In general, you should write your tickets [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.
+- When you move a ticket to Blocked, include a note explaining the change in status.
+- When closing a ticket, 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]
+## Checklist for writing a good ticket [#jira_checklist]
 
 <table>
   <tbody>
@@ -79,8 +79,8 @@ When you edit the site, include the Jira issue key (DOC-1234, for example) in yo
         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"
+        - A ticket 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 ticket titles: "Browser API: Update custom attribute-related docs" or "Distributed tracing: Add more detail about CAT relationship"
       </td>
     </tr>
     <tr>
@@ -132,7 +132,7 @@ When you edit the site, include the Jira issue key (DOC-1234, for example) in yo
         Labels and fields
       </td>
       <td>
-        - Jiras: Component, Product Group, and Priority
+        - Jira tickets: Component, Product Group, and Priority
         - GitHub issues: `from_`, `pg_`, and `content` labels
       </td>
     </tr>

src/content/docs/agile-handbook/key-concepts/agile-roles.mdx

@@ -4,9 +4,9 @@ template: basicDoc
 topics:
   - Docs agile handbook
 ---
-Like most agile teams, we divide the team into team members, scrum masters, and managers. Because a content team has different needs than an engineering team, though, we ask somewhat different things of each of those roles:
+Like most agile teams, we divide the team into team members, scrum masters, product owners, and managers. Because a content team has different needs than an engineering team, we ask somewhat different things of each of those roles:
 
-- We combine the role of team manager and product manager into one person.
+- We combine the role of team manager and product owner into one person.
 - Each writer is responsible for "liaisonships" where they track work across a particular product or feature and bring in appropriate stories.
 - We don't expect scrum masters to clear blockers (that's a manager's job), and scrum mastering is not a full-time job.
 
@@ -21,13 +21,13 @@ Team members are responsible for:
 
 ## Scrum master [#scrum_master]
 
-The scrum master is a custodian of the sprint process, and the MC for sprint meetings.
+Each squad has a scrum master. The scrum master is not responsible for unblocking stories or communicating with stakeholders on behalf of the team (this work belongs to individual writers and their manager). We believe this lets the business have a single point of accountability (managers) for decisions, and ensures scrum masters have hands-on experience of what it's like to be a writer.
 
-- **In [sprint planning](/docs/agile-handbook/sprint-mechanics/meetings-and-ceremonies/#sprint_planning)**: Scrum master leads conversation, tracks discussion time, adds point values to stories, and organizes/ranks sprint candidates in real time. All stories in sprint planning should be presented to the team by the story reporter or the person who nominated the story for a sprint, not the scrum master. 
-- **In [retros](/docs/agile-handbook/sprint-mechanics/meetings-and-ceremonies/#retro)**: The scrum master puts together the retro slide deck, facilitates discussion, and takes notes. The scrum master may also compile sprint metrics. 
-- **In [backlog grooming](/docs/agile-handbook/sprint-mechanics/meetings-and-ceremonies/#backlog_grooming)**: Ideally, both the scrum master and manager are always present for backlog grooming, and all other team members are optional. If either the manager or scrum master are out of office, the other attends grooming with at least one other team member. If both are out of office, backlog grooming may be postponed.
+Instead, for us the scrum master is a custodian of the sprint process and the MC for sprint meetings.
 
-Each squad has a scrum master. The scrum master is not responsible for unblocking stories or communicating with stakeholders on behalf of the team (this work belongs to individual writers and their manager). We believe this lets the business have a single point of accountability (managers) for decisions, and ensures scrum masters have hands-on experience of what it's like to be a writer.
+- **In [backlog grooming](/docs/agile-handbook/sprint-mechanics/meetings-and-ceremonies/#backlog_grooming)**: The scrum master handles the mechanics of talking through each ticket and facilitating conversations about story quality. 
+- **In [sprint planning](/docs/agile-handbook/sprint-mechanics/meetings-and-ceremonies/#sprint_planning)**: The scrum master leads conversation, tracks discussion time, adds point values to stories, and organizes/ranks sprint candidates in real time. They don't present the stories, though—stories should be introduced by the person who nominated the story for the sprint.
+- **In [retros](/docs/agile-handbook/sprint-mechanics/meetings-and-ceremonies/#retro)**: The scrum master facilitates the discussion, captures action items, and takes notes. 
 
 ## Tech Docs managers (and product owner) [#team_managers]
 
@@ -39,7 +39,7 @@ The manager is also responsible for assigning liaisonships and ensuring we're co
 
 ## Key stakeholders [#key_stakeholders]
 
-Key stakeholders include executives, PMs, engineers, and designers. Writers work with the stakeholders to know when new work is coming, and to communicate documentation needs/timelines. 
+Our key internal stakeholders include PMs, engineers, designers, and executives. Writers work with the stakeholders to know when new work is coming, and to communicate documentation needs/timelines. 
 
 We should ensure our stakeholders know that we work in two week sprints, so that they can give us adequate lead time and get their documentation needs met.
 

src/content/docs/agile-handbook/key-concepts/agile-sprints-profusion-of-terms.mdx

@@ -5,7 +5,9 @@ topics:
   - Docs agile handbook
 ---
 
-Our team uses an **agile** **Sprint** workflow in **Jira** and **GitHub** to manage our work. We've further divided our team into **squads** to simplify planning and improve accountability. All those words are pretty inconsistent in their usage, so let's break them down further:
+Our team uses an **agile** **Sprint** workflow in **Jira** and **GitHub** to manage our work. We've further divided our team into **squads** to simplify planning and improve accountability. 
+
+All those words are pretty inconsistent in their usage, so let's break them down further.
 
 ## Agile [#agile]
 
@@ -25,25 +27,23 @@ This is the particular flavor of agile we follow. The sprint system (often refer
 * Planning that sprint in advance, and not changing the scope of the sprint (much) once it starts
 * Expecting all team members to contribute to making the sprint a success
 
-The video [Agile Product Ownership in a Nutshell](https://www.youtube.com/watch?v=502ILHjX9EE) (18 minutes) is an excellent resource for learning about Agile methodology. The Kindle book [Scrum: a Breathtakingly Brief and Agile Introduction](https://www.amazon.com/Scrum-Breathtakingly-Brief-Agile-Introduction-ebook/dp/B007P5N8D4/) is also a great read that you can get through in a short afternoon. 
+The video [Agile Product Ownership in a Nutshell](https://www.youtube.com/watch?v=502ILHjX9EE) (18 minutes) is an excellent resource for learning about sprint methodology. The Kindle book [Scrum: a Breathtakingly Brief and Agile Introduction](https://www.amazon.com/Scrum-Breathtakingly-Brief-Agile-Introduction-ebook/dp/B007P5N8D4/) is also a great read that you can get through in a short afternoon. 
 
-For more on the "why" of Sprint as our chosen methodology, see [Agile vs sprints](/docs/agile-handbook/key-concepts/agile-sprints-profusion-of-terms/). And for more on the "how," see [Sprint workflow](/docs/agile-handbook/sprint-mechanics/sprint-workflow-and-jira-boards/).
+For more on the "why" of Sprint as our chosen methodology, see [Key agile principles](/docs/agile-handbook/key-concepts/key-agile-principles/). And for more on the "how," see [Sprint workflow](/docs/agile-handbook/sprint-mechanics/sprint-workflow-and-jira-boards/).
 
-## Jira and GitHub projects [#jira-and-github-projects]
+## Jira and GitHub issues [#jira-and-github-projects]
 
-Jira and GitHub projects are the tools we use to manage our Agile workflow. If you remember one thing about them, it should be this: using Jira or GitHub issues is not the same as having an agile workflow. They're powerful tools for tracking work and managing a backlog, but the most important part of project management is the structure we impose on that tool.
+Jira and GitHub issues are the tools we use to manage our Agile workflow. If you remember one thing about them, it should be this: using Jira or GitHub issues is not the same as having an agile workflow. They're powerful tools for tracking work and managing a backlog, but the most important part of project management is the structure we impose on that tool.
 
-Jira is for sprint work. Sprints are where roadmap docs get written, monthly commits get delivered, and deeper research percolates. We have a backlog, board, and future sprint list in Jira that help us track what people want, what's coming up, and what we're working on now. For more on the mechanics of how we use Jira, see [Sprint workflow and Jira boards](/docs/agile-handbook/sprint-mechanics/sprint-workflow-and-jira-boards/) and [Ticket best practices: How to write a sprint-worthy Jira](/docs/agile-handbook/appendices/ticket-best-practices/).
+Jira is for sprint work. Sprints are where roadmap docs get written, monthly commits get delivered, and deeper research percolates. We have a backlog, board, and future sprint list in Jira that help us track what people want, what's coming up, and what we're working on now. For more on the mechanics of how we use Jira, see [Sprint workflow and Jira boards](/docs/agile-handbook/sprint-mechanics/sprint-workflow-and-jira-boards/) and [Ticket best practices](/docs/agile-handbook/appendices/ticket-best-practices/).
 
 We use GitHub projects for hero work, customer-reported issues, and managing the flow of PRs and edits. The [Docs PRs and Issues board](https://github.com/newrelic/docs-website/projects/3) contains everything we're actively working on in GitHub. We'll often connect work in GitHub back to Jira by putting a Jira issue key in the PR or issue title (`DOC-1234`, for example). For more on the mechanics of how we use GitHub, see [Managing the GitHub boards](/docs/agile-handbook/heroing/managing-the-github-boards/).
 
-We also use "Jira" to mean a story, ticket, or task. These are all basically synonyms.
-
 ## Teams and squads [#teams-and-squads]
 
 ![Lines of communication scale rapidly as you add people to a team. Where L is Lines and P is People, the formula is L=P((P/2)-0.5)](./images/lines_of_communication.png "Lines of communication versus the number of people on a team.")
 
-Our team is the Tech Docs team. We're collectively responsible for docs.newrelic.com and sundry writing content. Our team is further divided into two agile squads (_The Odd Squad_ and _The Amp Squad_). Squad membership is based simply on manager.
+Our team is the Tech Docs team. We're collectively responsible for docs.newrelic.com and sundry writing content. Our team is further divided into two agile squads (_The Odd Squad_ and _The Amp Squad_, one squad for each manager.
 
 The primary function of squads is to simplify sprint planning, backlog grooming, and liaisonships. Less people means shorter meetings. It also means better information sharing: The more people you have in a group, the more lines of communication are needed (see illustration) to maintain a shared understanding. Small squads can collaborate more easily than a large team, because not everyone needs to keep in mind everything that goes on everywhere.