Planning Metrics
Planning metrics offer insights into the initial phases of your software development lifecycle. Metrics such as issue cycle time, issue completion rates, and unplanned work help you understand the efficiency and accuracy of your team’s project planning and estimation processes.
Key Planning Metrics
Below are the key planning metrics tracked on our platform.
| Metric | Definition | Why It Matters |
|---|---|---|
| Issue Cycle Time | The time from when an issue was last marked as in-progress to when it was completed. Because issues may enter “In Progress” prematurely or multiple times, we use the last transition to reflect when continuous development work actually began. | This metric measures how long it takes to complete work once it’s started. Shorter, stable cycle times make delivery more predictable, while long cycle times often correlate with too much work in progress, unclear requirements, or shifting priorities. |
| Bug Open Rate | The sum of bugs opened each period divided by the sum of total issues opened over the same period. | This metric measures the proportion of newly created work items that are bugs — indicating how much of your team’s attention is being directed toward fixing quality issues rather than delivering new functionality. |
| Bug Resolution Rate | The sum of bugs resolved each period divided by the sum of bugs opened over the same period. | Increases in the rate of bugs resolved indicates a shift toward improving quality, whereas lower resolution rates indicate accumulating customer issues and tech debt. |
| Bug Resolution Time | The time from when a bug is created to when it is resolved. | Resolving bugs promptly contributes to better customer experiences. |
| Issue Completion Rate | The percentage of issues added to a sprint (planned and unplanned issues) that were completed. | Ensuring that work is completed each sprint improves the consistency of delivery. |
| Planned Issue Completion Rate | The percentage of planned issues that were completed per sprint. | Low accuracy may indicate poor estimation practices or delivery constraints. |
| Unplanned Issue Rate | The percentage of completed issues that were unplanned each sprint. Unplanned issues are issues added to a sprint after the sprint has started. | Keeping projects focused minimizes disruptions and maximizes quality of deliverables. |
Metric Calculations
This section explains what we include in planning metrics in more detail and how we derive cycle time so your numbers stay accurate across different workflows and edge cases.
Who and what we include
Contributors are Jira users who were assigned an in-progress or completed issue in the last 90 days.
Issue cycle time uses all issue types. Bug open rate and bug resolution rate use only bugs.
How we define issue cycle time
We measure cycle time from the last time an issue was moved to in progress until it was finished. Using the last transition reflects when continuous development actually began and avoids counting false starts. Issues that never have an in-progress timestamp are excluded.
For the end of the cycle, we use the greater of the resolution timestamp and the completed timestamp. That way, re-opened issues and workflows with both Resolved and Closed (or similar) statuses are counted correctly—we always use the final completion moment. For bug resolution time specifically, we use the resolution timestamp only.
Edge cases: re-opened, cloned, and incomplete issues
Jira issues can be re-opened after resolution or closed, or they can be cloned or imported with unusual timestamps. We handle these so metrics stay consistent:
- Re-opened and completed again — Jira’s resolution date does not update after the first resolution. We use the greater of the resolution and completed timestamps so we count only the last cycle.
- Cloned or imported issues — An issue cloned from a resolved issue or imported from another system can have a resolution date before its created date. We use the completed timestamp and require it to be after the created date.
- Re-opened but never completed — If an issue is moved back to in progress and never finished (for example due to workflow configuration), we only include it when the end time is after the start time, so cycle time is always positive.
Resolution vs. completed
Resolution is a standard Jira field. When it is set, Jira considers the issue’s lifecycle officially over. Completed is not a standard field; it means the issue is in a status mapped to Jira’s Done status category. An issue can have both a resolution timestamp and a completed timestamp.
Example: in a workflow In Progress → Resolved → Closed, the developer moves the issue to Resolved and a post-function sets the Resolution field (e.g. “Fixed”) and Jira sets the resolution date. The issue may sit in Resolved for QA, then move to Closed. If both statuses are mapped to Done, the issue is Completed only when it reaches Closed. Resolution can therefore happen before the issue is fully completed. Using the greater of the two timestamps in our calculations ensures re-opened issues and multi-step workflows are reflected correctly.