How Tickets Influence Team Performance
How poorly written tickets can impact team performance and how data-driven methods can turn it around.
Working with various teams throughout the years has shown me how important it is to write clear backlog tickets. They need to be short but give enough detail to explain what needs to be done.
Clear communication is crucial in any team environment, especially when managing complex projects. Poorly written tickets can lead to confusion, wasted time, and increased frustration. This article explores how clear, concise tickets can significantly enhance team performance, with a focus on practical, data-driven solutions.
Signs and metrics that point to a problem
Frustration is piling up
When a ticket isn't clear, two common issues arise. First, the engineer might start the task but soon have questions, leading to time-consuming discussions with the ticket's author, usually the Product Owner. Alternatively, and more problematically, the team may work on the task under a misunderstanding, resulting in output that needs to be completely redone.
Such situations are incredibly frustrating for the team, often leading to complaints during meetings like:
"The scope of the ticket was unclear, so I had to spend extra time clarifying it before I could start."
"Even after reading the ticket, I'm still not sure what is expected."
These complaints highlight the issue, but to understand how it truly affects team performance, we need to look at specific data points.
The recidivism rate is high
Recidivism, or rework, refers to the number of times a task is sent backward in the workflow. For instance, if our workflow stages are InProgress > CodeReview > Testing > Deployment, a ticket should ideally move from one status to the next without regression. We calculate the recidivism rate as follows:
Recidivism Rate = (Number of stories that regressed to a previous status / Total number of stories resolved) x 100
Consider the next 10 tickets as an example:
8 tickets progressed smoothly from InProgress to Deployment.
1 ticket moved from InProgress to CodeReview, then regressed back to InProgress.
1 ticket reached Testing, then regressed back to InProgress.
This results in a recidivism rate of 20%.
In my teams, where we primarily use Jira, I check the ticket history to view all transitions. Alternatively, team members can mark each regression on the ticket with a counter or label, or we could use existing plugins to track these movements.
We will store the data so we can make graphics with it:
In this team, we collected the recidivism rate for 100 tickets completed, which took around 6 weeks. We show this data to the team to bring awareness of the time that is lost and how the situation doesn’t get better over time.
The Cycle time reveals bottlenecks
Frequent misunderstandings often create bottlenecks at the 'InProgress' stage, leading to unnecessarily long cycle times as tasks pile up
To analyze cycle time bottlenecks effectively, start by reviewing the data as a team. Focus on tickets with the highest cycle times and discuss these with the team to identify any common patterns or issues.
Here we observe a quite big overall cycle time value and several outliers with the same pattern.
For a detailed guide on how to do this analysis, you can check my guide.
There are several reasons behind observing this pattern. It's crucial to pair this data with insights into its origins. For this team, the pattern indicates that engineers were spending time on clarification discussions rather than executing tasks. Moreover, during code review or testing phases, misunderstandings would surface, resulting in tickets being sent back to the InProgress status.
I suggest we ask the team to look at this data during their retrospective and focus on improving the data trends as soon as possible. Here is a guide to a data-driven retrospective.
How to solve this situation
It's just as crucial to include relevant information as it is to exclude irrelevant details. This isn't easy, so we will adopt a systematic approach in this team and steer clear of improvisation and scattered thoughts.
Our focus will be on using a straightforward template for each ticket we create.
Strategy 1: Use existing templates
For tickets involving user stories (where we develop features impacting our users), we will adhere to a template based on Behavior-Driven Development (BDD). The goal of BDD is to facilitate straightforward communication between the business, the team, and the systems.
Our template emphasizes articulating all scenarios of the feature we aim to develop in a clear and structured manner:
The person writing the ticket will collaborate with the business to translate their ideas into a structured template, aiming to cover all functionality through multiple user cases.
To ensure we capture all possible scenarios with the business stakeholders, we will employ a series of questions:
“Can you give me a scenario where that happens?”
“Can you give me an example?”
“Is there any context in which the action leads to a different scenario?”
Our focus will be on establishing a shared understanding of the scope first. Once the scope is crystal clear to everyone, then additional details can be added.
If you need more details and examples I recommend this detailed article.
Strategy 2: Create your own templates
By conducting a simple workshop, we can empower the team to create their own templates. From my experience, these templates may need to be reviewed and adjusted over time as we better understand which information is essential and which isn't. Initially, however, we can start with something very basic.
The workshop should initially focus on keeping the templates very simple. We can begin by asking the team, 'What is the minimum information we need to start working?' This question helps us frame our first template to be more focused and straightforward.
Conclusion
Understanding the impact of ticket quality on performance through data, and adopting a systematic approach to writing tickets, will enhance efficiency. Over time, we'll see improvements in rework percentages and cycle times, indicating that the team's performance has improved.