How to increase software delivery speeds by reducing cycle time
In this playbook, we’ll dive into how to reduce cycle time so you can speed up development, knock down more of your roadmap, and better compete in your market.
As we’ve worked with hundreds of engineering teams, we’ve found repeatable methods to improve engineering practices, remove roadblocks, and enhance the developer experience.
The average cycle time reduction is an impressive 35%.
The key? Objective data balanced with qualitative feedback. This balance is particularly crucial in the retrospective meeting, so we’ll guide you on how to use this data with a retrospective lens.
As cycle time has become an important indicator of team health and development success, we’ve released new capabilities within Pluralsight Flow. This playbook will dive deep into these so you’re equipped to fully leverage Flow with your team.
Ready to reduce that cycle time? Let’s go.
Prepare for the retrospective
Set expectations for the team
If you’ve been hosting retrospectives for a while, communicate before the next meeting if it’ll be longer than usual. Start with an hour to include meaningful discussion around your data insights. Also, communicate that you’ll be using Flow data if you haven’t done so before.
Preview the data
You’ll use Ticket Log and Retrospective for your analysis. Open these reports and double-check the following:
- Are all team members represented? If anyone recently joined the team, add their information in your User Merge and Team Management settings.
- Are there any outliers that don’t make sense? Avoid confusing distractions. If anything stands out, check your configurations for the reports to see if anything is out-of-date.
- Are there any noticeable areas in need of improvement? If the team doesn’t know where to start with the data, prepare conversation starters.
Set the tone
There are two principles you’ll need to establish as a team.
Data will allow us to advocate for and operate better as a team—it’s not for analyzing individual performance.
Data should augment the qualitative conversations in a retrospective, not replace them.
It’s important that this conversation comes from a place of curiosity. You might have made your own conclusions with Flow’s data, but listen to your team’s thoughts to see if they align.
We’ve found these two classic lines of conversation beat all others:
- What should we stop, start, and continue doing?
- What did we learn?
This conversation doesn’t need to feel like a dry, repetitive meeting. Here are some suggestions to add levity into your retrospective:
- Have engineers take turns leading the meeting
- Start the meeting with an icebreaker, especially if there are new team members
- Include metaphors from your team’s favorite games, movies, or TV shows
Dive into the specifics
It's time for you and your team to dig into the data. For this analysis, you’ll find your team’s cycle time hotspots and accelerators. Hotspots are areas that slow down your cycle time and accelerators speed it up. They’re indicated by particularly slow and fast tickets, respectively.
There are three levels you’ll need to explore to find hotspots and accelerators:
- A ticket analysis of your slowest and fastest tickets to find patterns of what’s repeatedly slowing down or speeding up your work
- A trend analysis across your data using Flow’s leading indicators
- A process analysis of your team’s culture of delivery, such as meetings, onboarding, maintenance, and reviews
Start with the ticket-by-ticket analysis by going to Ticket Log. Click on cycle time to sort your tickets by longest cycle time. Set the time period to the last two weeks—these point to your recent hotspots. Ask your team, “What happened here?” Remember to ask with curiosity, not blame. Then ask, “What actions should we take to make sure cycle time isn’t that slow?”
Next, click cycle time again to re-sort the table and view the fastest tickets. Some of these tickets might be basic maintenance (fast by nature). Ignore these and focus on cycle times that are less than a day—these are your recent accelerators. Discuss with your team the root cause of the fast cycle times. Is that cause scalable across other tickets?
Last, find common themes across tickets. For each ticket that suggested a hotspot or accelerator, talk with the assignee to get their opinion on what happened. Be sure not to blame or overly credit the assignee; odds are the cycle time was partly due to factors outside their control.
The next step is to look at trends across your team to see a bigger picture of how the overall team is doing. You can do this by using the Retrospective report.
The first row of insights on Retrospective is to help identify a baseline and track overall trends. Easily see tickets completed, velocity (if you use story points), and, most importantly, median cycle time.
The second row is to determine the causes behind that baseline. Here’s how we use Retrospective to separate true insights from the day-to-day noise.
Median queue time shows the amount of time a ticket spends in a waiting state. This important metric starts the conversation around your processes. If your team takes a long time to review tickets or provide feedback, why is that? Are they overwhelmed with other requests? Do they feel pressured to prioritize their own projects? Median queue time will help you start these conversations.
Click on Sources of queue time to figure out where your tickets spend the most time waiting and use that data to refine overall feedback processes. Sometimes it’s as simple as recommitting the team to jump onto code reviews, but it can also help you make the case for additional team members or support from other teams.
Backflow rate gives you insights into how often and why tickets move backward in the development process.
This is an example of a Goldilocks metric: too high or too low can be signs of issues in your workflow. What you should care about more is why tickets moved backwards. Use the Sources of Backflow panel to determine that why.
- Robust code reviews are occurring, causing a ticket to revert to active development for refinement.
- Tickets are marked ready for development but lack articulate descriptions.
- Work is moving from active/review to UX and backlog due to indecision from leaders.
The key here is to use these insights to support better conversations, especially if you need other teams to improve. Rather than saying your team needs more articulate tickets, show that ambiguous requests lead to hours of wasted effort and longer-than-necessary cycle times.
Total jitter looks at the activity behind each ticket. The significance of these sources of jitter depends on how your team uses Jira or ADO. Learn how to configure Jitter here and prioritize Jitter insights based on what’s most relevant to your team.
At a minimum, focus on these four sources of jitter:
- Assignee change: Did your engineer feel too busy for this ticket? Or was another engineer more experienced in the ticket’s area? Either way, assignee changes can slow your cycle time.
- Robust comments by assignee: Comments from the assignee are a sign they don’t understand the ticket’s needs. This slows down cycle time because it requires a response from a product manager (PM), but it beats the alternative: an engineer creates the wrong thing.
- Robust comments by other participants: This might mean that a reviewer had to provide lengthy feedback on a ticket. Addressing that feedback will add cycle time.
- Description changed by assignee: This could be in response to a comment by an assignee, or a PM might change the requirements. If the assignee has already started working on the ticket, this results in wasted effort and increased cycle time.
Next, look at longer-term trends. Change your retrospective to view the last quarter instead of the last two weeks. Discuss with your team:
How does the data from your last quarter differ from the past two weeks? How is it the same?
If you’re seeing numbers that are substantially higher or lower than they were across the quarter, discuss that during your retrospective. Why did they spike or plummet, and was it positive or negative?
Address any concerning numbers and repeat your process for good numbers. On the other hand, if the numbers are largely the same, discuss which numbers you want to change and how to make it happen.
It’s important to have a regular cadence of retrospectives so you can address these questions as they come up.
The third level is to think about your larger process strategies. Here’s where your team’s unique context comes in—your cycle time is only as strong as your people. Using the information you found in your ticket-by-ticket and trend analysis, compile a full list of hotspots and accelerators you’ve discovered so far. Then talk about any hotspots or accelerators that might not have shown up in the data.
Here are some common process hotspots and accelerators:
|Changing product roadmaps
|Product managers communicating the why of all feature requests
|Knowledge silos between engineers
|Planning ahead for dependencies
|Breaking down work into subtasks
|Raising and clearing roadblocks
|Uncertain definition of ready
|Establish a definition of done
|Ineffective story grooming
|Communicate with developers on the exact work you're asking them to do
|Dependencies on other tickets
|Clear work prioritization
Set your action items
After this analysis, your whiteboard should be full of hotspots and accelerators. Identify the top three for each. Flow can help with identifying hotspots and accelerators, but you’ll need to implement changes in your processes based on what you discovered. Here’s what our team has found works best.
Start by talking about those top three hotspots. Work with your team to determine how to overcome them. Some solutions will be as easy as canceling meetings and others as complicated as hiring new headcount.
Identify three things with your team:
- Can we address this hotspot on our own?
- How can we address it?
- When can we address it?
Next, find ways to multiply your top three accelerators. Did you get lucky with these tickets, or is there something you can duplicate? More importantly, is it scalable? For example, let’s say one engineer’s cycle time was particularly fast because they cleared meetings for a day to focus on work. Have that engineer share with the team if they felt they missed out on the meetings and if they’d clear their schedule more often. Then talk with the larger team about if it’s feasible to clear more meetings.
Your action items should always be set up like a SMART goal: specific, measurable, achievable, relevant, and time-bound. For example, “decrease cycle time” isn’t SMART design, but “break my tickets into as many subtasks as possible by the end of the week” is.
Another way to get clarity on what makes a reasonable action item is to determine what’s in your control. You and your team can control the prioritization of tickets, who gets assigned which tickets, and the amount of subtasks for each ticket. On the other hand, you can’t control attrition, high-severity defects, or last-minute corporate meetings.
Make continuous, measurable improvements with Flow
Improving cycle time—and improving most engineering processes—is not a one-and-done process. As you onboard new engineers, develop new features, and create new systems, you’ll see your cycle time ebb and flow. Return to this process when you see things slow down, and remember that engineering metrics don’t operate in a vacuum; as you improve one metric, watch how other metrics also change.
It’s important to note that Retrospective isn’t the only report for impacting cycle time. Here are three reports to use regularly as a way to maintain cycle time and improve your processes in general:
This report is built for teams who use Scrum methodologies. Use Sprint Movement to determine how much unplanned work got added during sprints and its effect on workflow. Sprint Movement compares up to six sprints so you can see how your team is (or isn’t) improving across sprints.
Use Ticket Log during your stand-ups to get a quick visual of what your team is working on. Here’s where you’ll get insights into potential roadblocks for cycle time. Are engineers stuck on a ticket? Were they in too many meetings? Use Ticket Log to discuss these roadblocks before they negatively impact cycle time.
Your cycle time will always be as strong as your people. Use Check-In during your 1:1s with team members to find their strengths and areas of improvement, and then use this information to better plan and allocate work.
The case for cycle time and retrospectives
What is cycle time? At its most fundamental level, cycle time is the time between when work starts and ends on a ticket. By “starts,” we mean it’s defined as “active,” or someone is actively working on it. And by “ends,” we mean it’s been marked as “done” according to the team’s definition of done. The number is calculated by subtracting the task’s beginning timestamp from its ending timestamp.
We display the median cycle time within Flow because we know there will always be outliers for extremely slow and fast tickets; a median allows us to focus on general trends.
But why does cycle time matter? Cycle time gets at the heart of your delivery process. It shows how rapidly you’re moving units of work through your delivery pipeline. Looking at aggregate cycle time for a set of tickets completed during a workflow cycle—whether that's a sprint, the preceding month, or the first quarter of the year—can expose areas of inefficiency in workflow.
Engineering managers have competing priorities beyond the delivery process, such as team health and financial goals. Focusing on the delivery process actually helps with these other priorities and provides three main benefits: financial savings, faster time to market, and increased team morale. These benefits are cyclical; as you improve one, another improves.
Faster speed to market
When cycle time is fast, so is the entire delivery process. In addition, your process will be more predictable, which helps you plan and allocate resources for future delivery. All of that results in features that beat competitors, bugs that are quickly resolved, and happier customers all around.
Better team morale
Studies have shown that when employees are happy, they’re more productive. This creates a positive cycle: As engineers’ productivity improves, their happiness does as well, which makes them even more productive. But there are additional benefits with decreased cycle time, including better communication, an improved sense of direction, and increased collaboration—all of which improve team morale.
When we pair decreased cycle time with better completion rates, the efforts of software engineers and product managers shift to releasing features faster, fixing bugs, and clearing up technical debt. To be clear, decreased cycle time doesn’t mean a decrease in headcount. Instead, engineering teams can focus on the work that adds the most value to the team.
How to collect your data
When it comes to retrospectives, your data won’t get you far if it’s inaccurate. If you’re a manager, make sure you have the right data before presenting it to the team.
If you haven’t yet configured your delivery reports (Retrospective, Sprint Movement, and Ticket Log), visit this link. Flow will configure these reports automatically, but it’s important to check that this auto-configuration matches your team’s priorities. How can Flow calculate these metrics in a way that’s most meaningful and relevant to your team? Here’s a quick refresher on what each of these metrics measure. The more your team collaborates to customize this configuration, the better your insights.
Once you’ve configured this data, look at your Retrospective and Ticket Log reports. Now it’s time for some data hygiene. If you can’t measure your work because your data is inconsistent, improving your cycle time will be a constantly moving target.
Here’s a good start for troubleshooting common data issues. While you reviewed your data, did anything seem missing? If so, check your User Merge settings to make sure you’re representing all of your team’s work. If your data still seems off, start here and then go into your Jira settings. Are you labeling your tickets consistently? And is your team following the Jira practices you’ve set? If data is coming across as incomplete or incorrect, those are two frequent causes for data hygiene issues. Here’s a good starting point for Jira.
Understand the data
You’ll want to have a baseline understanding of the data before meeting with your team.
To start, open Retrospective. Filter by your team and select “Trailing 14 days” for your timeframe. This will give you insight into what’s going on right now with your team. (We’ll explore longer-term data later.) Click “Compare to: Three periods” to check if these two weeks reflect a baseline for your team. Retrospective will then display arrows that show if your data from the past two weeks is above or below average compared to these periods.
Focus on the top row to define your baseline with Retrospective:
- Tickets completed: Do you have goals for how many tickets you completed in a given period? If so, how does this number match up?
- Velocity: Consider you story points. Number of tickets completed is great as a general guide, but velocity will start to show you the scope of the work you completed.
- Median cycle time: What was your average cycle time over the last six periods? And how does it compare to your last two weeks? Flow uses median instead of average cycle time to get rid of any outliers that might skew the data in either direction.
We often hear that teams want to know how they’re doing compared to the rest of the industry. It’s valuable information, but we’ll add a huge caveat. Every team has a different reality for what’s achievable. Industry benchmarks give you an outside perspective, but their main purpose is to help you start a conversation with your team and leaders. If your numbers are much lower, consider what might be taking your team longer than the industry. Perhaps you have a legacy system, staffing shortages, or a complicated roadmap. All these need addressing—and they mean that your team’s cycle time isn’t reflective of their work.
For Scrum teams, the Sprint Movement report can give further insights into your cycle time. Open Sprint Movement and select your last six sprints. For each sprint, look at the list of tickets completed and review their cycle times. Sort by cycle time to review your slowest tickets. Is there a common theme? Do the same for your fastest tickets.
Next, recall the tickets completed metric that you found with Retrospective. Look at your completion rate across these sprints. Did your team complete its sprint commits, or did they get distracted by added work? Did the added work have a faster or slower cycle time than the committed work? The answers will help you and your team plan and prioritize your work.
What if we don’t use Jira or Azure DevOps (ADO services or Azure boards)?
If you’re not using Jira or Azure DevOps, you won’t be able to use our Retrospective report, but you can still hold retrospective meetings. Focus on the Team Health Insights report, particularly these five metrics:
- Coding days: How many days does your team spend coding per week? This will impact your cycle time.
- Efficiency: Make sure your developers are working on work that moves cycle time forward. Within Flow, we define that as the percentage of work that didn’t churn. If your efficiency is less than 50%, you’ll want to troubleshoot to see where your teams can improve on their code.
- Time to first comment: How quickly is your team reviewing each other’s work? The faster they respond, the faster your cycle time.
- Time to merge: For most teams, the PR process can be one of the biggest bottlenecks. Look at this metric over time to get a better understanding of your PR process.
- Thoroughly reviewed PRs: Speed should never be at the expense of quality. Make sure your team is thoroughly reviewing each other’s work and not just rubber-stamping it. Flow measures the quality of reviews, which is a good way to see if people are giving meaningful feedback.
Prepare for your next retrospective
Plan for your next retrospective before you end the current one. What do you want to achieve, what amount of effort would that achievement require, and what do you expect to achieve given that effort? Once you’ve defined your action items, create an experiment around them.
Think of these changes like a science experiment, complete with the scientific method.
- Start with your observations. Which are your accelerators and your hotspots?
- Determine the area of focus.
- Come up with a hypothesis for how your accelerator or hotspot might affect cycle time.
Run your experiment. Here are a few of our favorites:
- Run through a sprint or engineering cycle with as few meetings as possible. Which meetings did the team miss and which can you skip?
- Be critical about adding scope or tickets. What happens if the team focuses only on the most important tickets?
- Set aside time for reviews each morning. Was your team able to use that time to review everything faster while they still felt fresh?
- Change your definition of done.
- Measure your cycle time before and after each experiment. Did it change and by how much?
- Come up with a conclusion on what your team needs to do moving forward.
Repeat your retrospectives
Like all engineering ceremonies, retrospectives should have a regular cadence. Try to meet weekly, bi-weekly, or monthly and host a longer discussion quarterly. In addition, host longer retrospectives if you onboard more team members, hire a new team leader, or implement any large cultural changes.
Structure of a retrospective
Tips & Tricks
But wait, there’s more! Here are a few additional tips and tricks to ensure you get the best ROI on your retrospectives:
Be strategic about planning
- Break down tasks as much as possible
- Determine what's most important
- Get up-front agreements
Use the tools available to you
- Flow will help you establish a baseline, but it will also help you measure progress while you implement these changes. As a quick note, if you change your workflow or processes, make sure that Flow’s configurations still match your teams’ work.
- Methodologies like Lean and Agile are popular for a reason. If your team isn’t already using these methodologies, consider experimenting with them to see if they help.
- Education will help your developers upskill and code faster without losing quality.
- Product managers can help remove barriers, prioritize tickets, and motivate the team with the purpose of their work.