How can I track interruptions in a sprint using ZenHub?
Whether your team wants to get better at protecting time during a Sprint to become more reliable with deadlines, or are looking to get more insight into processes to improve, we share more on tracking processes improvements using Velocity.
A common scenario: last minute high critical bugs continue to delay other planned project works within a sprint.
Rather than just fixing the bug, we recommend implementing a solution to track how often this happens! In the spirit of continuous improvement, this will give your team insights better QA testing to avoid high critical bugs disrupting future sprints, we recommend using a combination of labels on Issues and Velocity reporting.
Create a label via GitHub for tagging disrupters
Create a new Sprint Disruption label with a description that outlines it's used to tag Issues that get added unplanned to Sprints will do the trick!
Not sure how to create labels? We cover more on creating labels in this guide.
New process for labelling and tracking disruption Issues
Anytime an Issue gets worked on that didn't go through the typical flow of your refinement and sprint planning, but gets worked on during the Sprint, be sure to:
- Create an Issue to track the work, no matter how small the task
- Assign your new Sprint Disruption label to the Issue
- Assign the Issue to the Milestone in flight
Reviewing sprint disruption Issues
Periodically, we recommend pulling up a list of Issues in the Issue page in GitHub with the Sprint Disruption label to review common themes.
Where the disruptions all the same type of Issue? High security items or perhaps low priority bugs? These trends will point to a process area needing a review. If most disruptions are low priority bugs, perhaps adding in a checkpoint triage to ensure low priority bugs get slotted in for future sprints will help.
If they're high priority security bugs, how can you incorporate security reviews into your acceptance criteria for future projects to avoid bugs creeping up after the fact?
Filter by labels on the Velocity Chart
Adding labels to Issues not only allows you to easily pull up closed Issues for a historical analysis, but also powers the filtering on the Velocity Chart.
Filtering the Velocity chart allows teams to break down how many story points were closed sprint-over-sprint using a subset of data. This gives additional insight on how team efforts have been spent over the last sprints. Review the complete guide on Velocity here.
Using label tracking, teams will be able to detect trends to improve processes and increase productivity.
For example, adding the bug and urgent labels to your Velocity Report provides answers to questions, such as “How much of our time was spent addressing urgent bugs over the last few sprints?” or “How has our new QA/Code Review process been working to address bugs before releasing?”
With the added Sprint Disruption workflow, you'll be able to understand how many urgent bugs that were disrupters went into the previous Sprints.
When working on disruption Issues, it's easy to get caught up in recency bias, feeling like Sprint work gets disrupted frequently, and projects are off-track perhaps due to disruptions. The Velocity filtering using labels is a good quantifiable check on that hypothesis, allowing you to see historically in the past 7 Sprints, whether there were truly disruptions.
This process is only as good as the team's habits are for Issue creation and labelling!
You can of course historically label closed Issues, assign them to the closed Milestone, and look back on the Velocity after-the-fact. But, the more accurate you can do this in real time, the easier it'll be for the team to stay on track with live-tracking and insights.