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.
Throughput types classify merge requests and issues with a top level type in the list below. If an issue or merge request has more than one of these labels then the highest one in the list takes precedence.
Some throughput types have sub-types such as
~"feature::maintenance". Type labels will be inferred from sub-types with
to aid in throughput type reporting. Application of the sub-type label is
encouraged for measuring the type at the highest level of specificity.
~"Community contribution": A community contribution label takes precedence over other labels. Therefore, while the work may introduce a new feature or resolve a bug, we prioritize this label over others due to the importance of this particular category. You may apply a second throughput label such as
~"feature"to indicate the throughput type.
~"security": Security-related MRs.
~"bug": Defects in shipped code. Read more about features vs bugs.
~"feature": Any MR that contains work to support the implementation of a feature and/or results in an improvement in the user experience. Read more about features vs bugs.
~"feature::addition": Work towards the creation of a new feature. This includes user facing and non-user facing changes such as data model, feature flag and other backend pre-work.
~"feature::maintenance": Refinements to an existing feature that is not related to
~bugresolution. This would include
~"technical debt"and industry standard updates such as work towards Rails upgrade.
~"tooling": MRs related to engineering tooling.
~"tooling::pipelines": MRs related to pipelines configuration.
~"tooling::workflow": MRs related to improvements of the engineering workflow and release tooling like Danger, RuboCop, linters, etc.
~"documentation": For documentation-only MRs, use
~"documentation"only unless the work is attributable to code changes for a feature or bug, and in that case, use
~"bug", even if the doc change is being made late for a feature/bug from a previous milestone.
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.
~"backstage" was intended to be changes that were done to keep product development running smoothly. Over time,
~"backstage" was also being used for pre-feature work and has become unclear and confusing.
~"backstage" was deprecated as part of https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/488.
This guidance may be helpful if you are wondering the go-forward type label based on your use case for applying
~"feature::maintenance"for industry standard and refactoring changes such as:
~"feature::maintenance"for addition or updates to specs for existing GitLab features
~"feature::addition"for all changes related to the release of a new feature
~"tooling::workflow"for changes to engineering workflows such as:
~"tooling::pipelines"for changes to project pipeline configurations
~backstage will be removed with https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/483.
undefinedMRs represented, spend some time to review your team's MRs and add labels so you can get a more accurate reflection of your investment. It could take up to a day for these updates to show up on the quality dashboard. Also good to keep in mind that the data here represents contributions in multiple projects. Label hygiene is not enforced across all of them.
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.
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
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:
backstagework that spans multiple groups.
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.