Processing Time and Cycle Time Reports | Targetprocess - Visual management software

Processing Time and Cycle Time Reports

The Cycle Time report shows you how long it takes for work to pass through your process. Cycle time is defined as the number of days or hours it takes a card to move between selected workflow states.

High-performing teams often use their average cycle time to measure their efficiency and to estimate how long it may take to complete a new work item. When you implement Kanban process then metrics obtained from Cycle Time reports may help to detect bottlenecks and problematic states, adjust process settings, optimize list of states, balance load of assignees per their role, and tune WIP limits. When a problem is detected and solved, average cycle time is decreased, which means the work becomes getting done faster.

In Targetprocess, the Cycle Time report can be built for all the entities that have a states-based Project Workflow: User Stories, Tasks, Bugs, Features, Epics, Requests, Projects, Test Plan Runs. The reports are based on the dates when the entities change their workflow states.

Processing Time and Cycle Time Reports. Image 1

Changes of Team Workflow states and Custom Field statuses are not supported by Cycle Time reports in Targetprocess at the moment.

Types of Cycle Time reports in Targetprocess

In Targetprocess there are two types of Cycle Time metrics and reports. They use different data sources:

  • Lead Time and Cycle Time built-in metrics, templates for Entity Visual Reports, and Predefined Graphical Reports such as Process Control chart, Lead and Cycle Time Distribution chart. Use predefined fields such as Creation Date, Start Date, Completion Date, and IsPlanned setting of workflow states. The metrics and reports are limited: they do not support separate calculation per each state, and particular states cannot be selected for the totals calculation.
  • Historical Visual Reports. Use Historical data of state transitions. Besides totals taken across all the workflow states, processing times can be calculated per each one, and custom Cycle Time metrics can be built for selected states only.

Calculations of Lead and Cycle Time metrics are based on calendar days. All the metrics and reports are based on total number of days or hours an entity spent in a particular workflow state, including afterhours, weekends, and public holidays.

Lead Time and Cycle Time

Built-in Lead Time metric is the difference between the moment when an item is created and the moment when the item enters its Final state.

Built-in Cycle Time metric is the difference between the moment when an item is considered 'in progress' to the moment the item enters its Final state.

Lead Time and Cycle Time

More on them: Lead Time and Cycle Time.

Templates for Entity Visual Reports

These templates for Visual Reports use data from built-in entity fields such as Creation Date, Start Date, Completion Date, and IsPlanned setting of workflow states. The following templates are available:

  • Cycle Time Trend
  • Cycle Time Variation
  • Effort vs Cycle Time
  • Features Cycle Time Trend
  • Process Control by Cycle time

Templates for Entity Visual Reports

Cycle Time Trend

This report shows average Cycle Time across all complete items. Here we are able to see the Feature average Cycle Time changing month by month across different projects.

Features Cycle Time trend

The next report shows Cycle Time trends for User Stories and Bugs by week. A Linear Trend Line is also added so that we can make more detailed observations about these trends over time.

Cycle Time trend

Cycle Time Variation

This report shows the minimum, average, and maximum Cycle Time of User Stories each week. Spikes in the maximum Cycle Time reflect the moments when some long-awaited or delayed items were finally completed.

Cycle Time Variation

Effort vs Cycle Time

This report shows the correlation between Effort and Cycle Time for User Stories and Bugs.

Effort vs Cycle Time

Predefined Graphical Reports

Process Control chart

Process control chart shows cycle time distribution for completed entities (user stories, features, bugs, tasks, requests) within a certain timeframe.

Process Control chart

More on this chart: Process Control Chart.

Lead and Cycle Time Distribution Chart

The Lead and Cycle Time Distribution chart helps you make realistic forecasts.

Lead and Cycle Time Distribution Chart

More on this chart: Lead and Cycle Time Distribution Chart.

Historical Visual Reports for Processing Time and Cycle Time

Historical Visual Reports for Processing Time and Custom Cycle Time in Targetprocess use historical data of state transitions. The reports are used to calculate and visualize custom metrics for the entities in your system, especially:

  • Processing Time across all the workflow states
  • Processing Time per each state
  • Custom Cycle Time for selected states altogether

Processing Time per State, per Item

The Historical Visual Reports described below display raw Processing Time for each entity and state in the same chart. This is a stacked bar chart. Each bar represents time and, more concretely, how much time the entity such as the task or the project has spent in a given state. The different colors represent the different states in which the task has been throughout its life-cycle. The longer the bar, the longer the task has been worked on. Toggle on / off states in a legend to compare Processing Time for a selected state for all the displayed entities. Say, from the chart described below we can see that for the project S-P79 it took about 216 days to pass the Research phase, while the project S-N57 passed this state almost 4 times faster.

Processing Time per State, per Item

More on this chart: Processing Time per State, per Item.

Average Processing Time per State

Aggregation capabilities of Historical Visual Reports are used to calculate and display Average Processing Time per state across your filtered scope of data. Use the chart to compare Average Processing Time across workflow states, predict Cycle Time for your newly created work items, and detect problematic states.

According to the chart displayed below the development and testing activities are performed quite fast as average time spent in In Dev and Testing states for all the entities is rather low. However, most of the lifecycle the work items are queued and stuck in Planned (waits for development), Coded (waits for testing), and Tested (waits for deployment) states.

Average Processing Time per State

More on this chart: Average Processing Time per State.

Average Processing Time Dynamics per State

Historical Visual Reports support Timeline display mode and grouping source entities per date ranges. Group the work items weekly or monthly according to their Creation Date, Start Date, Completion Date, or Date of Modification, to get Processing Time dynamics. In the report below work items are grouped per month of creation date and groups displayed in the form of timeline. Average Processing Time is displayed for each group, helping to track dynamics and discover trends.

From the chart below we find out that the overall team performance for the entities created in August, 2017 was low: average processing time for Open, Planned, Reopen, Coded, Testing states was increased in comparison with the other month.

Average Processing Time Dynamics per State

More on this chart: Average Processing Time Dynamics per State.

Cycle Time for Selected States, per Item

Historical Visual Reports support selection of workflow states for the Processing Time and Cycle Time metrics. Here are the most frequently required use cases.

Value-added Processing Time vs Wasted Time. Not all the states are equal in terms of added value. In a workflow, processing time in some selected states may be considered as valuable because actual work has been performed during them. For example: Research, Design, In Dev, Testing, Deployment. As opposite, processing time in other states may be considered as wasted because the items in these state are just queued and wait for the actual work being performed. For example: Open, Reopen, Ideas, Planned, Coded, Tested.

Processing Time per Responsible Role. In Targetprocess it is possible to assign people to entities under multiple separate roles. People with different roles usually work on the same item subsequently and not simultaneously. Every role is usually set as responsible for the selected workflow states. For example, Developers are responsible for In Dev and Deployment state, Testers for Testing state, and activity of Feature Owners may be focused on Ideas, Research and Design states.

Use Advanced Filters by Entity States to calculate custom Cycle Time and build totals for value-added processing time, non-valuable wasted time, or processing time per states with particular responsible role only. In the filter, specify only the states you'd like to focus on.

Cycle Time for Selected States, per Item

More on this chart: Cycle Time for Selected States, per Item.

Average Cycle Time Dynamics for Selected States

Once custom Cycle Time metrics for Selected State are calculated per each item, it is possible to split items into groups and perform aggregation within each group. In the report below work items are grouped per quarter of creation date and groups are displayed in the form of timeline. Average custom Cycle Time is displayed for each group, helping to track dynamics and discover trends.

Average Cycle Time Dynamics for Selected States

More on this chart: Average Cycle Time Dynamics for Selected States.

Still have a question?

We're here to help! Just contact our friendly support team

Find out more about our APIs, Plugins, Mashups and custom extensions. Join our community of passionate users and even discuss directly with our developers.