Add latest changes from gitlab-org/gitlab@master

3 files changed, 10 insertions, 15 deletions

diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md
index 704476cdc90..017a0c46570 100644
--- a/doc/user/analytics/index.md
+++ b/doc/user/analytics/index.md
@@ -127,12 +127,6 @@ To retrieve metrics for change failure rate, use the [GraphQL](../../api/graphql
 
 We use the following terms to describe GitLab analytics:
 
-- **Cycle time:** The duration of only the execution work. Cycle time is often displayed in combination with the lead time, which is longer than the cycle time. GitLab measures cycle time from the earliest commit of a [linked issue's merge request](../project/issues/crosslinking_issues.md) to when that issue is closed. The cycle time approach underestimates the lead time because merge request creation is always later than commit time. GitLab displays cycle time in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](../analytics/value_stream_analytics.md).
-- **Deploys:** The total number of successful deployments to production in the given time frame (across all applicable projects). GitLab displays deploys in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md) and [project-level Value Stream Analytics](value_stream_analytics.md).
-- **Lead time:** The duration of your value stream, from start to finish. Different to
-[Lead time for changes](#lead-time-for-changes). Often displayed in combination with "cycle time,"
-which is shorter. GitLab measures lead time from issue creation to issue close. GitLab displays lead
-time in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md).
 - **Mean Time to Change (MTTC):** The average duration between idea and delivery. GitLab measures
 MTTC from issue creation to the issue's latest related merge request's deployment to production.
 - **Mean Time to Detect (MTTD):** The average duration that a bug goes undetected in production.
@@ -142,11 +136,6 @@ merge request creation to merge request merge (and closed/un-merged merge reques
 For more information, see [Merge Request Analytics](merge_request_analytics.md).
 - **Mean Time to Recover/Repair/Resolution/Resolve/Restore (MTTR):** The average duration that a bug
 is not fixed in production. GitLab measures MTTR from deployment of bug to deployment of fix.
-- **Throughput:** The number of issues closed or merge requests merged (not closed) in a period of
-time. Often measured per sprint. GitLab displays merge request throughput in [Merge Request Analytics](merge_request_analytics.md).
-- **Value Stream:** The entire work process that is followed to deliver value to customers. For example,
-the [DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/) is a value stream that starts
-with "plan" and ends with "monitor". GitLab helps you track your value stream using [Value Stream Analytics](value_stream_analytics.md).
 - **Velocity:** The total issue burden completed in some period of time. The burden is usually measured
 in points or weight, often per sprint. For example, your velocity may be "30 points per sprint". GitLab
 measures velocity as the total points or weight of issues closed in a given period of time.
diff --git a/doc/user/analytics/merge_request_analytics.md b/doc/user/analytics/merge_request_analytics.md
index 06774c3f16a..29f2ec79800 100644
--- a/doc/user/analytics/merge_request_analytics.md
+++ b/doc/user/analytics/merge_request_analytics.md
@@ -48,7 +48,8 @@ To view the number of merge requests merged per month:
        - In the **From** field, select a start date.
        - In the **To** field, select an end date.
 
-The **Throughput** chart shows the number of merge requests merged per month.
+The **Throughput** chart shows issues closed or merge requests merged (not closed) over a period of
+time.
 
 The table shows up to 20 merge requests per page, and includes
 information about each merge request.
@@ -58,9 +59,10 @@ information about each merge request.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229389) in GitLab 13.9.
 
 Use the number in **Mean time to merge** to view the average time between when a merge request is
-created and when it's merged.
+created and when it's merged. Closed and un-merged merge requests are not included.
 
 To view **Mean time to merge**:
 
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Analytics > Merge request**.
+1. On the left sidebar, select **Analytics > Merge request**. The **Mean time to merge** number
+is shown on the dashboard.
diff --git a/doc/user/analytics/value_stream_analytics.md b/doc/user/analytics/value_stream_analytics.md
index 92c4d447ed9..039d33a1ad8 100644
--- a/doc/user/analytics/value_stream_analytics.md
+++ b/doc/user/analytics/value_stream_analytics.md
@@ -12,6 +12,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Value stream analytics provides metrics about each stage of your software development process.
 
+A **value stream** is the entire work process that delivers value to customers. For example,
+the [DevOps lifecycle](https://about.gitlab.com/stages-devops-lifecycle/) is a value stream that starts
+with the Manage stage and ends with the Protect stage.
+
 Use value stream analytics to identify:
 
 - The amount of time it takes to go from an idea to production.
@@ -74,7 +78,7 @@ To view the median time spent in each stage:
 Value stream analytics shows the lead time and cycle time for issues in your project:
 
 - Lead time: Median time from when the issue was created to when it was closed.
-- Cycle time: Median time from first commit to issue closed. Commits are associated with issues when users [cross-link them in the commit message](../project/issues/crosslinking_issues.md#from-commit-messages).
+- Cycle time: Median time from first commit to issue closed. GitLab measures cycle time from the earliest commit of a [linked issue's merge request](../project/issues/crosslinking_issues.md) to when that issue is closed. The cycle time approach underestimates the lead time because merge request creation is always later than commit time.
 
 To view the lead time and cycle time for issues: