Planning Metrics
Planning metrics offer insights into the initial phases of your software development lifecycle. By measuring elements like planning time, issue completion rates, and unplanned work, these metrics help you understand the efficiency and accuracy of your team's project planning and estimation processes.
These metrics help you identify areas for improvement in how work is scoped, prioritized, and executed — leading to more predictable and consistent project delivery.
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. |
| Time to Plan | The time spent planning per pull request, from when the linked issue was last moved to in-progress to the first commit. | This metric measures the amount of time spent planning before development begins. Longer planning times can signal unclear requirements or poorly-scoped issues. |
| 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. |
| In-Progress Issues per Contributor | The number of issues in progress divided by the number of contributors. | Limiting work-in-progress can help teams maintain focus and streamline product development. |
| 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. |
How We Calculate Planning Metrics
Considerations for how we calculate your metrics:
- Contributors are Jira users who were assigned an in-progress or completed issue in the last 90 days.