Rename cycle analytics to value stream analytics

This is only to rename the user perceivable (façades)
elements of cycle analytics to value stream analytics.
This includes:
- Renaming content
- Renaming error messages
- Renaming routes
- Renaming docs

BE/FE codebase specific changes need to be done as a separate MR

app/assets/javascripts/cycle_analytics/components/banner.vue

@@ -27,7 +27,7 @@ export default {
 <template>
   <div class="landing content-block">
     <button
-      :aria-label="__('Dismiss Cycle Analytics introduction box')"
+      :aria-label="__('Dismiss Value Stream Analytics introduction box')"
       class="js-ca-dismiss-button dismiss-button"
       type="button"
       @click="dismissOverviewDialog"
@@ -36,10 +36,10 @@ export default {
     </button>
     <div class="svg-container" v-html="iconCycleAnalyticsSplash"></div>
     <div class="inner-content">
-      <h4>{{ __('Introducing Cycle Analytics') }}</h4>
+      <h4>{{ __('Introducing Value Stream Analytics') }}</h4>
       <p>
         {{
-          __(`Cycle Analytics gives an overview
+          __(`Value Stream Analytics gives an overview
 of how much time it takes to go from idea to production in your project.`)
         }}
       </p>

app/assets/javascripts/cycle_analytics/cycle_analytics_bundle.js

@@ -71,7 +71,7 @@ export default () => {
     },
     created() {
       // Conditional check placed here to prevent this method from being called on the
-      // new Cycle Analytics page (i.e. the new page will be initialized blank and only
+      // new Value Stream Analytics page (i.e. the new page will be initialized blank and only
       // after a group is selected the cycle analyitcs data will be fetched). Once the
       // old (current) page has been removed this entire created method as well as the
       // variable itself can be completely removed.
@@ -81,7 +81,7 @@ export default () => {
     methods: {
       handleError() {
         this.store.setErrorState(true);
-        return new Flash(__('There was an error while fetching cycle analytics data.'));
+        return new Flash(__('There was an error while fetching value stream analytics data.'));
       },
       initDropdown() {
         const $dropdown = $('.js-ca-dropdown');

app/assets/stylesheets/framework/variables.scss

@@ -579,7 +579,7 @@ $calendar-border-color: rgba(#000, 0.1);
 $calendar-user-contrib-text: #959494;
 
 /*
- *  Cycle Analytics
+ *  Value Stream Analytics
  */
 $cycle-analytics-box-padding: 30px;
 $cycle-analytics-box-text-color: #8c8c8c;

app/helpers/analytics_navbar_helper.rb

@@ -35,7 +35,7 @@ module AnalyticsNavbarHelper
     return unless project_nav_tab?(:cycle_analytics)
 
     navbar_sub_item(
-      title: _('Cycle Analytics'),
+      title: _('Value Stream Analytics'),
       path: 'cycle_analytics#show',
       link: project_cycle_analytics_path(project),
       link_to_options: { class: 'shortcuts-project-cycle-analytics' }

app/views/layouts/nav/sidebar/_project.html.haml

@@ -42,8 +42,8 @@
           - unless should_display_analytics_pages_in_sidebar
             - if can?(current_user, :read_cycle_analytics, @project)
               = nav_link(path: 'cycle_analytics#show') do
-                = link_to project_cycle_analytics_path(@project), title: _('Cycle Analytics'), class: 'shortcuts-project-cycle-analytics' do
-                  %span= _('Cycle Analytics')
+                = link_to project_cycle_analytics_path(@project), title: _('Value Stream Analytics'), class: 'shortcuts-project-cycle-analytics' do
+                  %span= _('Value Stream Analytics')
 
             = render_if_exists 'layouts/nav/project_insights_link'
 

app/views/projects/cycle_analytics/_overview.html.haml

@@ -4,12 +4,12 @@
       .col-md-10.offset-md-1
         .row.overview-details
           .col-md-6.overview-text
-            %h4 Introducing Cycle Analytics
+            %h4 Introducing Value Stream Analytics
             %p
-              Cycle Analytics gives an overview of how much time it takes to go from idea to production in your project.
-              To set up CA, you must first define a production environment by setting up your CI and then deploy to production.
+              Value Stream Analytics (VSA) gives an overview of how much time it takes to go from idea to production in your project.
+              To set up VSA, you must first define a production environment by setting up your CI and then deploy to production.
             %p
-              %a.btn{ href: help_page_path('user/analytics/cycle_analytics.md'), target: '_blank' } Read more
+              %a.btn{ href: help_page_path('user/analytics/value_stream_analytics.md'), target: '_blank' } Read more
           .col-md-6.overview-image
             %span.overview-icon
               = custom_icon ('icon_cycle_analytics_overview')

app/views/projects/cycle_analytics/show.html.haml

-- page_title "Cycle Analytics"
+- page_title "Value Stream Analytics"
 
 #cycle-analytics{ "v-cloak" => "true", data: { request_path: project_cycle_analytics_path(@project) } }
   - if @cycle_analytics_no_data
     %banner{ "v-if" => "!isOverviewDialogDismissed",
-      "documentation-link": help_page_path('user/analytics/cycle_analytics.md'),
+      "documentation-link": help_page_path('user/analytics/value_stream_analytics.md'),
       "v-on:dismiss-overview-dialog" => "dismissOverviewDialog()" }
   = icon("spinner spin", "v-show" => "isLoading")
   .wrapper{ "v-show" => "!isLoading && !hasError" }

changelogs/unreleased/38319-rename-interfaces-cycle-analytics-to-value-stream.yml

+---
+title: Rename cycle analytics interfaces to value stream analytics
+merge_request: 23427
+author:
+type: changed

config/routes/project.rb

@@ -195,9 +195,8 @@ constraints(::Constraints::ProjectUrlConstrainer.new) do
           end
         end
 
-        resource :cycle_analytics, only: [:show]
-
-        namespace :cycle_analytics do
+        resource :cycle_analytics, only: :show, path: 'value_stream_analytics'
+        scope module: :cycle_analytics, as: 'cycle_analytics', path: 'value_stream_analytics' do
           scope :events, controller: 'events' do
             get :issue
             get :plan
@@ -208,6 +207,7 @@ constraints(::Constraints::ProjectUrlConstrainer.new) do
             get :production
           end
         end
+        get '/cycle_analytics', to: redirect('%{namespace_id}/%{project_id}/-/value_stream_analytics')
 
         concerns :clusterable
 

db/fixtures/development/17_cycle_analytics.rb

@@ -109,7 +109,7 @@ class Gitlab::Seeder::CycleAnalytics
   def create_issues
     Array.new(@issue_count) do
       issue_params = {
-        title: "Cycle Analytics: #{FFaker::Lorem.sentence(6)}",
+        title: "Value Stream Analytics: #{FFaker::Lorem.sentence(6)}",
         description: FFaker::Lorem.sentence,
         state: 'opened',
         assignees: [@project.team.users.sample]
@@ -166,7 +166,7 @@ class Gitlab::Seeder::CycleAnalytics
       Timecop.travel 12.hours.from_now
 
       opts = {
-        title: 'Cycle Analytics merge_request',
+        title: 'Value Stream Analytics merge_request',
         description: "Fixes #{issue.to_reference}",
         source_branch: branch,
         target_branch: 'master'

doc/README.md

@@ -88,7 +88,7 @@ The following documentation relates to the DevOps **Manage** stage:
 | Manage Topics                                                                         | Description                                                                                                                                                                                                                  |
 |:--------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | [Authentication and<br/>Authorization](administration/auth/README.md) **(CORE ONLY)** | Supported authentication and authorization providers.                                                                                                                                                                        |
-| [GitLab Cycle Analytics](user/project/cycle_analytics.md)                             | Measure the time it takes to go from an [idea to production](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#from-idea-to-production-with-gitlab) for each project you have. |
+| [GitLab Value Stream Analytics](user/project/cycle_analytics.md)                      | Measure the time it takes to go from an [idea to production](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#from-idea-to-production-with-gitlab) for each project you have. |
 | [Instance Statistics](user/instance_statistics/index.md)                              | Discover statistics on how many GitLab features you use and user activity.                                                                                                                                                   |
 
 <div align="right">

doc/ci/environments.md

@@ -220,7 +220,7 @@ deployment will be recorded as a new environment named `production`.
 
 NOTE: **Note:**
 If your environment's name is `production` (all lowercase),
-it will get recorded in [Cycle Analytics](../user/project/cycle_analytics.md).
+it will get recorded in [Value Stream Analytics](../user/project/cycle_analytics.md).
 
 ### Configuring dynamic environments
 

doc/development/README.md

@@ -80,7 +80,7 @@ Complementary reads:
 - [File uploads](uploads.md)
 - [Auto DevOps development guide](auto_devops.md)
 - [Mass Inserting Models](mass_insert.md)
-- [Cycle Analytics development guide](cycle_analytics.md)
+- [Value Stream Analytics development guide](value_stream_analytics.md)
 - [Issue types vs first-class types](issue_types.md)
 - [Application limits](application_limits.md)
 - [Redis guidelines](redis.md)

doc/development/cycle_analytics.md

-# Cycle Analytics development guide
+---
+redirect_to: 'value_stream_analytics.md'
+---
 
-Cycle analytics calculates the time between two arbitrary events recorded on domain objects and provides aggregated statistics about the duration.
-
-## Stage
-
-During development, events occur that move issues and merge requests through different stages of progress until they are considered finished. These stages can be expressed with the `Stage` model.
-
-Example stage:
-
-- Name: Development
-- Start event: Issue created
-- End event: Issue first mentioned in commit
-- Parent: `Group: gitlab-org`
-
-### Events
-
-Events are the smallest building blocks of the cycle analytics feature. A stage consists of two events:
-
-- Start
-- End
-
-These events play a key role in the duration calculation.
-
-Formula: `duration = end_event_time - start_event_time`
-
-To make the duration calculation flexible, each `Event` is implemented as a separate class. They're responsible for defining a timestamp expression that will be used in the calculation query.
-
-#### Implementing an `Event` class
-
-There are a few methods that are required to be implemented, the `StageEvent` base class describes them in great detail. The most important ones are:
-
-- `object_type`
-- `timestamp_projection`
-
-The `object_type` method defines which domain object will be queried for the calculation. Currently two models are allowed:
-
-- `Issue`
-- `MergeRequest`
-
-For the duration calculation the `timestamp_projection` method will be used.
-
-```ruby
-def timestamp_projection
-  # your timestamp expression comes here
-end
-
-# event will use the issue creation time in the duration calculation
-def timestamp_projection
-  Issue.arel_table[:created_at]
-end
-```
-
-NOTE: **Note:**
-More complex expressions are also possible (e.g. using `COALESCE`). Look at the existing event classes for examples.
-
-In some cases, defining the `timestamp_projection` method is not enough. The calculation query should know which table contains the timestamp expression. Each `Event` class is responsible for making modifications to the calculation query to make the `timestamp_projection` work. This usually means joining an additional table.
-
-Example for joining the `issue_metrics` table and using the `first_mentioned_in_commit_at` column as the timestamp expression:
-
-```ruby
-def object_type
-  Issue
-end
-
-def timestamp_projection
-  IssueMetrics.arel_table[:first_mentioned_in_commit_at]
-end
-
-def apply_query_customization(query)
-  # in this case the query attribute will be based on the Issue model: `Issue.where(...)`
-  query.joins(:metrics)
-end
-```
-
-### Validating start and end events
-
-Some start/end event pairs are not "compatible" with each other. For example:
-
-- "Issue created" to "Merge Request created": The event classes are defined on different domain models, the `object_type` method is different.
-- "Issue closed" to "Issue created": Issue must be created first before it can be closed.
-- "Issue closed" to "Issue closed": Duration is always 0.
-
-The `StageEvents` module describes the allowed `start_event` and `end_event` pairings (`PAIRING_RULES` constant). If a new event is added, it needs to be registered in this module.
-​To add a new event:​
-
-1. Add an entry in `ENUM_MAPPING` with a unique number, it'll be used in the `Stage` model as `enum`.
-1. Define which events are compatible with the event in the `PAIRING_RULES` hash.
-
-Supported start/end event pairings:
-
-```mermaid
-graph LR;
-  IssueCreated --> IssueClosed;
-  IssueCreated --> IssueFirstAddedToBoard;
-  IssueCreated --> IssueFirstAssociatedWithMilestone;
-  IssueCreated --> IssueFirstMentionedInCommit;
-  IssueCreated --> IssueLastEdited;
-  IssueCreated --> IssueLabelAdded;
-  IssueCreated --> IssueLabelRemoved;
-  MergeRequestCreated --> MergeRequestMerged;
-  MergeRequestCreated --> MergeRequestClosed;
-  MergeRequestCreated --> MergeRequestFirstDeployedToProduction;
-  MergeRequestCreated --> MergeRequestLastBuildStarted;
-  MergeRequestCreated --> MergeRequestLastBuildFinished;
-  MergeRequestCreated --> MergeRequestLastEdited;
-  MergeRequestCreated --> MergeRequestLabelAdded;
-  MergeRequestCreated --> MergeRequestLabelRemoved;
-  MergeRequestLastBuildStarted --> MergeRequestLastBuildFinished;
-  MergeRequestLastBuildStarted --> MergeRequestClosed;
-  MergeRequestLastBuildStarted --> MergeRequestFirstDeployedToProduction;
-  MergeRequestLastBuildStarted --> MergeRequestLastEdited;
-  MergeRequestLastBuildStarted --> MergeRequestMerged;
-  MergeRequestLastBuildStarted --> MergeRequestLabelAdded;
-  MergeRequestLastBuildStarted --> MergeRequestLabelRemoved;
-  MergeRequestMerged --> MergeRequestFirstDeployedToProduction;
-  MergeRequestMerged --> MergeRequestClosed;
-  MergeRequestMerged --> MergeRequestFirstDeployedToProduction;
-  MergeRequestMerged --> MergeRequestLastEdited;
-  MergeRequestMerged --> MergeRequestLabelAdded;
-  MergeRequestMerged --> MergeRequestLabelRemoved;
-  IssueLabelAdded --> IssueLabelAdded;
-  IssueLabelAdded --> IssueLabelRemoved;
-  IssueLabelAdded --> IssueClosed;
-  IssueLabelRemoved --> IssueClosed;
-  IssueFirstAddedToBoard --> IssueClosed;
-  IssueFirstAddedToBoard --> IssueFirstAssociatedWithMilestone;
-  IssueFirstAddedToBoard --> IssueFirstMentionedInCommit;
-  IssueFirstAddedToBoard --> IssueLastEdited;
-  IssueFirstAddedToBoard --> IssueLabelAdded;
-  IssueFirstAddedToBoard --> IssueLabelRemoved;
-  IssueFirstAssociatedWithMilestone --> IssueClosed;
-  IssueFirstAssociatedWithMilestone --> IssueFirstAddedToBoard;
-  IssueFirstAssociatedWithMilestone --> IssueFirstMentionedInCommit;
-  IssueFirstAssociatedWithMilestone --> IssueLastEdited;
-  IssueFirstAssociatedWithMilestone --> IssueLabelAdded;
-  IssueFirstAssociatedWithMilestone --> IssueLabelRemoved;
-  IssueFirstMentionedInCommit --> IssueClosed;
-  IssueFirstMentionedInCommit --> IssueFirstAssociatedWithMilestone;
-  IssueFirstMentionedInCommit --> IssueFirstAddedToBoard;
-  IssueFirstMentionedInCommit --> IssueLastEdited;
-  IssueFirstMentionedInCommit --> IssueLabelAdded;
-  IssueFirstMentionedInCommit --> IssueLabelRemoved;
-  IssueClosed --> IssueLastEdited;
-  IssueClosed --> IssueLabelAdded;
-  IssueClosed --> IssueLabelRemoved;
-  MergeRequestClosed --> MergeRequestFirstDeployedToProduction;
-  MergeRequestClosed --> MergeRequestLastEdited;
-  MergeRequestClosed --> MergeRequestLabelAdded;
-  MergeRequestClosed --> MergeRequestLabelRemoved;
-  MergeRequestFirstDeployedToProduction --> MergeRequestLastEdited;
-  MergeRequestFirstDeployedToProduction --> MergeRequestLabelAdded;
-  MergeRequestFirstDeployedToProduction --> MergeRequestLabelRemoved;
-  MergeRequestLastBuildFinished --> MergeRequestClosed;
-  MergeRequestLastBuildFinished --> MergeRequestFirstDeployedToProduction;
-  MergeRequestLastBuildFinished --> MergeRequestLastEdited;
-  MergeRequestLastBuildFinished --> MergeRequestMerged;
-  MergeRequestLastBuildFinished --> MergeRequestLabelAdded;
-  MergeRequestLastBuildFinished --> MergeRequestLabelRemoved;
-  MergeRequestLabelAdded --> MergeRequestLabelAdded;
-  MergeRequestLabelAdded --> MergeRequestLabelRemoved;
-  MergeRequestLabelRemoved --> MergeRequestLabelAdded;
-  MergeRequestLabelRemoved --> MergeRequestLabelRemoved;
-```
-
-### Parent
-
-Teams and organizations might define their own way of building software, thus stages can be completely different. For each stage, a parent object needs to be defined.
-
-Currently supported parents:
-
-- `Project`
-- `Group`
-
-#### How parent relationship it work
-
-1. User navigates to the cycle analytics page.
-1. User selects a group.
-1. Backend loads the defined stages for the selected group.
-1. Additions and modifications to the stages will be persisted within the selected group only.
-
-### Default stages
-
-The [original implementation](https://gitlab.com/gitlab-org/gitlab/issues/847) of cycle analytics defined 7 stages. These stages are always available for each parent, however altering these stages is not possible.
-​
-To make things efficient and reduce the number of records created, the default stages are expressed as in-memory objects (not persisted). When the user creates a custom stage for the first time, all the stages will be persisted. This behaviour is implemented in the cycle analytics service objects.
-​
-The reason for this was that we'd like to add the abilities to hide and order stages later on.
-
-## Data Collector
-
-`DataCollector` is the central point where the data will be queried from the database. The class always operates on a single stage and consists of the following components:
-
-- `BaseQueryBuilder`:
-  - Responsible for composing the initial query.
-  - Deals with `Stage` specific configuration: events and their query customizations.
-  - Parameters coming from the UI: date ranges.
-- `Median`: Calculates the median duration for a stage using the query from  `BaseQueryBuilder`.
-- `RecordsFetcher`: Loads relevant records for a stage using the query from  `BaseQueryBuilder` and specific `Finder` classes to apply visibility rules.
-- `DataForDurationChart`: Loads calculated durations with the finish time (end event timestamp) for the scatterplot chart.
-
-For a new calculation or a query, implement it as a new method call in the `DataCollector` class.
-
-## Database query
-
-Structure of the database query:
-
-```sql
-SELECT (customized by: Median or RecordsFetcher or DataForDurationChart)
-FROM OBJECT_TYPE (Issue or MergeRequest)
-INNER JOIN (several JOIN statements, depending on the events)
-WHERE
-  (Filter by the PARENT model, example: filter Issues from Project A)
-  (Date range filter based on the OBJECT_TYPE.created_at)
-  (Check if the START_EVENT is earlier than END_EVENT, preventing negative duration)
-```
-
-Structure of the `SELECT` statement for `Median`:
-
-```sql
-SELECT (calculate median from START_EVENT_TIME-END_EVENT_TIME)
-```
-
-Structure of the `SELECT` statement for `DataForDurationChart`:
-
-```sql
-SELECT (START_EVENT_TIME-END_EVENT_TIME) as duration, END_EVENT.timestamp
-```
-
-## High-level overview
-
-- Rails Controller (`Analytics::CycleAnalytics` module): Cycle analytics exposes its data via JSON endpoints, implemented within the `analytics` workspace. Configuring the stages are also implements JSON endpoints (CRUD).
-- Services (`Analytics::CycleAnalytics` module): All `Stage` related actions will be delegated to respective service objects.
-- Models (`Analytics::CycleAnalytics` module): Models are used to persist the `Stage` objects `ProjectStage` and `GroupStage`.
-- Feature classes (`Gitlab::Analytics::CycleAnalytics` module):
-  - Responsible for composing queries and define feature specific busines logic.
-  - `DataCollector`, `Event`, `StageEvents`, etc.
-
-## Testing
-
-Since we have a lots of events and possible pairings, testing each pairing is not possible. The rule is to have at least one test case using an `Event` class.
-
-Writing a test case for a stage using a new `Event` can be challenging since data must be created for both events. To make this a bit simpler, each test case must be implemented in the `data_collector_spec.rb` where the stage is tested through the `DataCollector`. Each test case will be turned into multiple tests, covering the following cases:
-
-- Different parents: `Group` or `Project`
-- Different calculations: `Median`, `RecordsFetcher` or `DataForDurationChart`
+This document was moved to [another location](value_stream_analytics.md)

doc/development/i18n/externalization.md

@@ -559,5 +559,5 @@ Let's suppose you want to add translations for a new language, let's say French.
 
    ```shell
    git add locale/fr/ app/assets/javascripts/locale/fr/
-   git commit -m "Add French translations for Cycle Analytics page"
+   git commit -m "Add French translations for Value Stream Analytics page"
    ```

doc/development/value_stream_analytics.md

+# Value Stream Analytics development guide
+
+Value stream analytics calculates the time between two arbitrary events recorded on domain objects and provides aggregated statistics about the duration.
+
+For information on how to configure Value Stream Analytics in GitLab, see our [analytics documentation](../user/analytics/value_stream_analytics.md).
+
+## Stage
+
+During development, events occur that move issues and merge requests through different stages of progress until they are considered finished. These stages can be expressed with the `Stage` model.
+
+Example stage:
+
+- Name: Development
+- Start event: Issue created
+- End event: Issue first mentioned in commit
+- Parent: `Group: gitlab-org`
+
+### Events
+
+Events are the smallest building blocks of the value stream analytics feature. A stage consists of two events:
+
+- Start
+- End
+
+These events play a key role in the duration calculation.
+
+Formula: `duration = end_event_time - start_event_time`
+
+To make the duration calculation flexible, each `Event` is implemented as a separate class. They're responsible for defining a timestamp expression that will be used in the calculation query.
+
+#### Implementing an `Event` class
+
+There are a few methods that are required to be implemented, the `StageEvent` base class describes them in great detail. The most important ones are:
+
+- `object_type`
+- `timestamp_projection`
+
+The `object_type` method defines which domain object will be queried for the calculation. Currently two models are allowed:
+
+- `Issue`
+- `MergeRequest`
+
+For the duration calculation the `timestamp_projection` method will be used.
+
+```ruby
+def timestamp_projection
+  # your timestamp expression comes here
+end
+
+# event will use the issue creation time in the duration calculation
+def timestamp_projection
+  Issue.arel_table[:created_at]
+end
+```
+
+NOTE: **Note:**
+More complex expressions are also possible (e.g. using `COALESCE`). Look at the existing event classes for examples.
+
+In some cases, defining the `timestamp_projection` method is not enough. The calculation query should know which table contains the timestamp expression. Each `Event` class is responsible for making modifications to the calculation query to make the `timestamp_projection` work. This usually means joining an additional table.
+
+Example for joining the `issue_metrics` table and using the `first_mentioned_in_commit_at` column as the timestamp expression:
+
+```ruby
+def object_type
+  Issue
+end
+
+def timestamp_projection
+  IssueMetrics.arel_table[:first_mentioned_in_commit_at]
+end
+
+def apply_query_customization(query)
+  # in this case the query attribute will be based on the Issue model: `Issue.where(...)`
+  query.joins(:metrics)
+end
+```
+
+### Validating start and end events
+
+Some start/end event pairs are not "compatible" with each other. For example:
+
+- "Issue created" to "Merge Request created": The event classes are defined on different domain models, the `object_type` method is different.
+- "Issue closed" to "Issue created": Issue must be created first before it can be closed.
+- "Issue closed" to "Issue closed": Duration is always 0.
+
+The `StageEvents` module describes the allowed `start_event` and `end_event` pairings (`PAIRING_RULES` constant). If a new event is added, it needs to be registered in this module.
+​To add a new event:​
+
+1. Add an entry in `ENUM_MAPPING` with a unique number, it'll be used in the `Stage` model as `enum`.
+1. Define which events are compatible with the event in the `PAIRING_RULES` hash.
+
+Supported start/end event pairings:
+
+```mermaid
+graph LR;
+  IssueCreated --> IssueClosed;
+  IssueCreated --> IssueFirstAddedToBoard;
+  IssueCreated --> IssueFirstAssociatedWithMilestone;
+  IssueCreated --> IssueFirstMentionedInCommit;
+  IssueCreated --> IssueLastEdited;
+  IssueCreated --> IssueLabelAdded;
+  IssueCreated --> IssueLabelRemoved;
+  MergeRequestCreated --> MergeRequestMerged;
+  MergeRequestCreated --> MergeRequestClosed;
+  MergeRequestCreated --> MergeRequestFirstDeployedToProduction;
+  MergeRequestCreated --> MergeRequestLastBuildStarted;
+  MergeRequestCreated --> MergeRequestLastBuildFinished;
+  MergeRequestCreated --> MergeRequestLastEdited;
+  MergeRequestCreated --> MergeRequestLabelAdded;
+  MergeRequestCreated --> MergeRequestLabelRemoved;
+  MergeRequestLastBuildStarted --> MergeRequestLastBuildFinished;
+  MergeRequestLastBuildStarted --> MergeRequestClosed;
+  MergeRequestLastBuildStarted --> MergeRequestFirstDeployedToProduction;
+  MergeRequestLastBuildStarted --> MergeRequestLastEdited;
+  MergeRequestLastBuildStarted --> MergeRequestMerged;
+  MergeRequestLastBuildStarted --> MergeRequestLabelAdded;
+  MergeRequestLastBuildStarted --> MergeRequestLabelRemoved;
+  MergeRequestMerged --> MergeRequestFirstDeployedToProduction;
+  MergeRequestMerged --> MergeRequestClosed;
+  MergeRequestMerged --> MergeRequestFirstDeployedToProduction;
+  MergeRequestMerged --> MergeRequestLastEdited;
+  MergeRequestMerged --> MergeRequestLabelAdded;
+  MergeRequestMerged --> MergeRequestLabelRemoved;
+  IssueLabelAdded --> IssueLabelAdded;
+  IssueLabelAdded --> IssueLabelRemoved;
+  IssueLabelAdded --> IssueClosed;
+  IssueLabelRemoved --> IssueClosed;
+  IssueFirstAddedToBoard --> IssueClosed;
+  IssueFirstAddedToBoard --> IssueFirstAssociatedWithMilestone;
+  IssueFirstAddedToBoard --> IssueFirstMentionedInCommit;
+  IssueFirstAddedToBoard --> IssueLastEdited;
+  IssueFirstAddedToBoard --> IssueLabelAdded;
+  IssueFirstAddedToBoard --> IssueLabelRemoved;
+  IssueFirstAssociatedWithMilestone --> IssueClosed;
+  IssueFirstAssociatedWithMilestone --> IssueFirstAddedToBoard;
+  IssueFirstAssociatedWithMilestone --> IssueFirstMentionedInCommit;
+  IssueFirstAssociatedWithMilestone --> IssueLastEdited;
+  IssueFirstAssociatedWithMilestone --> IssueLabelAdded;
+  IssueFirstAssociatedWithMilestone --> IssueLabelRemoved;
+  IssueFirstMentionedInCommit --> IssueClosed;
+  IssueFirstMentionedInCommit --> IssueFirstAssociatedWithMilestone;
+  IssueFirstMentionedInCommit --> IssueFirstAddedToBoard;
+  IssueFirstMentionedInCommit --> IssueLastEdited;
+  IssueFirstMentionedInCommit --> IssueLabelAdded;
+  IssueFirstMentionedInCommit --> IssueLabelRemoved;
+  IssueClosed --> IssueLastEdited;
+  IssueClosed --> IssueLabelAdded;
+  IssueClosed --> IssueLabelRemoved;
+  MergeRequestClosed --> MergeRequestFirstDeployedToProduction;
+  MergeRequestClosed --> MergeRequestLastEdited;
+  MergeRequestClosed --> MergeRequestLabelAdded;
+  MergeRequestClosed --> MergeRequestLabelRemoved;
+  MergeRequestFirstDeployedToProduction --> MergeRequestLastEdited;
+  MergeRequestFirstDeployedToProduction --> MergeRequestLabelAdded;
+  MergeRequestFirstDeployedToProduction --> MergeRequestLabelRemoved;
+  MergeRequestLastBuildFinished --> MergeRequestClosed;
+  MergeRequestLastBuildFinished --> MergeRequestFirstDeployedToProduction;
+  MergeRequestLastBuildFinished --> MergeRequestLastEdited;
+  MergeRequestLastBuildFinished --> MergeRequestMerged;
+  MergeRequestLastBuildFinished --> MergeRequestLabelAdded;
+  MergeRequestLastBuildFinished --> MergeRequestLabelRemoved;
+  MergeRequestLabelAdded --> MergeRequestLabelAdded;
+  MergeRequestLabelAdded --> MergeRequestLabelRemoved;
+  MergeRequestLabelRemoved --> MergeRequestLabelAdded;
+  MergeRequestLabelRemoved --> MergeRequestLabelRemoved;
+```
+
+### Parent
+
+Teams and organizations might define their own way of building software, thus stages can be completely different. For each stage, a parent object needs to be defined.
+
+Currently supported parents:
+
+- `Project`
+- `Group`
+
+#### How parent relationship it work
+
+1. User navigates to the value stream analytics page.
+1. User selects a group.
+1. Backend loads the defined stages for the selected group.
+1. Additions and modifications to the stages will be persisted within the selected group only.
+
+### Default stages
+
+The [original implementation](https://gitlab.com/gitlab-org/gitlab/issues/847) of value stream analytics defined 7 stages. These stages are always available for each parent, however altering these stages is not possible.
+​
+To make things efficient and reduce the number of records created, the default stages are expressed as in-memory objects (not persisted). When the user creates a custom stage for the first time, all the stages will be persisted. This behaviour is implemented in the value stream analytics service objects.
+​
+The reason for this was that we'd like to add the abilities to hide and order stages later on.
+
+## Data Collector
+
+`DataCollector` is the central point where the data will be queried from the database. The class always operates on a single stage and consists of the following components:
+
+- `BaseQueryBuilder`:
+  - Responsible for composing the initial query.
+  - Deals with `Stage` specific configuration: events and their query customizations.
+  - Parameters coming from the UI: date ranges.
+- `Median`: Calculates the median duration for a stage using the query from  `BaseQueryBuilder`.
+- `RecordsFetcher`: Loads relevant records for a stage using the query from  `BaseQueryBuilder` and specific `Finder` classes to apply visibility rules.
+- `DataForDurationChart`: Loads calculated durations with the finish time (end event timestamp) for the scatterplot chart.
+
+For a new calculation or a query, implement it as a new method call in the `DataCollector` class.
+
+## Database query
+
+Structure of the database query:
+
+```sql
+SELECT (customized by: Median or RecordsFetcher or DataForDurationChart)
+FROM OBJECT_TYPE (Issue or MergeRequest)
+INNER JOIN (several JOIN statements, depending on the events)
+WHERE
+  (Filter by the PARENT model, example: filter Issues from Project A)
+  (Date range filter based on the OBJECT_TYPE.created_at)
+  (Check if the START_EVENT is earlier than END_EVENT, preventing negative duration)
+```
+
+Structure of the `SELECT` statement for `Median`:
+
+```sql
+SELECT (calculate median from START_EVENT_TIME-END_EVENT_TIME)
+```
+
+Structure of the `SELECT` statement for `DataForDurationChart`:
+
+```sql
+SELECT (START_EVENT_TIME-END_EVENT_TIME) as duration, END_EVENT.timestamp
+```
+
+## High-level overview
+
+- Rails Controller (`Analytics::CycleAnalytics` module): Value stream analytics exposes its data via JSON endpoints, implemented within the `analytics` workspace. Configuring the stages are also implements JSON endpoints (CRUD).
+- Services (`Analytics::CycleAnalytics` module): All `Stage` related actions will be delegated to respective service objects.
+- Models (`Analytics::CycleAnalytics` module): Models are used to persist the `Stage` objects `ProjectStage` and `GroupStage`.
+- Feature classes (`Gitlab::Analytics::CycleAnalytics` module):
+  - Responsible for composing queries and define feature specific busines logic.
+  - `DataCollector`, `Event`, `StageEvents`, etc.
+
+## Testing
+
+Since we have a lots of events and possible pairings, testing each pairing is not possible. The rule is to have at least one test case using an `Event` class.
+
+Writing a test case for a stage using a new `Event` can be challenging since data must be created for both events. To make this a bit simpler, each test case must be implemented in the `data_collector_spec.rb` where the stage is tested through the `DataCollector`. Each test case will be turned into multiple tests, covering the following cases:
+
+- Different parents: `Group` or `Project`
+- Different calculations: `Median`, `RecordsFetcher` or `DataForDurationChart`

doc/user/analytics/code_review_analytics.md

@@ -36,7 +36,7 @@ identify improvements that might substantially accelerate your development cycle
 Code Review Analytics can be used when:
 
 - Your team agrees that code review is moving too slow.
-- The [Cycle Analytics feature](cycle_analytics.md) shows that reviews are your team's most time-consuming step.
+- The [Value Stream Analytics feature](value_stream_analytics.md) shows that reviews are your team's most time-consuming step.
 
 You can use Code Review Analytics to see the types of work that are currently moving the slowest, and analyze the patterns
 and trends between them. For example:

doc/user/analytics/cycle_analytics.md

-# Cycle Analytics
+---
+redirect_to: '../analytics/value_stream_analytics.md'
+---
 
-> - Introduced prior to GitLab 12.3 at the project level.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12077) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3 at the group level.
-
-Cycle Analytics measures the time spent to go from an
-[idea to production](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#from-idea-to-production-with-gitlab)
-(also known as cycle time) for each of your projects. Cycle Analytics displays the median time
-spent in each stage defined in the process.
-
-NOTE: **Note:**
-Use the `cycle_analytics` feature flag to enable at the group level.
-
-Cycle Analytics is useful in order to quickly determine the velocity of a given
-project. It points to bottlenecks in the development process, enabling management
-to uncover, triage, and identify the root cause of slowdowns in the software development life cycle.
-
-Cycle Analytics is tightly coupled with the [GitLab flow](../../topics/gitlab_flow.md) and
-calculates a separate median for each stage.
-
-## Overview
-
-Cycle Analytics is available:
-
-- From GitLab 12.3, at the group level in the analytics workspace (top navigation bar) at
-  **Analytics > Cycle Analytics**. **(PREMIUM)**
-
-  In the future, multiple groups will be selectable which will effectively make this an
-  instance-level feature.
-
-- At the project level via **Project > Cycle Analytics**.
-
-There are seven stages that are tracked as part of the Cycle Analytics calculations.
-
-- **Issue** (Tracker)
-  - Time to schedule an issue (by milestone or by adding it to an issue board)
-- **Plan** (Board)
-  - Time to first commit
-- **Code** (IDE)
-  - Time to create a merge request
-- **Test** (CI)
-  - Time it takes GitLab CI/CD to test your code
-- **Review** (Merge Request/MR)
-  - Time spent on code review
-- **Staging** (Continuous Deployment)
-  - Time between merging and deploying to production
-- **Total** (Total)
-  - Total lifecycle time. That is, the velocity of the project or team. [Previously known](https://gitlab.com/gitlab-org/gitlab/issues/38317) as **Production**.
-
-## Date ranges
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/13216) in GitLab 12.4.
-
-GitLab provides the ability to filter analytics based on a date range. To filter results:
-
-1. Select a group.
-1. Optionally select a project.
-1. Select a date range using the available date pickers.
-
-## How the data is measured
-
-Cycle Analytics records cycle time and data based on the project issues with the
-exception of the staging and total stages, where only data deployed to
-production are measured.
-
-Specifically, if your CI is not set up and you have not defined a `production`
-or `production/*` [environment](../../ci/yaml/README.md#environment), then you will not have any
-data for this stage.
-
-Each stage of Cycle Analytics is further described in the table below.
-
-| **Stage** | **Description** |
-| --------- | --------------- |
-| Issue     | Measures the median time between creating an issue and taking action to solve it, by either labeling it or adding it to a milestone, whatever comes first. The label will be tracked only if it already has an [Issue Board list](../project/issue_board.md#creating-a-new-list) created for it. |
-| Plan      | Measures the median time between the action you took for the previous stage, and pushing the first commit to the branch. The very first commit of the branch is the one that triggers the separation between **Plan** and **Code**, and at least one of the commits in the branch needs to contain the related issue number (e.g., `#42`). If none of the commits in the branch mention the related issue number, it is not considered to the measurement time of the stage. |
-| Code      | Measures the median time between pushing a first commit (previous stage) and creating a merge request (MR) related to that commit. The key to keep the process tracked is to include the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically) to the description of the merge request (for example, `Closes #xxx`, where `xxx` is the number of the issue related to this merge request). If the issue closing pattern is not present in the merge request description, the MR is not considered to the measurement time of the stage. |
-| Test      | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI takes to run every job for the commits pushed to that merge request defined in the previous stage. It is basically the start->finish time for all pipelines. |
-| Review    | Measures the median time taken to review the merge request that has closing issue pattern, between its creation and until it's merged. |
-| Staging   | Measures the median time between merging the merge request with closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI configuration. If there isn't a production environment, this is not tracked. |
-| Total | The sum of all time (medians) taken to run the entire process, from issue creation to deploying the code to production. [Previously known](https://gitlab.com/gitlab-org/gitlab/issues/38317) as **Production**. |
-
-How this works, behind the scenes:
-
-1. Issues and merge requests are grouped together in pairs, such that for each
-   `<issue, merge request>` pair, the merge request has the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically)
-   for the corresponding issue. All other issues and merge requests are **not**
-   considered.
-1. Then the `<issue, merge request>` pairs are filtered out by last XX days (specified
-   by the UI - default is 90 days). So it prohibits these pairs from being considered.
-1. For the remaining `<issue, merge request>` pairs, we check the information that
-   we need for the stages, like issue creation date, merge request merge time,
-   etc.
-
-To sum up, anything that doesn't follow [GitLab flow](../../workflow/gitlab_flow.md) will not be tracked and the
-Cycle Analytics dashboard will 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.
-- Staging and production stages, if the project has no `production` or `production/*`
-  environment.
-
-## Example workflow
-
-Below is a simple fictional workflow of a single cycle that happens in a
-single day passing through all seven stages. Note that if a stage does not have
-a start and a stop mark, it is not measured and hence not calculated in the median
-time. It is assumed that milestones are created and CI for testing and setting
-environments is configured.
-
-1. Issue is created at 09:00 (start of **Issue** stage).
-1. Issue is added to a milestone at 11:00 (stop of **Issue** stage / start of
-   **Plan** stage).
-1. Start working on the issue, create a branch locally and make one commit at
-   12:00.
-1. Make a second commit to the branch which mentions the issue number at 12.30
-   (stop of **Plan** stage / start of **Code** stage).
-1. Push branch and create a merge request that contains the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically)
-   in its description at 14:00 (stop of **Code** stage / start of **Test** and
-   **Review** stages).
-1. The CI starts running your scripts defined in [`.gitlab-ci.yml`](../../ci/yaml/README.md) and
-   takes 5min (stop of **Test** stage).
-1. Review merge request, ensure that everything is OK and merge the merge
-   request at 19:00. (stop of **Review** stage / start of **Staging** stage).
-1. Now that the merge request is merged, a deployment to the `production`
-   environment starts and finishes at 19:30 (stop of **Staging** stage).
-1. The cycle completes and the sum of the median times of the previous stages
-   is recorded to the **Total** stage. That is the time between creating an
-   issue and deploying its relevant merge request to production.
-
-From the above example you can conclude the time it took each stage to complete
-as long as their total time:
-
-- **Issue**:  2h (11:00 - 09:00)
-- **Plan**:   1h (12:00 - 11:00)
-- **Code**:   2h (14:00 - 12:00)
-- **Test**:   5min
-- **Review**: 5h (19:00 - 14:00)
-- **Staging**:  30min (19:30 - 19:00)
-- **Total**: Since this stage measures the sum of median time of all
-  previous stages, we cannot calculate it if we don't know the status of the
-  stages before. In case this is the very first cycle that is run in the project,
-  then the **Total** time is 10h 30min (19:30 - 09:00)
-
-A few notes:
-
-- In the above example we demonstrated that it doesn't matter if your first
-  commit doesn't mention the issue number, you can do this later in any commit
-  of the branch you are working on.
-- You can see that the **Test** stage is not calculated to the overall time of
-  the cycle since it is included in the **Review** process (every MR should be
-  tested).
-- The example above was just **one cycle** of the seven stages. Add multiple
-  cycles, calculate their median time and the result is what the dashboard of
-  Cycle Analytics is showing.
-
-## Days to completion chart
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21631) in GitLab 12.6.
-
-This chart visually depicts the total number of days it takes for cycles to be completed.
-
-This chart uses the global page filters for displaying data based on the selected
-group, projects, and timeframe. In addition, specific stages can be selected
-from within the chart itself.
-
-### Chart median line
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/36675) in GitLab 12.7.
-
-The median line on the chart displays data that is offset by the number of days selected.
-For example, if 30 days worth of data has been selected (for example, 2019-12-16 to 2020-01-15) the
-median line will represent the previous 30 days worth of data (2019-11-16 to 2019-12-16)
-as a metric to compare against.
-
-### Disabling chart
-
-This chart is enabled by default. If you have a self-managed instance, an
-administrator can open a Rails console and disable it with the following command:
-
-```ruby
-Feature.disable(:cycle_analytics_scatterplot_enabled)
-```
-
-### Disabling chart median line
-
-This chart's median line is enabled by default. If you have a self-managed instance, an
-administrator can open a Rails console and disable it with the following command:
-
-```ruby
-Feature.disable(:cycle_analytics_scatterplot_median_enabled)
-```
-
-## Permissions
-
-The current permissions on the Project Cycle Analytics dashboard are:
-
-- Public projects - anyone can access.
-- Internal projects - any authenticated user can access.
-- Private projects - any member Guest and above can access.
-
-You can [read more about permissions](../../ci/yaml/README.md) in general.
-
-NOTE: **Note:**
-As of GitLab 12.3, the project-level page is deprecated. You should access
-project-level Cycle Analytics from **Analytics > Cycle Analytics** in the top
-navigation bar. We will ensure that the same project-level functionality is available
-to CE users in the new analytics space.
-
-For Cycle Analytics functionality introduced in GitLab 12.3 and later:
-
-- Users must have Reporter access or above.
-- Features are available only on
-  [Premium or Silver tiers](https://about.gitlab.com/pricing/) and above.
-
-## More resources
-
-Learn more about Cycle Analytics in the following resources:
-
-- [Cycle Analytics feature page](https://about.gitlab.com/product/cycle-analytics/).
-- [Cycle Analytics feature preview](https://about.gitlab.com/blog/2016/09/16/feature-preview-introducing-cycle-analytics/).
-- [Cycle Analytics feature highlight](https://about.gitlab.com/blog/2016/09/21/cycle-analytics-feature-highlight/).
+This document was moved to [another location](../analytics/value_stream_analytics.md)

doc/user/analytics/index.md

@@ -16,13 +16,13 @@ Once enabled, click on **Analytics** from the top navigation bar.
 From the centralized analytics workspace, the following analytics are available:
 
 - [Code Review Analytics](code_review_analytics.md). **(STARTER)**
-- [Cycle Analytics](cycle_analytics.md), enabled with the `cycle_analytics`
+- [Value Stream Analytics](value_stream_analytics.md), enabled with the `cycle_analytics`
   [feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-in-development). **(PREMIUM)**
 - [Productivity Analytics](productivity_analytics.md), enabled with the `productivity_analytics`
   [feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-in-development). **(PREMIUM)**
 
 NOTE: **Note:**
-Project-level Cycle Analytics are still available at a project's **Project > Cycle Analytics**.
+Project-level Value Stream Analytics are still available at a project's **Project > Value Stream Analytics**.
 
 ## Other analytics tools
 

doc/user/analytics/productivity_analytics.md

@@ -7,7 +7,7 @@ Track development velocity with Productivity Analytics.
 For many companies, the development cycle is a blackbox and getting an estimate of how
 long, on average, it takes to deliver features is an enormous endeavor.
 
-While [Cycle Analytics](../project/cycle_analytics.md) focuses on the entire
+While [Value Stream Analytics](../project/cycle_analytics.md) focuses on the entire
 Software Development Life Cycle (SDLC) process, Productivity Analytics provides a way for Engineering Management to drill down in a systematic way to uncover patterns and causes for success or failure at an individual, project or group level.
 
 Productivity can slow down for many reasons ranging from degrading code base to quickly growing teams. In order to investigate, department or team leaders can start by visualizing the time it takes for merge requests to be merged.

doc/user/analytics/value_stream_analytics.md

+# Value Stream Analytics
+
+> - Introduced as Cycle Analytics prior to GitLab 12.3 at the project level.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12077) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3 at the group level.
+> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23427) from Cycle Analytics to Value Stream Analytics in GitLab 12.8.
+
+Value Stream Analytics measures the time spent to go from an
+[idea to production](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#from-idea-to-production-with-gitlab)
+(also known as cycle time) for each of your projects. Value Stream Analytics displays the median time
+spent in each stage defined in the process.
+
+For information on how to contribute to the development of Value Stream Analytics, see our [contributor documentation](../../development/value_stream_analytics.md).
+
+NOTE: **Note:**
+Use the `cycle_analytics` feature flag to enable at the group level.
+
+Value Stream Analytics is useful in order to quickly determine the velocity of a given
+project. It points to bottlenecks in the development process, enabling management
+to uncover, triage, and identify the root cause of slowdowns in the software development life cycle.
+
+Value Stream Analytics is tightly coupled with the [GitLab flow](../../topics/gitlab_flow.md) and
+calculates a separate median for each stage.
+
+## Overview
+
+Value Stream Analytics is available:
+
+- From GitLab 12.3, at the group level in the analytics workspace (top navigation bar) at
+  **Analytics > Value Stream Analytics**. **(PREMIUM)**
+
+  In the future, multiple groups will be selectable which will effectively make this an
+  instance-level feature.
+
+- At the project level via **Project > Value Stream Analytics**.
+
+There are seven stages that are tracked as part of the Value Stream Analytics calculations.
+
+- **Issue** (Tracker)
+  - Time to schedule an issue (by milestone or by adding it to an issue board)
+- **Plan** (Board)
+  - Time to first commit
+- **Code** (IDE)
+  - Time to create a merge request
+- **Test** (CI)
+  - Time it takes GitLab CI/CD to test your code
+- **Review** (Merge Request/MR)
+  - Time spent on code review
+- **Staging** (Continuous Deployment)
+  - Time between merging and deploying to production
+- **Total** (Total)
+  - Total lifecycle time. That is, the velocity of the project or team. [Previously known](https://gitlab.com/gitlab-org/gitlab/issues/38317) as **Production**.
+
+## Date ranges
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/13216) in GitLab 12.4.
+
+GitLab provides the ability to filter analytics based on a date range. To filter results:
+
+1. Select a group.
+1. Optionally select a project.
+1. Select a date range using the available date pickers.
+
+## How the data is measured
+
+Value Stream Analytics records cycle time and data based on the project issues with the
+exception of the staging and total stages, where only data deployed to
+production are measured.
+
+Specifically, if your CI is not set up and you have not defined a `production`
+or `production/*` [environment](../../ci/yaml/README.md#environment), then you will not have any
+data for this stage.
+
+Each stage of Value Stream Analytics is further described in the table below.
+
+| **Stage** | **Description** |
+| --------- | --------------- |
+| Issue     | Measures the median time between creating an issue and taking action to solve it, by either labeling it or adding it to a milestone, whatever comes first. The label will be tracked only if it already has an [Issue Board list](../project/issue_board.md#creating-a-new-list) created for it. |
+| Plan      | Measures the median time between the action you took for the previous stage, and pushing the first commit to the branch. The very first commit of the branch is the one that triggers the separation between **Plan** and **Code**, and at least one of the commits in the branch needs to contain the related issue number (e.g., `#42`). If none of the commits in the branch mention the related issue number, it is not considered to the measurement time of the stage. |
+| Code      | Measures the median time between pushing a first commit (previous stage) and creating a merge request (MR) related to that commit. The key to keep the process tracked is to include the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically) to the description of the merge request (for example, `Closes #xxx`, where `xxx` is the number of the issue related to this merge request). If the issue closing pattern is not present in the merge request description, the MR is not considered to the measurement time of the stage. |
+| Test      | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI takes to run every job for the commits pushed to that merge request defined in the previous stage. It is basically the start->finish time for all pipelines. |
+| Review    | Measures the median time taken to review the merge request that has closing issue pattern, between its creation and until it's merged. |
+| Staging   | Measures the median time between merging the merge request with closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI configuration. If there isn't a production environment, this is not tracked. |
+| Total | The sum of all time (medians) taken to run the entire process, from issue creation to deploying the code to production. [Previously known](https://gitlab.com/gitlab-org/gitlab/issues/38317) as **Production**. |
+
+How this works, behind the scenes:
+
+1. Issues and merge requests are grouped together in pairs, such that for each
+   `<issue, merge request>` pair, the merge request has the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically)
+   for the corresponding issue. All other issues and merge requests are **not**
+   considered.
+1. Then the `<issue, merge request>` pairs are filtered out by last XX days (specified
+   by the UI - default is 90 days). So it prohibits these pairs from being considered.
+1. For the remaining `<issue, merge request>` pairs, we check the information that
+   we need for the stages, like issue creation date, merge request merge time,
+   etc.
+
+To sum up, anything that doesn't follow [GitLab flow](../../workflow/gitlab_flow.md) will not be tracked and the
+Value Stream Analytics dashboard will 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.
+- Staging and production stages, if the project has no `production` or `production/*`
+  environment.
+
+## Example workflow
+
+Below is a simple fictional workflow of a single cycle that happens in a
+single day passing through all seven stages. Note that if a stage does not have
+a start and a stop mark, it is not measured and hence not calculated in the median
+time. It is assumed that milestones are created and CI for testing and setting
+environments is configured.
+
+1. Issue is created at 09:00 (start of **Issue** stage).
+1. Issue is added to a milestone at 11:00 (stop of **Issue** stage / start of
+   **Plan** stage).
+1. Start working on the issue, create a branch locally and make one commit at
+   12:00.
+1. Make a second commit to the branch which mentions the issue number at 12.30
+   (stop of **Plan** stage / start of **Code** stage).
+1. Push branch and create a merge request that contains the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically)
+   in its description at 14:00 (stop of **Code** stage / start of **Test** and
+   **Review** stages).
+1. The CI starts running your scripts defined in [`.gitlab-ci.yml`](../../ci/yaml/README.md) and
+   takes 5min (stop of **Test** stage).
+1. Review merge request, ensure that everything is OK and merge the merge
+   request at 19:00. (stop of **Review** stage / start of **Staging** stage).
+1. Now that the merge request is merged, a deployment to the `production`
+   environment starts and finishes at 19:30 (stop of **Staging** stage).
+1. The cycle completes and the sum of the median times of the previous stages
+   is recorded to the **Total** stage. That is the time between creating an
+   issue and deploying its relevant merge request to production.
+
+From the above example you can conclude the time it took each stage to complete
+as long as their total time:
+
+- **Issue**:  2h (11:00 - 09:00)
+- **Plan**:   1h (12:00 - 11:00)
+- **Code**:   2h (14:00 - 12:00)
+- **Test**:   5min
+- **Review**: 5h (19:00 - 14:00)
+- **Staging**:  30min (19:30 - 19:00)
+- **Total**: Since this stage measures the sum of median time of all
+  previous stages, we cannot calculate it if we don't know the status of the
+  stages before. In case this is the very first cycle that is run in the project,
+  then the **Total** time is 10h 30min (19:30 - 09:00)
+
+A few notes:
+
+- In the above example we demonstrated that it doesn't matter if your first
+  commit doesn't mention the issue number, you can do this later in any commit
+  of the branch you are working on.
+- You can see that the **Test** stage is not calculated to the overall time of
+  the cycle since it is included in the **Review** process (every MR should be
+  tested).
+- The example above was just **one cycle** of the seven stages. Add multiple
+  cycles, calculate their median time and the result is what the dashboard of
+  Value Stream Analytics is showing.
+
+## Days to completion chart
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21631) in GitLab 12.6.
+
+This chart visually depicts the total number of days it takes for cycles to be completed.
+
+This chart uses the global page filters for displaying data based on the selected
+group, projects, and timeframe. In addition, specific stages can be selected
+from within the chart itself.
+
+### Chart median line
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/36675) in GitLab 12.7.
+
+The median line on the chart displays data that is offset by the number of days selected.
+For example, if 30 days worth of data has been selected (for example, 2019-12-16 to 2020-01-15) the
+median line will represent the previous 30 days worth of data (2019-11-16 to 2019-12-16)
+as a metric to compare against.
+
+### Disabling chart
+
+This chart is enabled by default. If you have a self-managed instance, an
+administrator can open a Rails console and disable it with the following command:
+
+```ruby
+Feature.disable(:cycle_analytics_scatterplot_enabled)
+```
+
+### Disabling chart median line
+
+This chart's median line is enabled by default. If you have a self-managed instance, an
+administrator can open a Rails console and disable it with the following command:
+
+```ruby
+Feature.disable(:cycle_analytics_scatterplot_median_enabled)
+```
+
+## Permissions
+
+The current permissions on the Project Value Stream Analytics dashboard are:
+
+- Public projects - anyone can access.
+- Internal projects - any authenticated user can access.
+- Private projects - any member Guest and above can access.
+
+You can [read more about permissions](../../ci/yaml/README.md) in general.
+
+NOTE: **Note:**
+As of GitLab 12.3, the project-level page is deprecated. You should access
+project-level Value Stream Analytics from **Analytics > Value Stream Analytics** in the top
+navigation bar. We will ensure that the same project-level functionality is available
+to CE users in the new analytics space.
+
+For Value Stream Analytics functionality introduced in GitLab 12.3 and later:
+
+- Users must have Reporter access or above.
+- Features are available only on
+  [Premium or Silver tiers](https://about.gitlab.com/pricing/) and above.
+
+## More resources
+
+Learn more about Value Stream Analytics in the following resources:
+
+- [Value Stream Analytics feature page](https://about.gitlab.com/product/cycle-analytics/).
+- [Value Stream Analytics feature preview](https://about.gitlab.com/blog/2016/09/16/feature-preview-introducing-cycle-analytics/).
+- [Value Stream Analytics feature highlight](https://about.gitlab.com/blog/2016/09/21/cycle-analytics-feature-highlight/).

doc/user/index.md

@@ -45,7 +45,7 @@ GitLab is a Git-based platform that integrates a great number of essential tools
 - Building, testing, and deploying with built-in [Continuous Integration](../ci/README.md).
 - Deploying personal and professional static websites with [GitLab Pages](project/pages/index.md).
 - Integrating with Docker by using [GitLab Container Registry](packages/container_registry/index.md).
-- Tracking the development lifecycle by using [GitLab Cycle Analytics](project/cycle_analytics.md).
+- Tracking the development lifecycle by using [GitLab Value Stream Analytics](project/cycle_analytics.md).
 
 With GitLab Enterprise Edition, you can also:
 

doc/user/permissions.md

@@ -139,10 +139,10 @@ The following table depicts the various user permission levels in a project.
 | Force push to protected branches (*4*)            |         |            |             |          |        |
 | Remove protected branches (*4*)                   |         |            |             |          |        |
 
-\* Owner permission is only available at the group or personal namespace level (and for instance admins) and is inherited by its projects.  
-(*1*): Guest users are able to perform this action on public and internal projects, but not private projects.  
-(*2*): Guest users can only view the confidential issues they created themselves.  
-(*3*): If **Public pipelines** is enabled in **Project Settings > CI/CD**.  
+\* Owner permission is only available at the group or personal namespace level (and for instance admins) and is inherited by its projects.
+(*1*): Guest users are able to perform this action on public and internal projects, but not private projects.
+(*2*): Guest users can only view the confidential issues they created themselves.
+(*3*): If **Public pipelines** is enabled in **Project Settings > CI/CD**.
 (*4*): Not allowed for Guest, Reporter, Developer, Maintainer, or Owner. See [Protected Branches](./project/protected_branches.md).
 
 ## Project features permissions
@@ -165,10 +165,10 @@ Maintainers and Developers from pushing to a protected branch. Read through the
 [Allowed to Merge and Allowed to Push settings](project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings)
 to learn more.
 
-### Cycle Analytics permissions
+### Value Stream Analytics permissions
 
-Find the current permissions on the Cycle Analytics dashboard on
-the [documentation on Cycle Analytics permissions](analytics/cycle_analytics.md#permissions).
+Find the current permissions on the Value Stream Analytics dashboard, as described in
+[related documentation](analytics/value_stream_analytics.md#permissions).
 
 ### Issue Board permissions
 

doc/user/project/cycle_analytics.md

 ---
-redirect_to: '../analytics/cycle_analytics.md'
+redirect_to: '../analytics/value_stream_analytics.md'
 ---
 
-This document was moved to [another location](../analytics/cycle_analytics.md)
+This document was moved to [another location](../analytics/value_stream_analytics.md)

doc/user/project/index.md

@@ -87,7 +87,7 @@ When you create a project in GitLab, you'll have access to a large number of
 
 - [Wiki](wiki/index.md): document your GitLab project in an integrated Wiki.
 - [Snippets](../snippets.md): store, share and collaborate on code snippets.
-- [Cycle Analytics](cycle_analytics.md): review your development lifecycle.
+- [Value Stream Analytics](cycle_analytics.md): review your development lifecycle.
 - [Insights](insights/index.md): configure the Insights that matter for your projects. **(ULTIMATE)**
 - [Security Dashboard](security_dashboard.md): Security Dashboard. **(ULTIMATE)**
 - [Syntax highlighting](highlighting.md): an alternative to customize

ee/app/assets/javascripts/analytics/cycle_analytics/components/base.vue

@@ -203,7 +203,7 @@ export default {
 <template>
   <div class="js-cycle-analytics">
     <div class="page-title-holder d-flex align-items-center">
-      <h3 class="page-title">{{ __('Cycle Analytics') }}</h3>
+      <h3 class="page-title">{{ __('Value Stream Analytics') }}</h3>
     </div>
     <div class="mw-100">
       <div
@@ -239,7 +239,7 @@ export default {
     </div>
     <gl-empty-state
       v-if="shouldRenderEmptyState"
-      :title="__('Cycle Analytics can help you determine your team’s velocity')"
+      :title="__('Value Stream Analytics can help you determine your team’s velocity')"
       :description="
         __(
           'Start by choosing a group to see how your team is spending time. You can then drill down to the project level.',
@@ -251,11 +251,11 @@ export default {
       <gl-empty-state
         v-if="hasNoAccessError"
         class="js-empty-state"
-        :title="__('You don’t have access to Cycle Analytics for this group')"
+        :title="__('You don’t have access to Value Stream Analytics for this group')"
         :svg-path="noAccessSvgPath"
         :description="
           __(
-            'Only \'Reporter\' roles and above on tiers Premium / Silver and above can see Cycle Analytics.',
+            'Only \'Reporter\' roles and above on tiers Premium / Silver and above can see Value Stream Analytics.',
           )
         "
       />

ee/app/assets/javascripts/analytics/cycle_analytics/mixins/filter_mixins.js

@@ -14,7 +14,7 @@ export default {
     },
     setSelectedGroup(selectedGroup) {
       this.selectedGroup = selectedGroup;
-      this.renderSelectedGroup(`/groups/${selectedGroup.path}/-/cycle_analytics`);
+      this.renderSelectedGroup(`/groups/${selectedGroup.path}/-/value_stream_analytics`);
     },
     setSelectedProjects(selectedProjects) {
       this.selectedProjectIds = selectedProjects.map(value => value.id);

ee/app/assets/javascripts/analytics/cycle_analytics/store/actions.js

@@ -119,7 +119,7 @@ export const receiveCycleAnalyticsDataError = ({ commit }, { response }) => {
   commit(types.RECEIVE_CYCLE_ANALYTICS_DATA_ERROR, status);
 
   if (status !== httpStatus.FORBIDDEN)
-    createFlash(__('There was an error while fetching cycle analytics data.'));
+    createFlash(__('There was an error while fetching value stream analytics data.'));
 };
 
 export const fetchCycleAnalyticsData = ({ dispatch }) => {
@@ -147,7 +147,7 @@ export const requestSummaryData = ({ commit }) => commit(types.REQUEST_SUMMARY_D
 
 export const receiveSummaryDataError = ({ commit }, error) => {
   commit(types.RECEIVE_SUMMARY_DATA_ERROR, error);
-  createFlash(__('There was an error while fetching cycle analytics summary data.'));
+  createFlash(__('There was an error while fetching value stream analytics summary data.'));
 };
 
 export const receiveSummaryDataSuccess = ({ commit }, data) =>
@@ -198,7 +198,7 @@ export const fetchGroupLabels = ({ dispatch, state }) => {
 
 export const receiveGroupStagesAndEventsError = ({ commit }, error) => {
   commit(types.RECEIVE_GROUP_STAGES_AND_EVENTS_ERROR, error);
-  createFlash(__('There was an error fetching cycle analytics stages.'));
+  createFlash(__('There was an error fetching value stream analytics stages.'));
 };
 
 export const receiveGroupStagesAndEventsSuccess = ({ state, commit, dispatch }, data) => {
@@ -209,7 +209,7 @@ export const receiveGroupStagesAndEventsSuccess = ({ state, commit, dispatch },
     dispatch('setSelectedStage', firstStage);
     dispatch('fetchStageData', firstStage.slug);
   } else {
-    createFlash(__('There was an error while fetching cycle analytics data.'));
+    createFlash(__('There was an error while fetching value stream analytics data.'));
   }
 };
 
@@ -386,7 +386,7 @@ export const receiveDurationDataSuccess = ({ commit, state, dispatch }, data) =>
 
 export const receiveDurationDataError = ({ commit }) => {
   commit(types.RECEIVE_DURATION_DATA_ERROR);
-  createFlash(__('There was an error while fetching cycle analytics duration data.'));
+  createFlash(__('There was an error while fetching value stream analytics duration data.'));
 };
 
 export const fetchDurationData = ({ state, dispatch, getters }) => {
@@ -430,7 +430,7 @@ export const receiveDurationMedianDataSuccess = ({ commit }, data) =>
 
 export const receiveDurationMedianDataError = ({ commit }) => {
   commit(types.RECEIVE_DURATION_MEDIAN_DATA_ERROR);
-  createFlash(__('There was an error while fetching cycle analytics duration median data.'));
+  createFlash(__('There was an error while fetching value stream analytics duration median data.'));
 };
 
 export const fetchDurationMedianData = ({ state, dispatch }) => {

ee/app/assets/javascripts/analytics/cycle_analytics/utils.js

@@ -45,7 +45,7 @@ export const getLabelEventsIdentifiers = (events = []) =>
 /**
  * Checks if the specified stage is in memory or persisted to storage based on the id
  *
- * Default cycle analytics stages are initially stored in memory, when they are first
+ * Default value stream analytics stages are initially stored in memory, when they are first
  * created the id for the stage is the name of the stage in lowercase. This string id
  * is used to fetch stage data (events, median calculation)
  *

ee/app/assets/javascripts/api.js

@@ -17,12 +17,13 @@ export default {
   projectPackagesPath: '/api/:version/projects/:id/packages',
   projectPackagePath: '/api/:version/projects/:id/packages/:package_id',
   cycleAnalyticsTasksByTypePath: '/-/analytics/type_of_work/tasks_by_type',
-  cycleAnalyticsSummaryDataPath: '/-/analytics/cycle_analytics/summary',
-  cycleAnalyticsGroupStagesAndEventsPath: '/-/analytics/cycle_analytics/stages',
-  cycleAnalyticsStageEventsPath: '/-/analytics/cycle_analytics/stages/:stage_id/records',
-  cycleAnalyticsStageMedianPath: '/-/analytics/cycle_analytics/stages/:stage_id/median',
-  cycleAnalyticsStagePath: '/-/analytics/cycle_analytics/stages/:stage_id',
-  cycleAnalyticsDurationChartPath: '/-/analytics/cycle_analytics/stages/:stage_id/duration_chart',
+  cycleAnalyticsSummaryDataPath: '/-/analytics/value_stream_analytics/summary',
+  cycleAnalyticsGroupStagesAndEventsPath: '/-/analytics/value_stream_analytics/stages',
+  cycleAnalyticsStageEventsPath: '/-/analytics/value_stream_analytics/stages/:stage_id/records',
+  cycleAnalyticsStageMedianPath: '/-/analytics/value_stream_analytics/stages/:stage_id/median',
+  cycleAnalyticsStagePath: '/-/analytics/value_stream_analytics/stages/:stage_id',
+  cycleAnalyticsDurationChartPath:
+    '/-/analytics/value_stream_analytics/stages/:stage_id/duration_chart',
   codeReviewAnalyticsPath: '/api/:version/analytics/code_review',
   countriesPath: '/-/countries',
   countryStatesPath: '/-/country_states',

ee/app/views/analytics/cycle_analytics/show.html.haml

-- page_title _("Cycle Analytics")
+- page_title _("Value Stream Analytics")
 - initial_data = @request_params.valid? ? @request_params.to_data_attributes : {}
 
 #js-cycle-analytics-app{ data: initial_data.merge({ empty_state_svg_path: image_path("illustrations/analytics/cycle-analytics-empty-chart.svg"),

ee/app/views/layouts/nav/sidebar/_analytics.html.haml

@@ -25,12 +25,12 @@
             .nav-icon-container
               = sprite_icon('repeat')
             %span.nav-item-name
-              = _('Cycle Analytics')
+              = _('Value Stream Analytics')
           %ul.sidebar-sub-level-items.is-fly-out-only
             = nav_link(controller: :cycle_analytics, html_options: { class: "fly-out-top-item qa-sidebar-cycle-analytics-fly-out" } ) do
               = link_to analytics_cycle_analytics_path do
                 %strong.fly-out-top-item-name
-                  = _('Cycle Analytics')
+                  = _('Value Stream Analytics')
 
       = render_ce 'layouts/nav/sidebar/instance_statistics_links'
 

ee/config/routes/analytics.rb

@@ -6,8 +6,8 @@ namespace :analytics do
   resource :productivity_analytics, only: :show, constraints: -> (req) { Feature.disabled?(:group_level_productivity_analytics) && Gitlab::Analytics.productivity_analytics_enabled? }
 
   constraints(-> (req) { Gitlab::Analytics.cycle_analytics_enabled? }) do
-    resource :cycle_analytics, only: :show
-    namespace :cycle_analytics do
+    resource :cycle_analytics, only: :show, path: 'value_stream_analytics'
+    scope module: :cycle_analytics, as: 'cycle_analytics', path: 'value_stream_analytics' do
       resources :stages, only: [:index, :create, :update, :destroy] do
         member do
           get :duration_chart
@@ -15,8 +15,9 @@ namespace :analytics do
           get :records
         end
       end
-      resource :summary, controller: :summary, only: [:show]
+      resource :summary, controller: :summary, only: :show
     end
+    get '/cycle_analytics', to: redirect('-/analytics/value_stream_analytics')
   end
 
   constraints(::Constraints::FeatureConstrainer.new(Gitlab::Analytics::TASKS_BY_TYPE_CHART_FEATURE_FLAG)) do

ee/config/routes/group.rb

@@ -19,8 +19,8 @@ constraints(::Constraints::GroupUrlConstrainer.new) do
 
     get '/analytics', to: redirect('groups/%{group_id}/-/contribution_analytics')
     resource :contribution_analytics, only: [:show]
-    resource :cycle_analytics, only: [:show]
-    namespace :cycle_analytics do
+    resource :cycle_analytics, only: [:show], path: 'value_stream_analytics'
+    scope module: :cycle_analytics, as: 'cycle_analytics', path: 'value_stream_analytics' do
       scope :events, controller: 'events' do
         get :issue
         get :plan

ee/db/fixtures/development/30_customizable_cycle_analytics.rb

@@ -160,7 +160,7 @@ class Gitlab::Seeder::CustomizableCycleAnalytics
   def merge_requests
     @merge_requests ||= Array.new(MERGE_REQUEST_COUNT).map do |i|
       opts = {
-        title: 'Customized Cycle Analytics merge_request',
+        title: 'Customized Value Stream Analytics merge_request',
         description: "some description",
         source_branch: "#{FFaker::Lorem.word}-#{i}-#{SecureRandom.hex(5)}",
         target_branch: 'master'

ee/spec/controllers/analytics/analytics_controller_spec.rb

@@ -16,7 +16,7 @@ describe Analytics::AnalyticsController do
 
   describe 'GET index' do
     describe 'redirects to the first enabled analytics page' do
-      it 'redirects to cycle analytics' do
+      it 'redirects to value stream analytics' do
         stub_feature_flags(Gitlab::Analytics::CYCLE_ANALYTICS_FEATURE_FLAG => true)
 
         get :index

ee/spec/features/analytics/cycle_analytics/cycle_analytics_spec.rb

 # frozen_string_literal: true
 require 'spec_helper'
 
-describe 'Group Cycle Analytics', :js do
+describe 'Group Value Stream Analytics', :js do
   let!(:user) { create(:user) }
   let!(:group) { create(:group, name: "CA-test-group") }
   let!(:project) { create(:project, :repository, namespace: group, group: group, name: "Cool fun project") }
@@ -32,7 +32,7 @@ describe 'Group Cycle Analytics', :js do
   it 'displays an empty state before a group is selected' do
     element = page.find('.row.empty-state')
 
-    expect(element).to have_content("Cycle Analytics can help you determine your team’s velocity")
+    expect(element).to have_content("Value Stream Analytics can help you determine your team’s velocity")
     expect(element.find('.svg-content img')['src']).to have_content('illustrations/analytics/cycle-analytics-empty-chart')
   end
 
@@ -78,7 +78,7 @@ describe 'Group Cycle Analytics', :js do
 
   it 'displays empty text' do
     [
-      'Cycle Analytics can help you determine your team’s velocity',
+      'Value Stream Analytics can help you determine your team’s velocity',
       'Start by choosing a group to see how your team is spending time. You can then drill down to the project level.'
     ].each do |content|
       expect(page).to have_content(content)

ee/spec/fixtures/gitlab_com_plans.json

@@ -21,7 +21,7 @@
             },
             {
                 "highlight": false,
-                "title": "Cycle Analytics"
+                "title": "Value Stream Analytics"
             },
             {
                 "highlight": false,

ee/spec/frontend/analytics/cycle_analytics/components/base_spec.js

@@ -424,12 +424,12 @@ describe('Cycle Analytics component', () => {
       const defaultRequests = {
         fetchSummaryData: {
           status: defaultStatus,
-          endpoint: `/-/analytics/cycle_analytics/summary`,
+          endpoint: `/-/analytics/value_stream_analytics/summary`,
           response: [...mockData.summaryData],
         },
         fetchGroupStagesAndEvents: {
           status: defaultStatus,
-          endpoint: `/-/analytics/cycle_analytics/stages`,
+          endpoint: `/-/analytics/value_stream_analytics/stages`,
           response: { ...mockData.customizableStagesAndEvents },
         },
         fetchGroupLabels: {
@@ -448,19 +448,19 @@ describe('Cycle Analytics component', () => {
 
       if (mockFetchDurationData) {
         mock
-          .onGet(/analytics\/cycle_analytics\/stages\/\d+\/duration_chart/)
+          .onGet(/analytics\/value_stream_analytics\/stages\/\d+\/duration_chart/)
           .reply(defaultStatus, [...mockData.rawDurationData]);
       }
 
       if (mockFetchStageMedian) {
         mock
-          .onGet(/analytics\/cycle_analytics\/stages\/\d+\/median/)
+          .onGet(/analytics\/value_stream_analytics\/stages\/\d+\/median/)
           .reply(defaultStatus, { value: null });
       }
 
       if (mockFetchStageData) {
         mock
-          .onGet(/analytics\/cycle_analytics\/stages\/\d+\/records/)
+          .onGet(/analytics\/value_stream_analytics\/stages\/\d+\/records/)
           .reply(defaultStatus, mockData.issueEvents);
       }
 
@@ -497,14 +497,14 @@ describe('Cycle Analytics component', () => {
         overrides: {
           fetchSummaryData: {
             status: httpStatusCodes.NOT_FOUND,
-            endpoint: '/-/analytics/cycle_analytics/summary',
+            endpoint: '/-/analytics/value_stream_analytics/summary',
             response: { response: { status: httpStatusCodes.NOT_FOUND } },
           },
         },
       });
 
       return selectGroupAndFindError(
-        'There was an error while fetching cycle analytics summary data.',
+        'There was an error while fetching value stream analytics summary data.',
       );
     });
 
@@ -531,14 +531,14 @@ describe('Cycle Analytics component', () => {
       mockRequestCycleAnalyticsData({
         overrides: {
           fetchGroupStagesAndEvents: {
-            endPoint: '/-/analytics/cycle_analytics/stages',
+            endPoint: '/-/analytics/value_stream_analytics/stages',
             status: httpStatusCodes.NOT_FOUND,
             response: { response: { status: httpStatusCodes.NOT_FOUND } },
           },
         },
       });
 
-      return selectGroupAndFindError('There was an error fetching cycle analytics stages.');
+      return selectGroupAndFindError('There was an error fetching value stream analytics stages.');
     });
 
     it('will display an error if the fetchStageData request fails', () => {
@@ -572,7 +572,7 @@ describe('Cycle Analytics component', () => {
 
       return waitForPromises().catch(() => {
         expect(findFlashError().innerText.trim()).toEqual(
-          'There was an error while fetching cycle analytics duration data.',
+          'There was an error while fetching value stream analytics duration data.',
         );
       });
     });
@@ -588,7 +588,7 @@ describe('Cycle Analytics component', () => {
 
       return waitForPromises().catch(() => {
         expect(findFlashError().innerText.trim()).toEqual(
-          'There was an error while fetching cycle analytics duration data.',
+          'There was an error while fetching value stream analytics duration data.',
         );
       });
     });

ee/spec/frontend/analytics/cycle_analytics/components/labels_selector_spec.js

@@ -4,7 +4,7 @@ import { groupLabels } from '../mock_data';
 
 const selectedLabel = groupLabels[groupLabels.length - 1];
 
-describe('Cycle Analytics LabelsSelector', () => {
+describe('Value Stream Analytics LabelsSelector', () => {
   function createComponent({ props = {}, shallow = true } = {}) {
     const func = shallow ? shallowMount : mount;
     return func(LabelsSelector, {

ee/spec/frontend/analytics/cycle_analytics/mock_data.js

@@ -11,10 +11,10 @@ import { toYmd } from 'ee/analytics/shared/utils';
 import { transformRawTasksByTypeData } from 'ee/analytics/cycle_analytics/utils';
 
 const endpoints = {
-  customizableCycleAnalyticsStagesAndEvents: 'analytics/cycle_analytics/stages.json', // customizable stages and events endpoint
-  stageEvents: stage => `analytics/cycle_analytics/stages/${stage}/records.json`,
-  stageMedian: stage => `analytics/cycle_analytics/stages/${stage}/median.json`,
-  summaryData: 'analytics/cycle_analytics/summary.json',
+  customizableCycleAnalyticsStagesAndEvents: 'analytics/value_stream_analytics/stages.json', // customizable stages and events endpoint
+  stageEvents: stage => `analytics/value_stream_analytics/stages/${stage}/records.json`,
+  stageMedian: stage => `analytics/value_stream_analytics/stages/${stage}/median.json`,
+  summaryData: 'analytics/value_stream_analytics/summary.json',
 };
 
 export const groupLabels = mockLabels.map(({ title, ...rest }) => ({ ...rest, name: title }));

ee/spec/frontend/analytics/cycle_analytics/store/actions_spec.js

@@ -22,20 +22,20 @@ import {
 
 const stageData = { events: [] };
 const error = new Error('Request failed with status code 404');
-const flashErrorMessage = 'There was an error while fetching cycle analytics data.';
+const flashErrorMessage = 'There was an error while fetching value stream analytics data.';
 const selectedGroup = { fullPath: group.path };
 const [selectedStage] = stages;
 const selectedStageSlug = selectedStage.slug;
 const endpoints = {
   groupLabels: `/groups/${group.path}/-/labels`,
-  summaryData: '/analytics/cycle_analytics/summary',
-  durationData: /analytics\/cycle_analytics\/stages\/\d+\/duration_chart/,
-  stageData: /analytics\/cycle_analytics\/stages\/\d+\/records/,
-  stageMedian: /analytics\/cycle_analytics\/stages\/\d+\/median/,
-  baseStagesEndpoint: '/analytics/cycle_analytics/stages',
+  summaryData: '/analytics/value_stream_analytics/summary',
+  durationData: /analytics\/value_stream_analytics\/stages\/\d+\/duration_chart/,
+  stageData: /analytics\/value_stream_analytics\/stages\/\d+\/records/,
+  stageMedian: /analytics\/value_stream_analytics\/stages\/\d+\/median/,
+  baseStagesEndpoint: '/analytics/value_stream_analytics/stages',
 };
 
-const stageEndpoint = ({ stageId }) => `/-/analytics/cycle_analytics/stages/${stageId}`;
+const stageEndpoint = ({ stageId }) => `/-/analytics/value_stream_analytics/stages/${stageId}`;
 
 describe('Cycle analytics actions', () => {
   let state;
@@ -276,7 +276,7 @@ describe('Cycle analytics actions', () => {
       state = { ...state, selectedGroup, startDate, endDate };
     });
 
-    it(`dispatches actions for required cycle analytics data`, done => {
+    it(`dispatches actions for required value stream analytics analytics data`, done => {
       testAction(
         actions.fetchCycleAnalyticsData,
         state,
@@ -368,7 +368,9 @@ describe('Cycle analytics actions', () => {
           commit: () => {},
         })
         .then(() => {
-          shouldFlashAMessage('There was an error while fetching cycle analytics summary data.');
+          shouldFlashAMessage(
+            'There was an error while fetching value stream analytics summary data.',
+          );
           done();
         })
         .catch(done.fail);
@@ -394,7 +396,7 @@ describe('Cycle analytics actions', () => {
           commit: () => {},
         })
         .then(() => {
-          shouldFlashAMessage('There was an error fetching cycle analytics stages.');
+          shouldFlashAMessage('There was an error fetching value stream analytics stages.');
           done();
         })
         .catch(done.fail);
@@ -425,7 +427,9 @@ describe('Cycle analytics actions', () => {
         {},
       );
 
-      shouldFlashAMessage('There was an error while fetching cycle analytics duration data.');
+      shouldFlashAMessage(
+        'There was an error while fetching value stream analytics duration data.',
+      );
     });
 
     describe('with an existing error', () => {
@@ -925,7 +929,9 @@ describe('Cycle analytics actions', () => {
         commit: () => {},
       });
 
-      shouldFlashAMessage('There was an error while fetching cycle analytics duration data.');
+      shouldFlashAMessage(
+        'There was an error while fetching value stream analytics duration data.',
+      );
     });
   });
 
@@ -1149,7 +1155,7 @@ describe('Cycle analytics actions', () => {
       });
 
       shouldFlashAMessage(
-        'There was an error while fetching cycle analytics duration median data.',
+        'There was an error while fetching value stream analytics duration median data.',
       );
     });
   });

ee/spec/frontend/api_spec.js

@@ -380,13 +380,13 @@ describe('Api', () => {
     });
 
     describe('cycleAnalyticsSummaryData', () => {
-      it('fetches cycle analytics summary data', done => {
+      it('fetches value stream analytics summary data', done => {
         const response = [{ value: 0, title: 'New Issues' }, { value: 0, title: 'Deploys' }];
         const params = {
           ...defaultParams,
         };
 
-        const expectedUrl = `${dummyUrlRoot}/-/analytics/cycle_analytics/summary`;
+        const expectedUrl = `${dummyUrlRoot}/-/analytics/value_stream_analytics/summary`;
         mock.onGet(expectedUrl).reply(200, response);
 
         Api.cycleAnalyticsSummaryData(params)
@@ -410,7 +410,7 @@ describe('Api', () => {
           'cycle_analytics[created_after]': createdAfter,
           'cycle_analytics[created_before]': createdBefore,
         };
-        const expectedUrl = `${dummyUrlRoot}/-/analytics/cycle_analytics/stages`;
+        const expectedUrl = `${dummyUrlRoot}/-/analytics/value_stream_analytics/stages`;
         mock.onGet(expectedUrl).reply(200, response);
 
         Api.cycleAnalyticsGroupStagesAndEvents(groupId, params)
@@ -432,7 +432,7 @@ describe('Api', () => {
         const params = {
           ...defaultParams,
         };
-        const expectedUrl = `${dummyUrlRoot}/-/analytics/cycle_analytics/stages/${stageId}/records`;
+        const expectedUrl = `${dummyUrlRoot}/-/analytics/value_stream_analytics/stages/${stageId}/records`;
         mock.onGet(expectedUrl).reply(200, response);
 
         Api.cycleAnalyticsStageEvents(groupId, stageId, params)
@@ -454,7 +454,7 @@ describe('Api', () => {
         const params = {
           ...defaultParams,
         };
-        const expectedUrl = `${dummyUrlRoot}/-/analytics/cycle_analytics/stages/${stageId}/median`;
+        const expectedUrl = `${dummyUrlRoot}/-/analytics/value_stream_analytics/stages/${stageId}/median`;
         mock.onGet(expectedUrl).reply(200, response);
 
         Api.cycleAnalyticsStageMedian(groupId, stageId, params)
@@ -480,7 +480,7 @@ describe('Api', () => {
           end_event_identifier: 'issue_closed',
           end_event_label_id: null,
         };
-        const expectedUrl = `${dummyUrlRoot}/-/analytics/cycle_analytics/stages`;
+        const expectedUrl = `${dummyUrlRoot}/-/analytics/value_stream_analytics/stages`;
         mock.onPost(expectedUrl).reply(200, response);
 
         Api.cycleAnalyticsCreateStage(groupId, customStage)
@@ -502,7 +502,7 @@ describe('Api', () => {
           name: 'nice-stage',
           hidden: true,
         };
-        const expectedUrl = `${dummyUrlRoot}/-/analytics/cycle_analytics/stages/${stageId}`;
+        const expectedUrl = `${dummyUrlRoot}/-/analytics/value_stream_analytics/stages/${stageId}`;
         mock.onPut(expectedUrl).reply(200, response);
 
         Api.cycleAnalyticsUpdateStage(stageId, groupId, stageData)
@@ -520,7 +520,7 @@ describe('Api', () => {
     describe('cycleAnalyticsRemoveStage', () => {
       it('deletes the specified data', done => {
         const response = { id: stageId, hidden: true, custom: true };
-        const expectedUrl = `${dummyUrlRoot}/-/analytics/cycle_analytics/stages/${stageId}`;
+        const expectedUrl = `${dummyUrlRoot}/-/analytics/value_stream_analytics/stages/${stageId}`;
         mock.onDelete(expectedUrl).reply(200, response);
 
         Api.cycleAnalyticsRemoveStage(stageId, groupId)
@@ -541,7 +541,7 @@ describe('Api', () => {
         const params = {
           ...defaultParams,
         };
-        const expectedUrl = `${dummyUrlRoot}/-/analytics/cycle_analytics/stages/thursday/duration_chart`;
+        const expectedUrl = `${dummyUrlRoot}/-/analytics/value_stream_analytics/stages/thursday/duration_chart`;
         mock.onGet(expectedUrl).reply(200, response);
 
         Api.cycleAnalyticsDurationChart(stageId, params)

ee/spec/frontend/fixtures/analytics.rb

@@ -140,7 +140,7 @@ describe 'Analytics (JavaScript fixtures)', :sidekiq_inline do
     end
 
     default_stages.each do |endpoint|
-      it "cycle_analytics/events/#{endpoint}.json" do
+      it "value_stream_analytics/events/#{endpoint}.json" do
         get endpoint, params: { group_id: group, format: :json }
 
         expect(response).to be_successful
@@ -160,7 +160,7 @@ describe 'Analytics (JavaScript fixtures)', :sidekiq_inline do
       sign_in(user)
     end
 
-    it 'cycle_analytics/mock_data.json' do
+    it 'value_stream_analytics/mock_data.json' do
       get(:show, params: {
         group_id: group.name,
         cycle_analytics: { start_date: 30 }
@@ -194,21 +194,21 @@ describe 'Analytics (JavaScript fixtures)', :sidekiq_inline do
       sign_in(user)
     end
 
-    it 'analytics/cycle_analytics/stages.json' do
+    it 'analytics/value_stream_analytics/stages.json' do
       get(:index, params: { group_id: group.name }, format: :json)
 
       expect(response).to be_successful
     end
 
     Gitlab::Analytics::CycleAnalytics::DefaultStages.all.each do |stage|
-      it "analytics/cycle_analytics/stages/#{stage[:name]}/records.json" do
+      it "analytics/value_stream_analytics/stages/#{stage[:name]}/records.json" do
         stage_id = group.cycle_analytics_stages.find_by(name: stage[:name]).id
         get(:records, params: params.merge({ id: stage_id }), format: :json)
 
         expect(response).to be_successful
       end
 
-      it "analytics/cycle_analytics/stages/#{stage[:name]}/median.json" do
+      it "analytics/value_stream_analytics/stages/#{stage[:name]}/median.json" do
         stage_id = group.cycle_analytics_stages.find_by(name: stage[:name]).id
         get(:median, params: params.merge({ id: stage_id }), format: :json)
 
@@ -216,13 +216,13 @@ describe 'Analytics (JavaScript fixtures)', :sidekiq_inline do
       end
     end
 
-    it "analytics/cycle_analytics/stages/label-based-stage/records.json" do
+    it "analytics/value_stream_analytics/stages/label-based-stage/records.json" do
       get(:records, params: params.merge({ id: label_based_stage.id }), format: :json)
 
       expect(response).to be_successful
     end
 
-    it "analytics/cycle_analytics/stages/label-based-stage/median.json" do
+    it "analytics/value_stream_analytics/stages/label-based-stage/median.json" do
       get(:median, params: params.merge({ id: label_based_stage.id }), format: :json)
 
       expect(response).to be_successful
@@ -243,7 +243,7 @@ describe 'Analytics (JavaScript fixtures)', :sidekiq_inline do
       sign_in(user)
     end
 
-    it 'analytics/cycle_analytics/summary.json' do
+    it 'analytics/value_stream_analytics/summary.json' do
       get(:show, params: params, format: :json)
 
       expect(response).to be_successful

ee/spec/requests/groups/cycle_analytics_events_spec.rb

 # frozen_string_literal: true
 require 'spec_helper'
 
-describe 'cycle analytics events' do
+describe 'value stream analytics events' do
   let(:user) { create(:user) }
   let(:group) { create(:group)}
   let(:project) { create(:project, :repository, namespace: group, public_builds: false) }
   let(:issue) { create(:issue, project: project, created_at: 2.days.ago) }
 
-  describe 'GET /:namespace/-/cycle_analytics/events/:stage' do
+  describe 'GET /:namespace/-/value_stream_analytics/events/:stage' do
     before do
       stub_licensed_features(cycle_analytics_for_groups: true)
       group.add_developer(user)

ee/spec/routing/analytics_routing_spec.rb

@@ -31,7 +31,7 @@ describe 'Analytics' do
       it 'succeeds' do
         expect(Gitlab::Analytics).to receive(:cycle_analytics_enabled?).and_call_original
 
-        expect(get('/-/analytics/cycle_analytics')).to route_to('analytics/cycle_analytics#show')
+        expect(get('/-/analytics/value_stream_analytics')).to route_to('analytics/cycle_analytics#show')
       end
     end
 

ee/spec/views/layouts/nav/sidebar/_analytics.html.haml_spec.rb

@@ -33,12 +33,12 @@ describe 'layouts/nav/sidebar/_analytics' do
         expect(rendered).to match(/<use xlink:href=".+?icons-.+?#comment">/)
       end
 
-      it 'has `Cycle Analytics` link' do
+      it 'has `Value Stream Analytics` link' do
         stub_feature_flags(Gitlab::Analytics::CYCLE_ANALYTICS_FEATURE_FLAG => true)
 
         render
 
-        expect(rendered).to have_content('Cycle Analytics')
+        expect(rendered).to have_content('Value Stream Analytics')
         expect(rendered).to include(analytics_cycle_analytics_path)
         expect(rendered).to match(/<use xlink:href=".+?icons-.+?#repeat">/)
       end
@@ -84,7 +84,7 @@ describe 'layouts/nav/sidebar/_analytics' do
         disable_all_analytics_feature_flags
 
         expect(rendered).not_to have_content('Productivity Analytics')
-        expect(rendered).not_to have_content('Cycle Analytics')
+        expect(rendered).not_to have_content('Value Stream Analytics')
       end
 
       context 'and user has access to instance statistics features' do

lib/gitlab/analytics/cycle_analytics/default_stages.rb

 # frozen_string_literal: true
 
-# This module represents the default Cycle Analytics stages that are currently provided by CE
+# This module represents the default Value Stream Analytics stages that are currently provided by CE
 # Each method returns a hash that can be used to build a new stage object.
 #
 # Example:

lib/gitlab/cycle_analytics/base_stage.rb

@@ -50,7 +50,7 @@ module Gitlab
         # Build a `SELECT` query. We find the first of the `end_time_attrs` that isn't `NULL` (call this end_time).
         # Next, we find the first of the start_time_attrs that isn't `NULL` (call this start_time).
         # We compute the (end_time - start_time) interval, and give it an alias based on the current
-        # cycle analytics stage.
+        # value stream analytics stage.
 
         median_datetime(cte_table, interval_query(project_ids), name)
       end

locale/gitlab.pot

@@ -5802,15 +5802,6 @@ msgstr ""
 msgid "Customize your pipeline configuration."
 msgstr ""
 
-msgid "Cycle Analytics"
-msgstr ""
-
-msgid "Cycle Analytics can help you determine your team’s velocity"
-msgstr ""
-
-msgid "Cycle Analytics gives an overview of how much time it takes to go from idea to production in your project."
-msgstr ""
-
 msgid "CycleAnalyticsEvent|Issue closed"
 msgstr ""
 
@@ -6714,15 +6705,15 @@ msgstr ""
 msgid "Dismiss"
 msgstr ""
 
-msgid "Dismiss Cycle Analytics introduction box"
-msgstr ""
-
 msgid "Dismiss DevOps Score introduction"
 msgstr ""
 
 msgid "Dismiss Merge Request promotion"
 msgstr ""
 
+msgid "Dismiss Value Stream Analytics introduction box"
+msgstr ""
+
 msgid "Dismiss trial promotion"
 msgstr ""
 
@@ -10459,7 +10450,7 @@ msgstr ""
 msgid "Interval Pattern"
 msgstr ""
 
-msgid "Introducing Cycle Analytics"
+msgid "Introducing Value Stream Analytics"
 msgstr ""
 
 msgid "Introducing Your DevOps Score"
@@ -13042,7 +13033,7 @@ msgstr ""
 msgid "One or more of your personal access tokens will expire in %{days_to_expire} days or less."
 msgstr ""
 
-msgid "Only 'Reporter' roles and above on tiers Premium / Silver and above can see Cycle Analytics."
+msgid "Only 'Reporter' roles and above on tiers Premium / Silver and above can see Value Stream Analytics."
 msgstr ""
 
 msgid "Only Project Members"
@@ -19182,9 +19173,6 @@ msgstr ""
 msgid "There was an error fetching configuration for charts"
 msgstr ""
 
-msgid "There was an error fetching cycle analytics stages."
-msgstr ""
-
 msgid "There was an error fetching data for the selected stage"
 msgstr ""
 
@@ -19200,6 +19188,9 @@ msgstr ""
 msgid "There was an error fetching the Designs"
 msgstr ""
 
+msgid "There was an error fetching value stream analytics stages."
+msgstr ""
+
 msgid "There was an error gathering the chart data"
 msgstr ""
 
@@ -19242,16 +19233,16 @@ msgstr ""
 msgid "There was an error when unsubscribing from this label."
 msgstr ""
 
-msgid "There was an error while fetching cycle analytics data."
+msgid "There was an error while fetching value stream analytics data."
 msgstr ""
 
-msgid "There was an error while fetching cycle analytics duration data."
+msgid "There was an error while fetching value stream analytics duration data."
 msgstr ""
 
-msgid "There was an error while fetching cycle analytics duration median data."
+msgid "There was an error while fetching value stream analytics duration median data."
 msgstr ""
 
-msgid "There was an error while fetching cycle analytics summary data."
+msgid "There was an error while fetching value stream analytics summary data."
 msgstr ""
 
 msgid "There was an error with the reCAPTCHA. Please solve the reCAPTCHA again."
@@ -21100,6 +21091,15 @@ msgstr ""
 msgid "Value"
 msgstr ""
 
+msgid "Value Stream Analytics"
+msgstr ""
+
+msgid "Value Stream Analytics can help you determine your team’s velocity"
+msgstr ""
+
+msgid "Value Stream Analytics gives an overview of how much time it takes to go from idea to production in your project."
+msgstr ""
+
 msgid "Variables"
 msgstr ""
 
@@ -21893,10 +21893,10 @@ msgstr ""
 msgid "You don't have sufficient permission to perform this action."
 msgstr ""
 
-msgid "You don’t have access to Cycle Analytics for this group"
+msgid "You don’t have access to Productivity Analytics in this group"
 msgstr ""
 
-msgid "You don’t have access to Productivity Analytics in this group"
+msgid "You don’t have access to Value Stream Analytics for this group"
 msgstr ""
 
 msgid "You have been granted %{access_level} access to the %{source_link} %{source_type}."

spec/features/cycle_analytics_spec.rb

@@ -2,7 +2,7 @@
 
 require 'spec_helper'
 
-describe 'Cycle Analytics', :js do
+describe 'Value Stream Analytics', :js do
   let(:user) { create(:user) }
   let(:guest) { create(:user) }
   let(:project) { create(:project, :repository) }
@@ -23,7 +23,7 @@ describe 'Cycle Analytics', :js do
       end
 
       it 'shows introductory message' do
-        expect(page).to have_content('Introducing Cycle Analytics')
+        expect(page).to have_content('Introducing Value Stream Analytics')
       end
 
       it 'shows pipeline summary' do
@@ -38,7 +38,7 @@ describe 'Cycle Analytics', :js do
       end
     end
 
-    context "when there's cycle analytics data" do
+    context "when there's value stream analytics data" do
       before do
         allow_next_instance_of(Gitlab::ReferenceExtractor) do |instance|
           allow(instance).to receive(:issues).and_return([issue])

spec/features/projects/navbar_spec.rb

@@ -67,8 +67,8 @@ describe 'Project navbar' do
           nav_sub_items: [
             _('CI / CD Analytics'),
             (_('Code Review') if Gitlab.ee?),
-            _('Cycle Analytics'),
-            _('Repository Analytics')
+            _('Repository Analytics'),
+            _('Value Stream Analytics')
           ]
         },
         {

spec/fixtures/valid.po

@@ -267,11 +267,11 @@ msgstr "Eventos de notificaciones personalizadas"
 msgid "Custom notification levels are the same as participating levels. With custom notification levels you will also receive notifications for select events. To find out more, check out %{notification_link}."
 msgstr "Los niveles de notificación personalizados son los mismos que los niveles participantes. Con los niveles de notificación personalizados, también recibirá notificaciones para eventos seleccionados. Para obtener más información, consulte %{notification_link}."
 
-msgid "Cycle Analytics"
-msgstr "Cycle Analytics"
+msgid "Value Stream Analytics"
+msgstr "Value Stream Analytics"
 
-msgid "Cycle Analytics gives an overview of how much time it takes to go from idea to production in your project."
-msgstr "Cycle Analytics ofrece una visión general de cuánto tiempo tarda en pasar de idea a producción en su proyecto."
+msgid "Value Stream Analytics gives an overview of how much time it takes to go from idea to production in your project."
+msgstr "Value Stream Analytics ofrece una visión general de cuánto tiempo tarda en pasar de idea a producción en su proyecto."
 
 msgid "CycleAnalyticsStage|Code"
 msgstr "Código"
@@ -412,8 +412,8 @@ msgstr "Importar repositorio"
 msgid "Interval Pattern"
 msgstr "Patrón de intervalo"
 
-msgid "Introducing Cycle Analytics"
-msgstr "Introducción a Cycle Analytics"
+msgid "Introducing Value Stream Analytics"
+msgstr "Introducción a Value Stream Analytics"
 
 msgid "Jobs for last month"
 msgstr "Trabajos del mes pasado"

spec/javascripts/cycle_analytics/banner_spec.js

@@ -16,8 +16,10 @@ describe('Cycle analytics banner', () => {
     vm.$destroy();
   });
 
-  it('should render cycle analytics information', () => {
-    expect(vm.$el.querySelector('h4').textContent.trim()).toEqual('Introducing Cycle Analytics');
+  it('should render value stream analytics information', () => {
+    expect(vm.$el.querySelector('h4').textContent.trim()).toEqual(
+      'Introducing Value Stream Analytics',
+    );
 
     expect(
       vm.$el
@@ -25,7 +27,7 @@ describe('Cycle analytics banner', () => {
         .textContent.trim()
         .replace(/[\r\n]+/g, ' '),
     ).toContain(
-      'Cycle Analytics gives an overview of how much time it takes to go from idea to production in your project.',
+      'Value Stream Analytics gives an overview of how much time it takes to go from idea to production in your project.',
     );
 
     expect(vm.$el.querySelector('a').textContent.trim()).toEqual('Read more');

spec/requests/projects/cycle_analytics_events_spec.rb

@@ -2,12 +2,12 @@
 
 require 'spec_helper'
 
-describe 'cycle analytics events' do
+describe 'value stream analytics events' do
   let(:user) { create(:user) }
   let(:project) { create(:project, :repository, public_builds: false) }
   let(:issue) { create(:issue, project: project, created_at: 2.days.ago) }
 
-  describe 'GET /:namespace/:project/cycle_analytics/events/issues' do
+  describe 'GET /:namespace/:project/value_stream_analytics/events/issues' do
     before do
       project.add_developer(user)
 

spec/views/layouts/nav/sidebar/_project.html.haml_spec.rb

@@ -160,4 +160,31 @@ describe 'layouts/nav/sidebar/_project' do
       end
     end
   end
+
+  describe 'value stream analytics entry' do
+    let(:read_cycle_analytics) { true }
+
+    before do
+      allow(view).to receive(:can?).with(nil, :read_cycle_analytics, project).and_return(read_cycle_analytics)
+      stub_feature_flags(analytics_pages_under_project_analytics_sidebar: { enabled: false, thing: project })
+    end
+
+    describe 'when value stream analytics is enabled' do
+      it 'shows the value stream analytics entry' do
+        render
+
+        expect(rendered).to have_link('Value Stream Analytics', href: project_cycle_analytics_path(project))
+      end
+    end
+
+    describe 'when value stream analytics is disabled' do
+      let(:read_cycle_analytics) { false }
+
+      it 'does not show the value stream analytics entry' do
+        render
+
+        expect(rendered).not_to have_link('Value Stream Analytics', href: project_cycle_analytics_path(project))
+      end
+    end
+  end
 end