(This epic was promoted from #12260) ### Problem to solve In order to become efficient, we need to understand what type of work our team does, how much of it and how quickly it goes through. PMs have a difficult time to optimize between features, bugs, technical debt and security issues and usually there is no easy way to communicate trade-offs to management. Moreover, they don't know how much of that work is stuck in each stage (definition, in review, etc.) ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> PMs, EMs, Executives ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Add a cumulative flow chart in cycle analytics, which shows the flow of features, bugs, technical debt and security issues. On the right, we should be able to select the stage similar to https://gitlab.com/gitlab-org/gitlab-ee/uploads/a1261f48618f296ff8f4d7c15b6df988/days-to-completion--slect-stage-multi.png. On the x-axis we will have dates and on the y-axis the number of tasks in the specific stage on that day (so a stage should refer to only an issue or MR or a job). Let's use an area chart as per @cperessini in https://gitlab.com/gitlab-org/gitlab-ee/issues/12078. As an example, let's say I have selected P1 label for all issues and MRs in the global filters on cycle analytics, so I will be able to see the cycle time on all P1 issues/MRs. @matejlatin, I would also like to convey in some way what % is quality vs security vs bugs vs feature work. So I am not sure if this proposal works as we basically have multiple dimensions. ### 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)? --> ### 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. --> ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references ### Solution * We add two charts to the bottom of the page and a title 'Type of work' above them. * the Tasks by stage chart has a filter to choose which stages are shown, the default is 'All stages'. The 'All stages' option is visually separated from others by a divider. * Let's make sure we have an ARIA label saying 'Showing' to provide the context of the two dropdowns. * We show popovers on hover (on tap on mobile) | Type of work | with popovers | with filter dropdowns | mobile | |--------------|---------------|-----------------------|--------| |  |  |  |  | #### Tasks by type For the tasks by type chart we allow the users to select the tasks type by selecting which labels they want shown in the chart and also if they want to see issues or MRs.  Changing to 'Merge requests' in the dropdown will also change the description under the title. So from `Showing issues and 4 labels` it would change to `Showing merge requests and 7 labels` for example.