feat(agile handbook): Create placeholder docs for heroing

src/content/docs/agile-handbook/heroing/managing-the-github-board.mdx

@@ -0,0 +1,6 @@
+---
+title: "Managing the GitHub boards"
+template: basicDoc
+topics:
+  - Docs agile handbook
+---

src/content/docs/agile-handbook/heroing/whats-a-hero copy.mdx

@@ -0,0 +1,6 @@
+---
+title: "What's a hero?"
+template: basicDoc
+topics:
+  - Docs agile handbook
+---

src/content/docs/agile-handbook/sprint-mechanics/sprint-workflow.mdx → src/content/docs/agile-handbook/sprint-mechanics/sprint-workflow-and-jira-boards.mdx

@@ -11,56 +11,54 @@ Our sprint workflow in Jira depends on what type of work we're dealing with: Pla
 
 Planned work includes all work that is currently in our backlog or has been added to the current sprint as a result of a Sprint Planning session. This could include writing or updating documentation, research, meeting with SMEs, information architecture, incorporating peer edits, SME review, and so on. It does not include self-service edits or urgent doc requests, which are covered in the [Unplanned work](3379_INSERT_LINK_HERE) and [Self service and hero work](3379_INSERT_LINK_HERE) sections.
 
-### Backlog [#backlog]
+## Unplanned work (surprises) [#unplanned_work_surprises]
 
-This is where the vast majority of tickets spend their time. Most tickets (even for active projects) spend at least a little time here before moving into a sprint to be actively worked. Being in the backlog doesn't mean something isn't important---just that we haven't committed to it yet. 
+Usually, we get notified of major requests far enough in advance that we can include them in liaison project plans, backlog grooming, and sprint planning. Occasionally, of course, something bigger surprises us that needs emergency support.
+
+Follow this process with new docs asks to assess the scope of work and ensure we address valid docs needs within a reasonable amount of time. Our goal is to treat the sprint as sacred and insulate against "surprise" work that is not absolutely crucial. But we also want to ensure we're providing good internal customer service, and not getting hung up on process niceties for things that are small.
 
-### Future Sprints [#future_sprints]
+![The best way to deal with interrupts depends on how much time it takes, and whether the interruption is related to work already in the sprint. For things less than 20 minutes, just do it! For larger interrupts, you should get an estimate from the rest of the team.](./images/dealing_with_interrupts.png "Workflow and tips for dealing gracefully with interruptions.")
+
+## Backlog and future sprints [#backlog]
+
+This is where the vast majority of tickets spend their time. Most tickets (even for active projects) spend at least a little time here before moving into a sprint to be actively worked. Being in the backlog doesn't mean something isn't important---just that we haven't committed to it yet. 
 
-This is where tickets tentatively assigned to a future sprint will be found. Tickets can be assigned here to be held for future sprint work before moving into the To Do column after the Sprint Planning session for that sprint. 
+You can also add tickets straight to a future sprint. This is where tickets tentatively assigned to a future sprint will be found. Tickets can be assigned here to be held for backlog grooming and sprint planning. 
 
-### Current Sprint [#current_sprint]
+## Current Sprint [#current_sprint]
 
-#### Proposed [#proposed]
+### Proposed [#proposed]
 
 This step is for work that has been assigned to the current sprint during Sprint Planning and is available to be picked up by a tech writer. When you're ready to take on a new story, try to work the queue from the top-down and avoid cherry picking. It's also better to pick up Needs Peer Edit tickets before committing to a new story. Something that needs a peer edit is close to done, and helping things across the finish line helps get value into users hands, and frees us up to think about new problems.
 
-#### In Progress [#in_progress]
+### In Progress [#in_progress]
 
 This step is for all of the work to be done by the assignee: Research, meeting with SMEs, information architecture, writing, incorporating peer edits, SME review, and so on. Stories are moved to this step once work is started by the TW, and remain here until the work is either complete, ready for peer review, or it becomes blocked. If additional large edits are needed after the peer review, the story can be moved back to In Progress for those edits.
 
