chore(agile handbook): Address peer edit feedback

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

@@ -56,7 +56,7 @@ However, the goal of creating tickets is not to track writer time in detail. So
 
 ## Keeping tickets up-to-date [#lottery_factor]
 
-In general, you should write your tickets as though you might win the lottery tomorrow (a principle known as lottery factor or [bus factor](https://en.wikipedia.org/wiki/Bus_factor). In practice, 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 (a principle known as lottery factor or [bus factor](https://en.wikipedia.org/wiki/Bus_factor)). In practice, 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:
 

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

@@ -4,11 +4,12 @@ template: basicDoc
 topics:
   - Docs agile handbook
 ---
-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:
+Like most agile teams, we divide up the roles on our team into team members, scrum masters, product owners, and managers. We treat some of those roles differently than a traditional engineer-centric scrum team:
 
 - 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.
+- We divide the team further into two [squads](/docs/agile-handbook/key-concepts/agile-sprints-profusion-of-terms/#teams-and-squads), each with its own team members, scrum master, and product owners.
 
 ## Team member [#team_member]
 

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

@@ -43,7 +43,7 @@ We use GitHub projects for hero work, customer-reported issues, and managing the
 
 ![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_, one squad for each 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. 
 

src/content/docs/agile-handbook/sprint-mechanics/meetings-and-ceremonies.mdx

@@ -19,7 +19,7 @@ topics:
   <tbody>
     <tr>
       <td>_Week 1_</td>
-      <td>Sprint retro
+      <td>Sprint retro (every other sprint)
 
           Backlog grooming
       </td>
@@ -84,7 +84,7 @@ In the grooming, we:
 
 ## Retro [#retro]
 
-At the end of the sprint, we conduct a 60 minute retrospective meeting, where we discuss:
+Every other sprint, we conduct a 60 minute retrospective meeting, where we discuss:
 
 - How do we feel about the sprint?
 - What went well?