PR Cycle Time now leverages linked Jira/ADO issues to determine the start of the development phase.
Overview
It's a years long debate - what is Cycle Time? Some engineering leaders say that it measures how quickly a commit can get merged into the main branch, and it's a measure of the efficiency of the review review process.
Other leaders say that it's the time it takes from when the engineer starts development until the code gets to the main branch, and that the measure needs to include the time that was actually spent coding and testing.
DORA, on the other hand, makes it clear that it's the time from the first commit until the code reaches production or end users (but that's Lead Time for Changes).
The fact is, neither choice is wrong, they just measure different things and are both still valuable to understand a team's development process, and potential bottlenecks within. The different ways to calculate Cycle Time become equivalent if you have developers that create a commit at the start of their work, and frequently throughout, but that tends to be rare.
But now you can understand both of these pictures because Uplevel can now leverage Issue information to determine when development on a PR truly began. This is done by allowing users to select how to start calculating Cycle Time: by First Commit or by First Activity.
To do this, Uplevel looks at a PR's linked issues, and tracks the first time one of them moves to an "In Progress" status. Some organizations have told us that they have implemented Git/Jira integrations that automatically move the ticket to "In Progress" when a branch is created. Uplevel also realizes that developers forget to move the ticket to "In Progress" until the work is nearly done. First Activity is defined as whichever comes first: the first commit on a PR or the first time a linked Jira issues moves to "In Progress".
Which method should I use?
- Choose First Activity if your team consistently links their PRs to Jira/ADO Issues, and tends to have a practice of keeping issue statuses in sync with reality. This will give a clear view into how long the coding and testing takes as part of the development process.
- Choose First Commit if your team doesn't consistently link PRs to issues or if the team has inconsistent hygiene and best practices around tickets. This selection will put all PRs on the same page regardless of behavior in Jira.
- Note that the Wait and Review Phases are identical regardless of the selection.
💡Example Scenario:
Late Monday evening, a bug in production is detected. An issue gets created, triaged, and is assigned to a developer Tuesday morning at 9 AM during standup. The developer starts work and moves the ticket to "In Progress" at 10 AM, but isn't able to finish by end of day Tuesday. Development and testing continues on Wednesday morning until 11AM. The developer commits at 11:00 AM, pushes their local branch to Git and opens the PR at 11:05 AM and passes it off for review. It's ultimately approved and merged at noon Wednesday.
When using First Activity, the Cycle Time for this PR is 26 hours. This includes the 25 hours and 5 minutes spent in the development phase, and the 55 minutes spent in the review phase. This shows how long the work took from beginning to end including development
When using First Commit the Cycle time for this PR is 1 hour, with just 5 minutes between first commit and the PR being opened. This shows that the review process was quite efficient with just 55 minutes from the PR being opened until when it was merged.
Frequently Asked Questions
How does Uplevel link PRs to Jira/ADO issues?
Uplevel is able to link PRs to Jira/ADO issues if the key is included in the PR's title, branch name or description. For example, including a URL in the description: https://jira.atlassian.net/browse/ABC-123 or writing "ABC-123" in the body.
How is "In Progress" determined?
On a specific board, the ticket workflow can be specified and customized, but maintains three higher-level status categories: "To Do", "In Progress", and "Done". On a single board, an "In Progress" state might be called "In Development", "Coding", or "In Progress" as a few examples. You can work with your Jira administrator to determine how these statuses map to their overall status category.