-#### Needs Peer Editor [#needs_peer_editor]
+### Needs Peer Editor [#needs_peer_editor]
 
 Work that is ready for a peer edit. Once a peer editor picks it up, they move it into In Peer Edit.
 
-#### In Peer Edit [#in_peer_edit]
+### In Peer Edit [#in_peer_edit]
 
 This step is for a peer editor to review docs before they go live. Complete all steps in [Docs Peer Editing Process](3379_INSERT_LINK_HERE), then move the story into Peer Edit Done. 
 
-#### Peer Edit Done [#peer_edit_done]
+### Peer Edit Done [#peer_edit_done]
 
 This step is a holding state once peer editing is complete. After completing their peer edit and delivering their feedback, the peer editor moves the ticket into Peer Edit Done. From there, the assignee on the ticket (not the peer editor) moves the ticket into the appropriate column (In Progress, Blocked, or Closed). Minor edits can be completed from this column but for major doc rework, the Jira should be moved back into the In Progress column.
 
-#### Blocked [#blocked]
+### Blocked [#blocked]
 
 This step is for tickets that cannot be moved forward by the team. This could be because we're waiting for a response from a SME, or for a feature to deploy, or for final signoff. The team keeps an eye on this column for stories that may need escalation. Putting something in Blocked rather than In Progress lets us see the status of every ticket at a glance.
 
 This column can also be used for extended time out of the office for the assigned writer. If the work cannot be held while you're out, find another writer to step in and take over. 
 
 Once you're un-blocked, move the Jira to the appropriate column. If the jira remains blocked at the end of the current sprint, it will need to be re-reviewed during backlog grooming to determine if the jira will carry-over into the upcoming sprint, or return to the backlog until a future sprint.
 
-#### Done [#done]
+### Done [#done]
 
 This step is for work that is 100% finished. Work gets cleared out this column before we start a new sprint..
 
-## Unplanned work (surprises) [#unplanned_work_surprises]
-
-Usually, we get notified of major requests far enough in advance that we can include them in liaison project plans, backlog grooming, and sprint planning. Occasionally, of course, something bigger surprises us that needs emergency support.
-
-Follow this process with new docs asks to assess the scope of work and ensure we address valid docs needs within a reasonable amount of time. Our goal is to treat the sprint as sacred and insulate against "surprise" work that is not absolutely crucial. But we also want to ensure we're providing good internal customer service, and not getting hung up on process niceties for things that are small.
-
-![The best way to deal with interrupts depends on how much time it takes, and whether the interruption is related to work already in the sprint. For things less than 20 minutes, just do it! For larger interrupts, you should get an estimate from the rest of the team.](./images/dealing_with_interrupts.png "Workflow and tips for dealing gracefully with interruptions.")
-
 ## Incomplete ("carry-over") stories [#incomplete_carry-over_stories]
 
 Stories don't carry over automatically between sprints. Instead, any story that gets carried over is treated as a "new" story in the next sprint planning. Before sprint planning, review any open tickets in the board that are assigned to you and figure out what to do with them.

src/nav/docs-agile-handbook.yml

@@ -23,7 +23,13 @@ pages:
         path: /docs/agile-handbook/sprint-mechanics/meetings-and-ceremonies
       - title: "Planning poker"
         path: /docs/agile-handbook/sprint-mechanics/planning-poker
-      - title: "Sprint workflow"
-        path: /docs/agile-handbook/sprint-mechanics/sprint-workflow
+      - title: "Sprint workflow and Jira boards"
+        path: /docs/agile-handbook/sprint-mechanics/sprint-workflow-and-jira-boards
       - title: "Liaisonships"
         path: /docs/agile-handbook/sprint-mechanics/liaisonships
+  - title: "Heroing"
+    path: /docs/agile-handbook/heroing
+      - title: "What's a hero?"
+        path: /docs/agile-handbook/heroing/whats-a-hero
+      - title: "Managing the GitHub boards"
+        path: /docs/agile-handbook/heroing/managing-the-github-boards