Optimizing issue cycle time
Practical tips and best practices for improving your focus and structuring work to reduce issue cycle times.
Last updated
Was this helpful?
Practical tips and best practices for improving your focus and structuring work to reduce issue cycle times.
Last updated
Was this helpful?
Was this helpful?
As the complexity of a software organization and codebase increases, the teams in the organization face new challenges. Teams find themselves in an environment of team and system dependencies, and an increasing number of problems competing for their attention, including legacy systems and technical debt.
If the teams keep on doing what they've been doing, their existing work structures (for example Epics, Stories and Tasks) end up taking much longer than what they used to. As a result, the teams become slower to deliver software to the end-users and to react to new knowledge or customer feedback.
To reverse this trend, teams need to start measuring cycle time with an aim to decrease it. Retrospectives and working agreements are both great tools for turning cycle time insights into systematic action, like limiting work in progress.
These actions should be accompanied by structuring and breaking down the work with a goal of optimizing for cycle time and team collaboration.
The cycle time of any software work is the amount of time from the start of development work until the end result reaches the customer. For issues, the most understandable way to measure this is to look at the time it stays In Progress, based on the issue tracker status. In practice, the time spent in progress can often be split into multiple steps (e.g. a separate step for any time that an issue spends in review) – in which case you want to look at the combined time spent in these statuses (refer to these instructions to configure this on Swarmia).
Since the progression of issues is not always linear, it is important to be able to differentiate between the time the issue has been actively worked on, and the time between the first and last activity on the issue. There are valid reasons for pausing work on an issue – perhaps there's a critical bug in production, or perhaps the team had to revisit some assumptions about the problem and redesign the solution – but it's important to know when this happening.
Swarmia automatically calculates key properties and metrics (such as active time, lifetime and flow efficiency) for each issue to allow investigating how they went and what could have been done better.
In software teams the issues that are visible in your project management software almost never tell the full story about what teams are actually working on. There are always other priorities taking time away from completing your planned roadmap work. It's not possible (nor wise) to eliminate distractions completely, but it's important to understand the effect of context switching on the cycle time of your high-priority items.
It can be easy to get lost in the sea of problems and day-to-day work, especially without a proper way to measure what kind of work a team is spending their time on.
Swarmia's Work Log view is a good place to start understanding the full breadth of work in progress. You'll also get a view on work you think is in progress but doesn't have any real activity in a separate section.
Clicking on any issue to open the activity popup will reveal its flow efficiency – a lean metric telling you the proportion of days you have actively worked on the issue during its lifetime. If the issue has low flow efficiency and you did not work on it the whole time this often indicates having too much work in progress simultaneously. This symptom is also visualized on the work log as an absence of regular day-to-day activity on stories in progress.
If it looks like you are working on too many things at once, hindering the progress of your top priorities, consider adopting a working agreement limiting the work in progress. This way you'll stay on top of your work in progress and can act fast if you are drifting towards working on too many things at once. A good rule of thumb for the target number of stories in progress at once is Math.floor(number of devs / 2).
You can set working agreement targets for the amount of issues in progress (eg. "No more than three stories in progress at once"). Learn more about working agreements.
When work slows down, the effect is usually most obvious with the larger units of work. When stories start to take up to a month and epics more than a few months, the team can usually feel that things start to feel slow. Decreasing cycle time at this level can have a significant impact not only on the team's velocity but also how rewarding and fluent the work feels. So how do you improve?
The first step is simple: plan your work for at least two developers. One could argue that how you split the work doesn't matter, because the same work is going to get done anyway. However, there are two main reasons why it does:
How you split your work affects collaboration. If your smallest increment of work takes 2 weeks from one developer, it means they are unlikely to collaborate with others over those two weeks. Developers sometimes prefer this due to fewer distractions, but the downside is that the team shares less information, ends up creating worse plans, and takes less interest in their teammates' work.
The completion of work marks a natural time for re-evaluating a plan. If the team works on a feature for several months, chances are that some new information is not applied in the plan. Since software is often built with a large amount of uncertainty, it's critical that teams are able to apply learning early and regularly.
There are many other benefits that the teams gain by structuring their work in a way that enables collaboration. For instance, this often leads in reduced time-to-market for new products or features, resulting in more engagement with the customers and ultimately a better product. The developers are happier when they're collaborating and getting better support (e.g. getting better code reviews from their peers working on the same topic).
You can measure and improve your ability to work as a team on issues with Swarmia. This can be done by adopting a working agreement for avoiding solo work. Learn more about working agreements.
When everyone is working on their own project, work might feel efficient due to not having to coordinate anything with others. However, building a great product and team is a long-term effort, and the benefits far outweigh the costs in the long run, for the team and developers alike.
Structuring work with developer collaboration in mind forces you to be more thorough in the planning process. This can helps 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, all of which likely make your work flow better and reduce moments of frustration.
Too many competing priorities can lead developers and teams to work on simple, reactive tasks. These are easier to complete, but time spent on them might not maximize the impact of the team. It's often better to focus attention on properly solving few problems that really matter, rather than struggling to solve too many problems at once.
When the work in progress seems to not hinder completing your projects and they still seem to take too long to complete, you may need to look elsewhere for solutions. Another typical challenge to overcome is that a team is trying to solve too large of a problem at once. This is why you should critically evaluate the total scope of the issues.
For instance, a team might have structured the work in a way that would have created customer value and been able to learn more, before completing the whole original scope. 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.
There is much more to planning than just sheer scope of the issues. It is rare that upfront planning manages to account for all the tasks that end up going into an issue. This is why being aware of how the scope of the issue developed over time is important.
If you already know how much extra work you'll add on average (eg. 20% more tasks), you can take the scope creep into account when starting to plan the issue (for our example, this might mean three more tasks to complete, taking two extra days). You can also learn about certain types of tasks that tend to be always added to the scope after starting, and gradually increase the quality of planning.
As a side effect, you'll also become better at estimating how long the work will take to complete (which might help when making prioritization calls, deciding what to communicate to a stakeholder, or serve as a hint to split the work in smaller increments).
It is also common that challenges with scoping extend to the sub-tasks of the issue. There are often a couple of outlier tasks that took 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.