Add details of sprint board and workflow | Agile handbook

src/content/docs/agile-handbook/sprint-mechanics/sprint-workflow.mdx

@@ -0,0 +1,83 @@
+---
+title: "Sprint workflow"
+template: basicDoc
+topics:
+  - Docs agile handbook
+---
+
+Our sprint workflow in Jira depends on what type of work we're dealing with: Planned work, unplanned ("surprise!") work, or self-service edits that came in through the hero process.
+
+## Planned work [#planned_work]
+
+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]
+
+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. 
+
+### Future Sprints [#future_sprints]
+
+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. 
+
+### Current Sprint [#current_sprint]
+
+#### 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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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.
+For each open story assigned to you (or "carry over"), decide if you should:
+
+- **Recommended: Clone the story and close the old one.** This is the best option for partially completed work because it maes metrics easier. If you do:
+    1. Clone the story.
+    2. Note why we closed the story.
+    3. Add an estimate of points completed in the Points Completed field.
+    4. Create a follow-up story if necessary.
+- **Move the story to the next sprint.** If you do:
+    1. Review the Jira's action items and description to make sure they're still current.
+    2. Clear out the story points.
+- **Move the story back to the backlog.** If you do:
+    1. Update the action items and description to make sure they're still current.
+    2. Note why we moved to the backlog rather than carry over.
+
+## 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

@@ -23,3 +23,5 @@ 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