**Updated Description** ### Problem to solve PMs / Scrum Masters usually work across multiple teams and currently they cannot see cycle time or cross team dependencies on a group level. This makes it very difficult for them to manage the delivery of multiple teams and understand where the bottlenecks are. Engineering Executives would like to understand how fast their organization is moving and compare between projects / groups in order to identify patterns leading to loss of efficiency. ### Intended users Scrum Master, Product Manager, Executive ### Solution We will add two charts below the Cycle Analytics table: **NB. We will be adding only the scatterplot in this iteration**  #### Days to completion  This chart will be a scatterplot: - The X-axis represents dates. Label: `Completion date` - They Y-axis represents time to completion, expressed in days. Label: `Days to completion` - Each of the dots will represent the total cycle time on the corresponding day. Essentially, the added value of all stages in Cycle Analytics for that date. - The trendline will represent the median for the past 30 days on each day. It will be accompanied by +25-75% quantile bands. ##### Choosing stages On the top-right corner of the chart, there will be a dropdown for users to select which stages they would like to be represented in the chart. The dropdown is multi-select, which means that several stages can be chosen. The scatterplot will represent the addition of the values for each stage. There will be a special option at the top, `All stages`, which reverts the plot to default behavior. The selection should take effect when closing the dropdown. | All stages | Multi-select | | ---------- | ------------ | |  |  | ##### Popover  When hovering the chart, there will be a popover that will inform the user of the values of the two elements for that date. !!! **We will do a slightly different chart similar to the below in 12.2. Downsizing this ticket for 12.1** #### Moving median  !!! **We will do a slightly different chart similar to the below in 12.2. Downsizing this ticket for 12.1** The second chart will be an area chart that will represent the median time spent on each stage: - The X-axis represents dates. Label: `Date` - The Y-axis represents the median time spent on each stage. Label: `Median days in stage` - Each of the areas corresponds to one stage. The height of each area represents the time spent on that stage. The total height of the table represents total cycle time. This chart will have its separate dropdown for selecting stages. ##### Popover  When hovering over the chart, a vertical line will appear to help users see specific dates more easily. A popover will show up with detailed information for each stage. ##### Style | Stage | Line color | Area color | | ----- | ---------- | ---------- | | Issue | `$blue-500` | `$blue-500 20%` | | Plan | `$green-500` | `$green-500 20%` | | Code | `$orange-500` | `$orange-500 20%` | | Test | `$indigo-500` | `$indigo-500 20%` | | Review | `$red-500` | `$red-500 20%` | | Staging | `$grey-500` | `$grey-500 20%` | | Production | `$teal` (from labels) | `$teal 20%` (from labels) | #### Empty state When the user first enters the page, we will show an empty state. The user will need to select a group in order to start seeing analytics. The copy will be: Title: `Cycle Analytics can help you determine your team’s velocity` Body: `Start by choosing a group to see how your team is spending time. You can then drill down to the project level.`  ### Original proposal A scrum master would like to be able to consolidate multiple groups or projects in one dashboard, but having a view of all projects in a group is a good start. 1. Given we will only have group level analytics as an MVC for instance, a user should be able to filter by group, project, subgroup or specific calendar dates using a date picker (http://www.daterangepicker.com). (filtering by author, assignee, milestone, labels will be kept for another iteration) (http://www.daterangepicker.com). 2. Let's have a scatterplot with the specific day of completion on the x-axis and number of days it took from `X` to `Y` as our first attempt to answer the question as to whether people are getting better with time. The chart should contain a trend line (rolling median - 30 days?)+ 25-75% quantile bands. We should have a dropdown where a user can select which stage they want to look at and they should be able to select more than one, so that the trend line will be the sum of days for those stages selected. We can have different color dots representing the different stages. If this looks too messy, we can combine the stages in 1 dot. 3. Let's have an area chart, similar to a cumulative flow graph, where we chart the rolling median for each stage over time. The idea would be that when we can customize the stages, we can potentially represent as [cumulative flow digram](https://www.youtube.com/watch?v=eo2uv8avEsU). If a person selects a period less than 30 days, we show no data in the charts? @cperessini, what would be a better UX? This is something we should think about as if people use scrum they would most likely filter by milestone but if they use kanban, they are most likely to use the date picker. I would suggest for the 2 charts to go in 1 line under the table we have right now. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> The dashboard should inherit the project/ groups permissions of users, i.e. I can only see an aggregation of subgroups, projects I have access to. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> Measure: We should include the page in user ping to start with and measure how many people visit and how long they stay on it. Success: As we develop this further, we expect users to spend a significant time deep diving on the page at least once a week. ### Links https://docs.gitlab.com/ee/user/project/cycle_analytics.html <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->