Ticket Velocity

Track and improve how much work you get done.

Purpose

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

The velocity dashboard also tracks your backlog. If the backlog trend is significantly increasing, then you might get more customer tickets than you can resolve or plan more work than you are able to do.

Improvement Actions: To increase the ticket velocity, it is helpful to look at the task size. While not all tasks might be under the team's control, such as customer incidents, other tasks might be broken down. It has been shown that smaller tasks lead to overall more work being done.

Other aspects include the amount of interruptions the team has to deal with and the available resourcing. Improving those aspects can also lead to improved velocity.

Explanations

Some of the charts in this report include:

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

Lead time: The lifecycle time from creation to being closed for completed tickets. Shorter lead times often mean smaller tasks and higher throughput. The converse is true as well.

Contributors: The number of engineers who were assigned tickets. The more engineers you have the higher throughput one would expect.

Investment breakdown: This helps you to gauge where the organisational effort went. By default, the investment of work is defined by the number of tickets resolved with a specific issue type. Depending on the classification in your planning tools, It might indicate if most of the throughput comes from bug tickets or new feature work.

Backlog trends: This shows the number of open vs closed tickets over time and the accumulated effect. It indicates the trends of reducing the backlog or if you are having a growth in the backlog and are potentially falling behind.

Good to Know

Velocity, lead time and code quality be seen as example dimensions for delivery health. One might be able to ship a lot and fast, but with poor 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 viewpoint.

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