Coding Velocity

Track and improve how much work you get done.

Purpose

The coding velocity shows how much work your organisation can deliver over time. The higher the throughput, the more features/PRs you generally ship to your customers.

The velocity dashboard also tracks your PR backlog, i.e., those PRs you open but might not manage to merge/close. If the backlog trend is significantly increasing, you might have a review/approval problem, difficulties merging because of merge conflicts, or a problem with reviewer to developer allocation.

Improvement Actions: To increase the PR velocity, it is helpful to look at the PR size. It has been shown that smaller, less complex PRs lead to overall more work being done.

Other aspects include the amount of interruptions the team has to deal with and the available resourcing. Having a good time balance between review activities and coding helps to not accumulate larger PR backlogs.

Explanations

Some of the charts in this report include:

PR throughput: The number of PRs that were done/closed in the set period of time.

Cycle time: The PR lifecycle time from the first commit to merging/closing of completed PRs. Shorter cycle times often mean smaller tasks and higher throughput. The converse is true as well.

Contributors: The number of engineers who were opening a PR. The more engineers you have the higher throughput one would expect.

Work Focus: The work focus examines the code commits and gives each PR a predominant classification:

• New Work: New code being committed that does not change existing code.

• Rework Own: Changes to code less than 3 weeks (default) old, that had been committed by the same developer.

• Rework Others: Changes to code less than 3 weeks (default) old, that had been committed by a different developer.

• Maintenance: Changes to code older than 3 weeks.

The work focus helps you to understand where the organisational effort went into. A certain degree of rework and maintenance is expected. However, if maintenance dominates the throughput, then this is likely caused by technical debt and more extensive refactor needs. This also means that new features are de-prioritised.

Backlog trends: This shows the number of open vs closed PRs over time and the accumulated effect. PRs should usually not accumulate any substantial backlog. Reasons for backlog growth might come from forgotten and stale PRs, review delays or merge blockers. More information can be gleaned from Logilica's Code Activity and Risk dashboards.

Good to Know

Velocity, cycle time and code quality be seen as example dimensions for delivery health. One might be able to ship a lot of PRs fast, but with poor (review) quality and many code risks. Conversely, high-quality delivery might be sparse and slow. As such the Logilica metrics should be seen from a balancing point of view.

Similarly, one might ship many PRs, but overload the capacity of the team leading to potential burnout issues.