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 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.
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.
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.
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.
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, ready for peer review, or it becomes blocked. If additional large edits are needed after the peer review, the ticket can be moved back to In Progress for those edits.
Work that is ready for a peer edit. Once a peer editor picks it up, they move it into In Peer Edit.
This step is for a peer editor to review docs before they go live. Follow the Peer editor workflow, then move the ticket into 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 ticket should be moved back into the In Progress column.
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.
This step is for work that is 100% finished. Work gets cleared out this column before we start a new sprint.
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:
- Clone the ticket.
- Note why we closed the ticket.
- Add an estimate of points completed in the Points Completed field.
- Create a follow-up ticket if necessary.
- Move the ticket to the next sprint. If you do:
- Review the ticket's action items and description to make sure they're still current.
- Clear out the ticket points.
- Move the ticket back to the backlog. If you do:
- Update the action items and description to make sure they're still current.
- Note why we moved to the backlog rather than carry over.
We welcome thoughts or questions on our handbook! The easiest way to get in touch is to file a GitHub issue.