# Ticket Velocity

## 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.

{% hint style="success" %}
**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.
{% endhint %}

## 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](/metrics-and-reports/planning/ticket-overload.md) leading to potential burnout issues.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.logilica.com/metrics-and-reports/planning/ticket-velocity.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.