Gitlab hero border pattern left svg Gitlab hero border pattern right svg



Throughput, is a measure of the total number of MRs that are completed and in production in a given period of time. Unlike velocity, throughput does not require the use of story points or weights, instead we measure the number of MRs completed by a team in the span of a week or a release. Each MR is represented by 1 unit/point. This calculation happens after the time period is complete and no pre-planning is required to capture this metric. The total count should not be limited to only MRs that deliver features, it's important to include engineering proposed MRs in this count as well. This will ensure that we properly reflect the team's capacity in a consistent way and focus on delivering at a predictable rate.

We also refer to throughput as productivity on occasion. In both cases, we measure it at a team level (or higher), not at an individual level.


Each merge request must have one of the following labels. These labels assign a category in the charts. If an MR has more than one of these labels, the highest one in the list takes precedence.

If it does not have any of these, it will be tracked in the 'undefined' bucket instead. The Engineering Manager for each team is ultimately responsible for ensuring that these labels are set correctly, and should do this as a manual process on a schedule that is appropriate for their time.

Throughput charts are available on the quality dashboard for each team.

Why we adopted this model

A few notes to consider when using this model

How to read and interpret the data

When combined with cycle time, throughput is a great metric to help you identify areas of improvement and possible bottlenecks that the team can work to address.

Stage and Group labels in Throughput

In the spirit of "Everyone can Contribute" it's natural that members in a group will contribute to another group. Our guideline aims to cover for the 20/80 (default accounting method). By default the MR from an author should belong to their group::xxx and direct parent devops::xxx Optimizing for all edge cases will lead to complexity since there will always be edge cases.

We allow flexibility where the parent devops::xxx and child group::xxx label may not match. For example:

If a contribution happens across groups, we leave it to the discretion of the engineering and product manager to change the group::xxx label to reflect which group worked on it. They can also decide if they want to move over the devops::xxx as well or keep it to reflect the product area. The triage bot automatic labelling we will not override existing labels.