Add doc on planning poker | Agile handbook

My first contribution to the repo on an M1 mac. Exciting!

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

@@ -16,7 +16,7 @@ topics:
       <th>Friday</th>
     </tr>
   </thead>
-    <tbody>
+  <tbody>
     <tr>
       <td>_Week 1_</td>
       <td>Sprint retro
@@ -41,7 +41,7 @@ topics:
       <td></td>
       <td>Meeting-free day</td>
     </tr>
-    </tbody>
+  </tbody>
 </table>
 
 We break our work into two-week sprints. The new sprint starts on a Tuesday with Sprint Planning, where we commit to a set of stories that we're confident we can complete by the end of the sprint. Near the end of the sprint, we prepare for the next with Backlog Grooming. The sprint closes with a Retro where we discuss what went right and what went wrong, and then we kick off a new Sprint Planning meeting. 
@@ -50,7 +50,7 @@ Each squad does their own Backlog Grooming and Sprint Planning, and manages thei
 
 <Callout variant="tip">
 Why do we end sprints on Mondays and start Tuesdays? This funny schedule makes things easier to work across timezones. If we ended sprints on Fridays, our Barcelona-based writers would need to do retros and grooming on Friday evening, and who wants that?
- </Callout>
+</Callout>
 
 ## Sprint planning [#sprint_planning]
 
@@ -88,4 +88,8 @@ At the end of the sprint, we conduct a 60 minute Retrospective meeting, where we
 - Where can we improve?
 - Anything we should start or stop doing?
 
-The goal of the Retro is to improve the way we work together. That could be related to the sprint process, to how we collaborate with SMEs, to peer edits, and so on.
+The goal of the Retro is to improve the way we work together. That could be related to the sprint process, to how we collaborate with SMEs, to peer edits, and so on.
+
+## 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).

src/content/docs/agile-handbook/guide/planning-poker.mdx

@@ -0,0 +1,92 @@
+---
+title: "Planning poker and points budgets"
+template: basicDoc
+topics:
+  - Docs agile handbook
+---
+
+Planning poker is a consensus-based estimating and planning technique. To start a planning poker session, the story reporter or [liaison](3379_INSERT_LINK_HERE) presents a story to the team. Then, the team all votes (at the same time, to prevent groupthink) on how difficult they think the story is.
+
+Most agile teams that estimate with planning poker use cards that follow a Fibonacci sequence. We've found over the years that those large jumps weren't very helpful to us in estimating, and that we estimated better with smaller numbers. So we use fairly small, granular numbers that roughly break down to 1 point ≈ 1 day.
+
+Note that even though each of the possible scores have approximate time values associated with them, we vote in points, not time. Scoring with points prevents getting into weedsy debates about exactly how long something will take, and instead focuses us on the requirements and difficulty of the story.
+
+## Poker card definitions [#poker_card_definitions]
+
+These how we define our poker cards:
+
+<table>
+  <thead>
+    <tr>
+      <th>Card</th>
+      <th>Value</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td>¼</td>
+      <td>An hour or two. Anything smaller than this isn't worth bringing into a sprint or even ticketing—just do it right now.</td>
+    </tr>
+    <tr>
+      <td>½</td>
+      <td>About half of an "ideal" day. We define an "ideal" day as one without meetings or interruptions. Using "ideal" days makes it easier to estimate a story without litigating the details of how we spend our time.</td>
+    </tr>
+    <tr>
+      <td>1</td>
+      <td>About one "ideal" day. This is one of our most common story sizes.</td>
+    </tr>
+    <tr>
+      <td>1½</td>
+      <td>About one and a half "ideal" days. This is our other most common story size.</td>
+    </tr>
+    <tr>
+      <td>2</td>
+      <td>About two "ideal" days.</td>
+    </tr>
+    <tr>
+      <td>3</td>
+      <td>About three "ideal" days. We jump from 2 straight to 3 to avoid unrealistic granularity in our estimates.</td>
+    </tr>
+    <tr>
+      <td>5</td>
+      <td>About a week of work.</td>
+    </tr>
+    <tr>
+      <td>7</td>
+      <td>About a full sprint (two weeks) of work. We very rarely use this card—a ticket that takes a full sprint on its own is almost always too large and should be chunked into smaller, incremental tickets.</td>
+    </tr>
+    <tr>
+      <td>Break!</td>
+      <td>"I need a break." When someone plays a break card, we finish estimating the current story then immediately take a five minute break.</td>
+    </tr>
+    <tr>
+      <td>Defer</td>
+      <td>No strong opinion. Don't play this card on the first round of poker! Seeing wildly different estimates is a sign we don't have a shared understanding of the work. Playing an early Defer card can mask that uncertainty.</td>
+    </tr>
+  </tbody>
+</table>
+
+## How we calculate the points budget [#points_budget]
+
+In order to ensure we're not filling up our sprint with more "ideal days" of time than we realistically have available, we calculate the points budget based on the actual output of the team. Over time, we've found writers average 0.6 (technically, 0.57) points per day.
+
+<Callout variant="tip">
+  This value is totally unique to each team! A high number doesn't indicate a more productive team, and a low number isn't a problem. Story points are only meaningful within a team.
+
+  If you're starting a new team or new process, you'll need to zero in on the ideal number of points per writer. An easy way to figure out the right budget is to have the team vote in retro on whether to increase, decrease, or keep the same budget next sprint. You'll overshoot or undershoot a few times, but after a couple sprints you'll get a good sense of what constistutes a sustainable pace.
+</Callout>
+
+Once you know your baseline, calculating the budget is straightforward:
+
+1. Take the number of writers, and multiply by the number of days in the sprint. 
+    - To make the math easy, let's say 5 writers and a 10 business day (2 calendar week) sprint. Or, 50 person-days total.
+2. Subtract out time off days, plus 1 day for each day of [hero duty](3379_INSERT_LINK_HERE).
+    - Let's say we have 1 writer on vacation in Maui, and 1 day of hero time per day. 50 person days, minus 10 days of vacation and 10 days of hero time, gives us 30 person-days.
+3. Multiply the number of days times the average velocity per writer, per day.
+    - Our average velocity is 0.6 points/writer/day. 30 person days multiplied by 0.6 would give us an 18 point budget for the sprint.
+
+Because we work in two [squads](3379_INSERT_LINK_HERE), we calculate a separate points budget for each squad ahead of sprint planning.
+
+## 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).

src/nav/docs-agile-handbook.yml

@@ -15,3 +15,5 @@ pages:
       path: /docs/agile-handbook/guide/agile-roles
     - title: "Meetings and ceremonies"
       path: /docs/agile-handbook/guide/meetings-and-ceremonies
+    - title: "Planning poker"
+      path: /docs/agile-handbook/guide/planning-poker