Intro

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

Prerequisites

KEY ASSUMPTIONS

STEP 1

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.

STEP 2

Set the tone

There are two principles you’ll need to establish as a team.

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?

STEP 3

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:

1. A ticket analysis of your slowest and fastest tickets to find patterns of what’s repeatedly slowing down or speeding up your work
2. A trend analysis across your data using Flow’s leading indicators
3. A process analysis of your team’s culture of delivery, such as meetings, onboarding, maintenance, and reviews

Ticket Analysis

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.

Trend Analysis

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.

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.

Process Analysis

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:

STEP 4

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.

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.

STEP 5

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:

Sprint Movement

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.

Ticket log

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.

Check-In

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.

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.

Financial savings

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.