Time-tracking – DevAcrobats

Complexity vs Performance KPI

KPI Advisor — Thu, 09 Jan 2025 08:39:16 +0000

With Performance Objectives: Charts for Jira, your team can gain valuable insights into the average time it takes to complete issues with varying story point estimates. A Complexity vs Performance report can provide your clients with the data they need, enhancing their understanding of project progress and performance.

In practice, opinions on how to use Story Points vary, with some teams adopting a hybrid approach to estimate Product Backlog Items (PBIs) by combining Fibonacci sequence numbers and time estimates in order to handle client expectations. Clients might not fully comprehend the advantages of relative sizing and Story Points estimation. Instead, they often seek data directly reflecting the actual time required for different tasks. This article addresses these concerns by guiding you on creating a complexity vs performance KPI report using the ‘Time in status’ metric available in the Performance Objectives app.

Analyzing Story Points: Assessing Complexity vs Performance through Average Time in Status

Gain deeper insights into your team’s performance, identify areas for improvement, and make data-driven decisions to enhance overall efficiency and effectiveness in your project delivery. Based on a complexity vs performance report your agile teams can fine-tune their estimation processes, improve requirements gathering, and leverage individual expertise for better outcomes.

Improve your Sprint retrospectives by analyzing the average Time in status for issues with specific complexities, evaluating their estimation accuracy, requirements quality, and developer expertise within your Agile team.

Here’s a step-by-step guide on how to configure complexity vs performance report in Jira with our app:

Step 1: Filter out the data you wish to analyze as your ‘Data Source’. In our example we have filtered all resolved issues for the past 6 months in our Scrum demo project.

Step 2: Select the ‘Time in status’ metric and add one or more applicable statuses to analyze, e.g., In Progress, Review, Testing.

Step 3: Choose the ‘Average’ calculation method and leave the average to be calculated by Number of issues.

Step 4: Select ‘Story Points’ for the ‘Display by’ field.

Step 5: (Optional) Further break down the data by selecting ‘Status (history)’ or any other relevant criteria.

Step 6: (Optional) Opt for the ‘Vertical’ orientation to accommodate more items on the x-axis.

You can switch to Pivot table view or Tiles view directly form your chart. You can also export the report data in CSV format for comprehensive analysis, and download it as PDF.

Watch this configuration video with the easy steps to create a Complexity vs Performance report in Jira.

Sorry, your browser doesn't support embedded videos.

For additional performance-related reports, please visit our KPI examples. To find inspiration for reporting from your Jira data, explore the list of supported metrics and fields in our Configuration Overview.

If you require assistance with chart configurations, our support team is readily available to help you!

Max Issue Age KPI

KPI Advisor — Thu, 09 Jan 2025 08:35:51 +0000

KPIs, or Key Performance Indicators, are essential metrics used to measure and evaluate business performance. By tracking specific KPIs, businesses gain valuable insights to make data-driven decisions and improve operations, productivity, and overall success.

In this comprehensive guide, we explore the ‘Max Issue Age’ KPI and how efficiently tracking elapsed time since a designated event date can provide valuable insights. The ‘Time since’ metric, available in the Performance Objectives: Charts for Jira app, allows businesses to closely monitor issue age, optimize performance objectives, identify bottlenecks, improve workflow efficiency, and enhance customer satisfaction through timely issue resolution.

Tracking Time Since any Date Field in Jira with ‘Time since’ Metric

Jira users often rely on the built-in Average Age chart to determine the average age of issues based on specific event dates, such as issue creation or resolution. This chart provides some insights into the overall aging of issues. However, the Performance Objectives app takes this functionality a step further by introducing the ‘Time since’ metric. This metric empowers you to track the time that has passed since a designated event date. The event date can be any standard or custom Jira date field, such as Created, Updated, Resolved, or any other relevant milestone within your workflow.

Moreover, the Performance Objectives app goes beyond tracking elapsed time by offering the option to define a ‘max issue age’ target. This feature allows teams to establish performance objectives related to aging issues and ensures that timely resolutions are achieved. By combining the ‘Time since’ metric and the ‘max issue age’ target, businesses can optimize their performance, proactively identify and address bottlenecks, and significantly improve workflow efficiency. Now, let’s explore the ‘Max issue age’ KPI!

Defining the Max Issue Age Target for Effective Performance Monitoring

To effectively measure issue age, the Performance Objectives gadget allows you to set a target called the ‘Max issue age’. This target can be defined in either days or hours, depending on your specific needs and requirements. By establishing a threshold, you gain a clear benchmark to evaluate whether your issues are within the desired age range or if any exceed the defined maximum. Ensure that you set an appropriate target to monitor and optimize your workflow.

