Sprint workflow

All of our sprint work is tracked in Jira. The workflow depends on what type of work we're dealing with: Planned or unplanned ("surprise!") 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.

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, 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.

Jira boards: Backlog and future sprints

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. 

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. 

Jira boards: Current sprint

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 ticket, 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 ticket. 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

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. Tickets are moved to this step once work is started by the TW, and remain here until the work is either complete or it becomes blocked.

When you need your work reviewed, keep the ticket in this column, and move your corresponding PR into the GitHub Needs review column. Be sure to ask a colleague directly for a peer review. If you successfully finish the work after the review process, you can close the issue. If you encounter obstacles, you can put the issue into Blocked or clone it as a carry-over for another sprint.

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 tickets 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 it's work that can be safely held. (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 ticket to the appropriate column. If the ticket remains blocked at the end of the current sprint, it will need to be re-reviewed during backlog grooming to determine if the ticket will carry-over into the upcoming sprint, or return to the backlog until a future sprint.

Done

This step is for work that is 100% finished. Work gets cleared out this column before we start a new sprint.

Incomplete ("carry-over") tickets

Ticket don't carry over automatically between sprints. Instead, any ticket that gets carried over is treated as a "new" ticket 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 ticket assigned to you (or "carry over"), decide if you should:

• Recommended: Clone the ticket and close the old one. This is the best option for partially completed work because it makes metrics easier. If you do:
  1. Clone the ticket.
  2. Note why we closed the ticket.
  3. Add an estimate of points completed in the Points Completed field.
  4. Create a follow-up ticket if necessary.
• Move the ticket to the next sprint. If you do:
  1. Review the ticket's action items and description to make sure they're still current.
  2. Clear out the ticket points.
• Move the ticket 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.