Add deploy metric docs

doc/user/analytics/index.md

@@ -11,13 +11,17 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 When we describe GitLab analytics, we use the following terms:
 
 - **Cycle time:** The duration of only the execution work alone. Often displayed in combination with "lead time," which is longer. GitLab measures cycle time from issue first merge request creation to issue close. This approach underestimates 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).
+- **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).
 - **DORA (DevOps Research and Assessment)** ["Four Keys"](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance):
   - **Speed/Velocity**
 
-    - **Deployment Frequency:** How often an organization successfully releases to production. GitLab
-      measures this as the number of deployments to a
+    - **Deployment frequency:** The average number of successful deployments to production per period.
+      This effectively measures how often you are delivering value to end users. A higher deployment
+      frequency means you are able to get feedback and iterate more quickly in delivering
+      improvements and features faster. GitLab measures this as the number of deployments to a
       [production environment](../../ci/environments/index.md#deployment-tier-of-environments) in
       the given time period.
+      GitLab displays deployment frequency in [group-level Value Stream Analytics](../group/value_stream_analytics/index.md).
     - **Lead Time for Changes:** The time it takes for a commit to get into production. (1) GitLab
       measures this as the median duration between merge request merge and deployment to a
       [production environment](../../ci/environments/index.md#deployment-tier-of-environments) for

doc/user/group/value_stream_analytics/index.md

@@ -71,12 +71,26 @@ GitLab provides the ability to filter analytics based on a date range. To filter
 1. Optionally select a project.
 1. Select a date range using the available date pickers.
 
-## How Time metrics are measured
+## How metrics are measured
 
 The "Time" metrics near the top of the page are measured as follows:
 
 - **Lead time**: median time from issue created to issue closed.
-- **Cycle time**: median time from first commit to issue closed. (You can associate a commit with an issue by [crosslinking in the commit message](../../project/issues/crosslinking_issues.md#from-commit-messages).)
+- **Cycle time**: median time from first commit to issue closed. (You can associate a commit with an
+  issue by [crosslinking in the commit message](../../project/issues/crosslinking_issues.md#from-commit-messages).)
+
+The "Recent Activity" metrics near the top of the page are measured as follows:
+
+- **New Issues:** the number of issues created in the date range.
+- **Deploys:** the number of deployments to production (1) in the date range.
+- **Deployment Frequency:** the average number of deployments to production (1) per day in the date range.
+
+(1) To give a more accurate representation of deployments that actually completed successfully,
+the calculation for these two metrics changed in GitLab 13.9 from using the time a deployment was
+created to the time a deployment finished. If you were referencing this metric prior to 13.9, please
+keep this slight change in mind.
+
+You can learn more about these metrics in our [analytics definitions](../../analytics/index.md).
 
 ![Value stream analytics time metrics](img/vsa_time_metrics_v13_0.png "Time metrics for value stream analytics")
 
@@ -109,8 +123,8 @@ How this works, behind the scenes:
    we need for the stages, like issue creation date, merge request merge time,
    etc.
 
-To sum up, anything that doesn't follow [GitLab flow](../../../topics/gitlab_flow.md) will not be tracked and the
-Value Stream Analytics dashboard will not present any data for:
+To sum up, anything that doesn't follow [GitLab flow](../../../topics/gitlab_flow.md) is not tracked and the
+Value Stream Analytics dashboard doesn not present any data for:
 
 - Merge requests that do not close an issue.
 - Issues not labeled with a label present in the Issue Board or for issues not assigned a milestone.
@@ -118,7 +132,8 @@ Value Stream Analytics dashboard will not present any data for:
 
 ## How the production environment is identified
 
-Value Stream Analytics identifies production environments by looking for project [environments](../../../ci/yaml/README.md#environment) with a name matching any of these patterns:
+Value Stream Analytics identifies production environments by looking for project
+[environments](../../../ci/yaml/README.md#environment) with a name matching any of these patterns:
 
 - `prod` or `prod/*`
 - `production` or `production/*`
@@ -184,7 +199,8 @@ The default stages are designed to work straight out of the box, but they might
 all teams. Different teams use different approaches to building software, so some teams might want
 to customize their Value Stream Analytics.
 
-GitLab allows users to create multiple value streams, hide default stages and create custom stages that align better to their development workflow.
+GitLab allows users to create multiple value streams, hide default stages and create custom stages
+that align better to their development workflow.
 
 ### Stage path
 
@@ -255,7 +271,8 @@ the start event, the stop event dropdown will only list the compatible events.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/196698) in GitLab 12.10.
 
-Once a custom stage has been added, you can "drag and drop" stages to rearrange their order. These changes are automatically saved to the system.
+Once a custom stage has been added, you can "drag and drop" stages to rearrange their order. These
+changes are automatically saved to the system.
 
 ### Label based stages
 
@@ -293,7 +310,8 @@ To recover a default stage that was previously hidden:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221202) in GitLab 13.3
 
-A default value stream is readily available for each group. You can create additional value streams based on the different areas of work that you would like to measure.
+A default value stream is readily available for each group. You can create additional value streams
+based on the different areas of work that you would like to measure.
 
 Once created, a new value stream includes the [seven stages](#default-stages) that follow
 [GitLab workflow](../../../topics/gitlab_flow.md)