Step-by-Step Configuration Guide:

Step 1: Identify Jira issues to be analyzed by configuring them within the Data Source, e.g., Status is ‘Work in progress’, ‘Waiting for support’, Issue type is ‘Support’, etc.

Step 2: Select the metric ‘Time since’ and pick the ‘Created’ Jira date field for ‘Event’. Apply customizations based on your preferences. Please not that the ‘Measure until’ button is set to until resolved by default. You can keep it like this as it won’t affect issue age of open issues, which is the aim of our report.

Step 3: Use ‘Issue Key’ or ‘Issue summary’ for ‘Display by’ to get metric data distinguished by Jira issue.

Step 4: (Optional) Use ‘Stacked by’ mode to see the metric distribution by any chosen field, metric, or data source. In the provided example, we have not utilized the stack option.

Step 5: Choose vertical orientation of the chart. It will allow more items to fit on the y-axis, as the height in Jira dashboard is better suited to be extended.

Step 6: Switch on Target section and leave the ‘Fixed’ tab selected.

Step 7: Set target results to be calculated against each x-axis item.

Step 8: Define target level. In the sample configuration it is 3 days.

Step 9: Mark target as negative by setting ‘Exceeding’ is: ‘Bad’. Therefore, if the target is exceeded, the results will be colored in red.

Step 10: Under ‘More Settings’ section, enable the ‘Warning threshold’ and set a number as fixed value or as % of target. It will color the results above that level and below target in Amber.

Step 11: Enable the ‘Custom Target Label’ and set label to indicate the negative type of the Target on the chart, e.g., ‘Max age (d)’.

View the recorded video encompassing the provided configuration steps:

Sorry, your browser doesn't support embedded videos.

Additional Time-Based Reporting Options with the ‘Time Since’ Metric

You can further utilize the ‘Time since’ metric within the Performance Objectives gadget to generate reports based on various standard or custom Jira date fields. Explore the diverse possibilities of time-based reporting on your Jira Dashboard using the ‘Time Since’ metric. Here are a few examples of the types of reports you can create with this app:

Time passed since ‘Updated’
Time since First date in status ‘In Progress’
Time passed since Overdue Date
Time since ‘Status category Change’
Time passed since ‘First day in Assignee’

By leveraging the power of the ‘Time since’ metric in the Performance Objectives app, you can gain valuable insights into the timing and duration of various events within your Jira projects. Customize your reports based on the specific date fields that are relevant to your workflow and enhance your overall project management and performance monitoring.

Average Time in Status in Sprint

KPI Advisor — Fri, 20 Dec 2024 09:15:51 +0000

In the dynamic world of Agile project management, tracking and improving team performance is crucial for the success of each sprint. One effective way to achieve this is by generating an Average Time in Status in Sprint report in Jira, utilizing the Performance Objectives app. This report provides valuable insights into how long tasks remain in specific statuses, such as Review, Testing, In Progress, or any other status in your workflow. By displaying this data on a sprint-by-sprint basis along the x-axis and setting targets for maximum time spent in each status, teams can identify and eliminate bottlenecks, enhance sprint velocity, and increase the likelihood of achieving the sprint goal.

Generating Average Time in Status in Sprint KPI Report

The core of this report Average time in status report for Jira lies in the ‘Time in Status‘ metric, which is ready to use within our app, the Performance Objectives for Jira. By defining and tracking the time tasks spend in critical statuses like “Review”, teams can set actionable goals to reduce these durations. For instance, setting a target to decrease the average time spent in the Review status can significantly reduce blockers, ensuring a smoother workflow.

This aligns with the “fail fast, fail early” principle, encouraging teams to address issues promptly and iteratively. By focusing on this metric, teams not only improve their current sprint performance but also foster a culture of continuous improvement, ultimately driving higher efficiency and productivity in their Agile processes.

Now, let’s configure this report in a few steps.

Step 1: Add a Data Source. In our example, we’ve filtered our demo project “AQUA” and disabled the date range to view all previous sprints.

Step 2: Select the ‘Time in Status’ metric and specify the status “Review”.

Step 3: Switch from Sum to Average calculation. Average calculation provides insight into typical durations, mitigating the impact of outliers and offering a clearer understanding of overall task progression.

Step 4: Choose ‘Sprint’ for the ‘Display by’ field and add the Sprint Board you want to analyze.

Step 5: Turn on the Target section and opt for a Fixed target.

