Defining issue lifecycle and cycle time
Issues progress through various stages of completeness during their lifetime. Swarmia automatically calculates key properties and metrics for each issue.
Last updated
Was this helpful?
Issues progress through various stages of completeness during their lifetime. Swarmia automatically calculates key properties and metrics for each issue.
Last updated
Was this helpful?
Every team has slightly different conventions for how they use their issue tracker. Swarmia allows you to smooth out these differences through the so that every issue always has one of the following statuses: To Do, In Progress, or Done / Won't Do. This helps make the status of work comparable across different teams in the same organization.
The progression of issues through these statuses may not always be linear - someone might start working on a bug, only to realize they're out of their depth, and leave it for someone else. In this case, the status of the issue might've gone from To Do to In Progress, and then back again to To Do.
The cycle time of any work is the amount of time it has spent in the In Progress status, according to your issue tracker.
Most often, this is simply the time between starting the work (status becomes In Progress) and finishing it (status becomes Done).
More complex status histories are also accounted for. For example, if you work on an issue for 1 week, but then your priorities change, and that work is postponed for 3 months. You then start working on it again and finish it after 1 week. With this history, the issue will have a cycle time of 2 weeks, not 3½ months, as long as the issue was moved out of the In Progress status for the 3-month break.
You can see when each issue went into and out of the In Progress status from the Issue Activity Popup (accessible by clicking on any issue key found on Swarmia).
Swarmia also calculates incomplete cycle times for issues that are not yet Done. Such incomplete cycle times are clearly indicated in the UI and don't contribute to aggregate metrics such as your team's average cycle time.
If an issue moves directly from To Do to Done status, its cycle time is not defined. This may happen when someone completed their entire work on an issue without ever updating the issue tracker, and the status of the issue is later corrected.
Such undefined cycle times do not reflect reality, and also do not contribute to aggregate metrics such as your team's average cycle time.
Swarmia doesn't differentiate between work time and off-time in cycle time calculations. That is, weekends count as cycle time, as do non-business hours of the day.
This may seem unintuitive, or even unfair at first, but consider the following:
Many teams are distributed, and work may happen at various time zones
Even co-located teams have members with different work habits: someone shows up at 7 AM, someone squeezes in a bit of work time after 9 PM after putting the kids to bed
Different countries have different national holidays
Teams have off-sites and trainings which are not holidays, but not regular work time either
Attempting to take all of this into account would result in a number that's too complex to understand, not comparable across teams.
The lifetime of an issue is the amount of time between its first and last activity, according to merged data from your issue tracker and your version control system.
Issue activity includes all events that can be tied to the issue in question, such as commits, pull requests, and reviews. Issue status changes also count as activity.
For some issues, the lifetime will be the same as the cycle time: even if there's a lot of activity in between, the first activity will be the status change to In Progress, and the last activity will be the status change to Done.
But for many issues this is not the case: someone might have worked on the issue for days, before remembering to update the issue status to In Progress. Similarly, it's not uncommon to mark an issue as Done, only to spend the following days fixing all the little things you notice only in production.
The issue lifetime takes these realities into account. In contrast to the issue cycle time, it is often closer to the actual time it took to complete an issue from start to end.
On the other hand, the issue lifetime doesn't account for more complex issue status histories. For example, if you work on an issue for 1 week, take a 3-month break, and then finish the work in 1 week, the issue lifetime will be 3½ months. This is the case even if the issue was moved out of the In Progress status for the 3-month break.
The active days of an issue is the number of days on which it had some linked activity indicating the issue is moving forward.
Version control activity includes all events that can be tied to the issue in question, such as commits, pull requests, and reviews which count towards the issue active time. In addition to version control activity, completed child issues also count as issue active time.
For some issues, the active days will be the same as the lifetime: someone was actively working on the code each day while the issue was in progress.
But often this is not the case: teams might run into blockers, or be working on too many things at the same time. This will cause them to have days (or even weeks) when there's no active work being done towards completing the issue. The issue active days captures this information.
This number helps you quantify focus: for a focused team, making steady progress towards completing the issue, the number will be close to 100%. On the other hand, for a team that is trying to complete too many work items at the same time, the number will be significantly lower. Increasing your flow efficiency helps you deliver value earlier, and eliminate waste.
For the same reason, an issue may actually have a flow efficiency greater than 100%.
This special handling of off-hours is so that you have an intuitive target to aim for: less than 100%, and your focus may be spread too thin; more than 100%, and your pace might not be sustainable.
Same as with cycle time, there is .
You can see which days had activity in the .
As with cycle time, Swarmia has : if there is activity on weekends, it also contributes toward the active days of the issue.
The flow efficiency of an issue is the percentage of days when the issue was , compared to its whole .
, the flow efficiency takes weekends into account. That is, if your issue lifetime is from Monday to the Friday of the next week, and there is version control activity on each weekday, the flow efficiency of the issue will be 100%, even if there is a weekend in between.
