The unfortunate reality about software development is that if you keep doing what you’ve been doing, you’ll start slowing down. When you first start building a product with a small team, things move fast because everyone knows the codebase, and the team hasn’t accumulated any technical debt yet. This is true even if you don’t pay any attention to processes and structures just yet.
As the team and codebase grow, your existing work incements (for example, epics, stories, and tasks) end up taking much longer than they used to. As a result, it becomes slower to deliver software to the end users and to react to new knowledge or customer feedback. To reverse this trend, you’ll need to start measuring cycle time with the aim to decrease it.
To maintain a swift pace of delivery, your team should pay attention to every level of the flow of work from the bottom up: from commits and pull requests all the way up to your biggest projects and initiatives. If it looks like pull requests are taking too long to get through, you’ll want to start by fixing that bottleneck before you move up the hierarchy. If, on the other hand, your pull requests are already moving fast, you might want to start optimizing issue cycle time, meaning your tasks, stories, and epics. As you move up the hierarchy and start to optimize for bigger chunks of work, complexity increases. This is because completing a larger entity of work requires more collaboration and planning.
Ultimately, optimizing issue cycle time will help your team constantly deliver valuable features to your customers.
What is issue cycle time?
Issue cycle time captures how long your epics, stories, and tasks (or any other increments in which you plan your work) are in progress. Each team splits their work differently, so it’s good to note that issue cycle times are never directly comparable. For instance, if two teams are building the same product, it doesn't really matter whether that happens in two tasks taking ten hours each or five tasks taking four hours each.
The best way to measure cycle time for an issue is to look at the time it stayed “in progress” according to your issue tracker. Since the progression of an issue isn’t always linear, it’s important to differentiate between the time the issue has been actively worked on and the time between the first and last activity on the issue.
How to identify and fix 3 of the most typical problems software teams face with issue cycle time
If your issues are often delayed and it’s hard to estimate when they’ll be ready, it’s fair to assume that things could be better. It’s often better to start optimizing from the smaller increments of work to make sure you have the necessary pieces in place to optimize larger chunks. As a rule of thumb, if you’re happy with your average pull request cycle time and throughput, you’re ready to start optimizing issue cycle time.
After working with dozens of software organizations that have struggled with making progress with and completing their issues, we’ve noticed some common patterns. In our experience, three of the most common problems with issue cycle time are:
- Limited collaboration
- Multitasking
- Trying to solve problems that are too large
When you’re trying to optimize your issue cycle time, we recommend that you look into these three areas first to try to identify antipatterns you can start solving.
1. Not working as a team
Collaboration is a good place to start when you’re trying to identify antipatterns related to issue cycle time. Working together helps teams prioritize, reduce multitasking, and enforce better planning.
Having every team member work on their own projects might feel efficient because it means they don’t have to coordinate with others. However, building a great product and team is a long-term effort, and the benefits of collaboration far outweigh the costs.
Why should your team work together?
- Structuring your work with developer collaboration in mind forces you to be more thorough in the planning phase. This can help clarify the context for the team and reduce unknowns before the implementation.
- Tough problems become easier when you don't have to work on them alone. You're going to have an easier time sparring, rubber ducking, and getting your code reviewed faster, all of which will likely make your work flow better and reduce frustration.
- Too many competing priorities can lead developers and teams to work on simple, reactive tasks. Reactive tasks are easier to complete, but they’re not always the best use of your team’s time. It's often better to focus attention on properly solving a few problems that really matter, rather than struggling to solve too many problems at once.
How to identify siloing?
To identify problems in collaboration, you need to answer questions like, “How many people worked on a story?” and “Are we good at sharing work?” You’ll want to find out if there are enough contributors working together on issues.
Digging through your issue tracker, you might be able to tell whenever only a single contributor is assigned tasks on a story. Swarmia’s Work Log makes it easy to identify issues with a single contributor. This view shows the contributions made to any issue over time and helps you discover siloing quickly. If you repeatedly see only a single person working on larger issues, it’s a sign of lack of collaboration and sharing knowledge.
How to stop and prevent siloing?
The answer is fairly straightforward: just make sure to have multiple contributors on larger issues. However, getting this done in practice may not be as simple. There are many possible reasons for limited collaboration. And when you’re further investigating the issue, you might want to check whether the work is split into smaller chunks (which allows multiple developers to contribute) and whether the team is working on too many things at once. Identifying and solving these two challenges are covered below.
It might also be that people gravitate to working alone to avoid having to work with others. In this case, it might make sense to adopt a team-wide working agreement to avoid working alone on issues. Swarmia allows your team to adopt this working agreement (and many others) and get notified whenever there are exceptions. This way, you’ll know when people are working on their own projects and can take action to strengthen collaboration, improve knowledge sharing, and speed up the progress of top priority issues.
2. Working on too many things at the same time
There are typically more than enough features that your engineering teams could build at any given time. To make matters worse, there’s probably also pressure from your customers and internal stakeholders to do many of those things at once. This might lead to a situation where your team starts new work before they finish what they’ve started earlier.
Simultaneously working on too many issues will slow everything down and likely result in waste from incomplete work that will never be shipped. In addition, the issues that are visible in your project management software almost never tell the full story about what the teams are actually working on. There are always other priorities taking time away from completing your planned work. While it's not possible — or smart — to eliminate distractions completely, it's important to understand the effect of context switching on the cycle time of your high-priority items.
How do you know if your teams are working on too many things at once?
To identify whether you have a problem with multitasking, you need to know all the things your teams are working on at any given time. You might want to monitor the number of open epics, stories, and tasks over time and compare that to the number of developers in the team. To get a better grasp of what’s going on, you also need to check how much activity there is in the issues in progress. Whenever there’s too much work in progress, activity in issues starts to get patchy with gaps in pull requests related to the issue.
Most teams don’t have visibility into where their efforts go beyond what’s shown in the issue tracker. If this is the case, you can rely on qualitative feedback from the team by asking where they are using their time and how they feel about their current work in progress levels.
Ultimately, you want to ensure that multitasking isn’t preventing you from shipping your top priorities.
How to prevent working on too many issues at the same time?
Introducing a work in progress limit is one of the most effective ways to ensure that you’re not working on too many things at once. When the team has a work in progress limit, everyone is aligned on finishing some work before starting anything new. A good rule of thumb for the target number of stories in progress at once is the number of developers divided by two rounded down.
Work in progress limits are easiest to manage when they are tied to real data. Swarmia allows you to set work in progress limits on multiple levels. It automatically notifies you when you’re above your agreed limit. This way, you'll stay on top of your work in progress and can act fast if you’re drifting towards working on too many things at once.
3. Working in too big increments
When your projects seem to take too long to complete but your work in progress limits are under control, you may need to look elsewhere for solutions. One of the most common reasons for this is that you’re trying to solve too large of a problem at once. This is why you should critically evaluate the total scope of your issues.
However, there’s much more to planning than just the sheer scope of the issue. After all, it’s rare that upfront planning manages to account for all the tasks that end up going into an issue. That’s why you’ll also want to understand how the scope of your issues develops over time.
How to identify whether you’re working on too big of an increment?
To identify possible shortcomings in planning, you’ll want to take a look at how accurate your plans are and how they develop over time. Your goal is to ensure that the quality of planning is high.
Looking at how long it takes to complete issues is a good place to start. If an issue takes two times more than your average issue to complete, the scope might have simply been too large. Would it be possible to split that feature into smaller but still functional slices?
Looking beyond the sheer scope of the issue, you should also pay attention to how the scope develops over time and what kind of tasks are added. Having some amount of scope creep is totally okay. And to improve your estimates, you should always factor in some scope creep to your plans. However, if you’re often hitting 50%+ of scope creep on issues, there’s probably something in the planning process that could be fixed.
What to do if it looks like your projects are too big?
If it looks like the team is trying to solve too large of a problem at once, you may want to look into different strategies of splitting stories. The power of small stories to deliver more value for customers is well researched, and there are good strategies out there to slice your stories to optimize your issue sizes.
In contrast, if it looks like scope creep is the real problem, you should try to plan for the added scope. If you already know how much extra work you add on average (e.g. 20% more tasks), you can factor that into your plans. For example, this might mean three additional tasks and two extra days).
You can also start paying attention to certain types of tasks that tend to be added to the scope after starting and gradually increase the quality of your planning. It’s also common that challenges with scoping extend to the sub-tasks of the issue. There are often a couple of outlier tasks that take the longest to complete for some reason. Identifying long running tasks and thinking about if they could have been split somehow will also positively contribute to the quality of planning future issues.
Summary
Working alone on issues, working on too many things at once, and working in too big increments are three common antipatterns that can negatively affect your issue cycle time. To maintain your speed of delivery as your software organization grows, these three areas are worth taking a closer look into — especially as they’re usually connected. For instance, having too much work in progress may make it difficult to work together on issues.
If it looks like you’re facing one or more of these antipatterns, these actions can help you overcome them:
- Introduce work in progress limits to minimize context switching and speed up delivery
- Agree to always have multiple contributors working on issues to enforce team work
- Split stories to avoid working in increments that are too big
Finally, there’s a lot more to software development productivity than the flow of delivery and optimizing issue cycle time. To learn more about the topic, here’s a holistic approach that also covers things like business impact and team health.