Step 6: Select “Per x-axis item” as the target type and set the value of your choice. In our sample report, it is 2 hours.

Step 7: Specify that exceeding 2 hours in the chosen status on average is considered undesirable by choosing “exceeding is Bad”.

Step 8: (Optional) Under More Settings, add a warning threshold of your choice as an early indicator of approaching the target.

Step 9: Optional) Under More Settings, set a custom target label to “Max. 2 h”.

Detailed image for Step 2:

In the sample report we have used status “Review”, but you have the flexibility to select each status of interest, such as “In Progress” or “Testing,” allowing you to easily identify bottlenecks in each step of your workflow.

Here’s a video guide to help you step by step through the process of configuring an Average Time in Status in Sprint KPI report in Jira:

Sorry, your browser doesn't support embedded videos.

With the powerful features of the Performance Objectives app and the ready-to-use metrics it supports, you can build various insightful KPI reports for your Jira dashboard. To explore more about our app’s features, refer to the User Guide, gain inspiration from our KPI Examples or contact our Support team for demo or assistance!

Work Log Time KPI – Week Goal

KPI Advisor — Fri, 20 Dec 2024 09:14:47 +0000

As highlighted in our blog post, it’s important to note that the Jira system field ‘Time Spent’ might not always provide the precise time results you anticipate when reviewing worklogs for specific periods such as months, weeks, or days. Choosing the right metric and configuring the display by field is paramount for ensuring accurate worklog time tracking reports. However, another important factor is selecting the right filters in the data source to precisely capture the timeframe of when logs occurred. An issue may have multiple ‘Work Logged Date’ entries due to multiple worklog instances from different team members who worked on the issue (i.e., ‘Work Log Authors’).

The Performance Objectives provides a selection of ready-to-use metrics and fields designed to read, calculate, and present data from your issue history. Among our app’s supported metrics and fields, for precise worklog tracking and reporting, consider using:

Worklog time (h) – time type field, can be used as calculation metric (y-axis) and display field (x-axis)
Work logged – date type field, can be selected in the Data source, or as a display field (x-axis)
Worklog author – user type field, can be used for x-axis display

Here’s an accurate “Last Week’s Work Log Time by Work Log Author” report. We’ve leveraged the Target feature within the app to establish a goal of a minimum of 35 work hours logged per week for each employee (Work Log Author).

Here are the steps you can follow to create a precise worklog tracking report with a predefined target using our app:

Step 1: In your Data Source, select Work Logged issues and choose the date range you are interested in. In our sample, this is Last Week.

Step 2: Choose the metric ‘Work Log Time (h)’

Step 3: For Display By, select “Work Log Author” field

Step 4: Turn the Target feature on and select “Fixed Target”

Step 5: Choose “Per x-axis item” type of target calculation

Step 6: Add a specific value for the target. In our sample, we have defined 35 hours per week as the goal.

Below is a detailed configuration of the Data Source for Step 1. On the right image, we have applied additional filtering of the data source by ‘Work Log Author’. This approach is useful if you wish to narrow the results only to specific team members who have worked on and logged time for your project issues.

Additionally, we have set the default view of the Performance Objectives gadget to Tiles and have also included a threshold line as a percentage of the target. However, these steps are optional. If you wish to proceed with them, open “More Settings”.

Potential Issues with Worklog Time Tracking in Jira

In the domain of project management, precise time tracking and worklog time tracking holds utmost importance for assessing progress, allocating resources effectively, and estimating future tasks and overall capacity. Nevertheless, relying in all cases on the standard Jira field “Time Spent” can often result in misleading reports and inaccurate insights. If you want to learn more on the topic, this blog post aims to delve into the Limitations of Reporting on Time Spent by Assignee in Jira. Additionally, here is a comprehensive list with detailed explanations of why alternative configurations may not yield the expected results in the “Last Week’s Work Log Time by Work Log Author” scenario.

If we report by the metric ‘Work log time (h)’ and display by the field ‘Assignee’, it will allocate the total work logs on the issue to the last assignee of the issue.
If we filter the data using the ‘Created’ date field for a specific time period and display it by ‘Time Spent’, the results may not include issues that have been worked on but were created before the selected time period.
Moreover, if we show data by date field ‘Created’ instead of ‘Work Logged’ the whole time will be accounted to the ‘Created’ date, which won’t be correct.

In the example above, we’ve utilized the Performance Objectives gadget in Tiles view. To explore more about our app’s features, refer to our Documentation, gain inspiration from our KPI Examples.