Instance Level Analytics (with group level data)
Problem to solve
During customer conversations we have found that engineering and product teams can span multiple groups and projects. At the moment, most of our analytics are on a project level, which makes it very difficult for an EM / PM / Executive to get a sense of where the majority of effort is spent and understand cycle times and bottlenecks across teams (we have received similar feedback from @dhavens). Moreover, our analytics are dispersed across the tool and are not particularly easy to find. We have:
Most of these analytics do not contribute to any actionable insights since they are at MVC stage and difficult to connect.
For example, executives would like to be able to have a single view of languages used across the instance (ex: https://gitlab.com/gitlab-org/gitlab-ce/issues/62294), compare productivity and velocity across teams, groups, projects, etc. Currently, managers at different levels of the organization are looking at different information, which is often inconsistently defined between teams and difficult to aggregate.
Development Team Lead, Product Manager, Executive
Implementing analytics at an instance level will allow us to move forward with our vision for VSM and have one place for dashboards, which can be used by developers, managers and executives. Many customers have expressed interest in instance level analytics with customizable dashboards allowing users to drill-down in order to uncover actionable insights. (https://gitlab.com/gitlab-org/gitlab-ce/issues/48807)
We add a new
Analytics link to the top bar after
Snippets and before the separator.
When the user clicks on the Analytics link, they're taken to the Analytics dashboard. The sidebar contains the header (
Analytics), and a single navigation item (
The page presents an empty state for Cycle Analytics. The page contains:
- Search bar with a
Choose a groupprimary button (small size). There is a timeframe dropdown next to the search bar.
Recent activitypanel with the empty state message:
Select a group above to get started
- Cycle Analytics panel, where the times have been replaced by
Choosing a group
When the user clicks the primary button, it is replaced by a
Group token, and the group-selection dropdown opens up. This works the same way as the filters in Issues and Merge Requests. The user will need to click the magnifying glass button or press Enter in order for the search to take effect.
Once the user submits their search, the Group token is completed and the Cycle Analytics information populates.
We will use the following icons:
icn/logfor the sidebar header,
Given the size of instances like GitLab.com, our MVC here will be starting analytics on a group level.
A logged-in PM/EM, who is currently on an instance page, should have an easy navigation to an analytics page. @cperessini, after discussing with Eric and Jeremy, I think it's better to have it as
Analyticson the top nav bar, just before the Ops Dashboard icon. We can work on combining with the admin dashboard at a later date. We can actually remove Snippets as no-one uses it and I am not aware of any marketing effort to make it an app important feature deserving space on the nav bar?
Given we are putting
Analyticson the Nav Bar (in order not to confuse use with discoverability given the feature will move to instance level), let's have an easy way for a user to select a group he is interested in. We can potentially use our existing dropdown for Groups or the selection of projects feature on the Ops Dashboard for that? (cc: @cperessini, what do you think?)
Once the user clicks on 'Analytics', a page similar to the below would open and on the left we can have:
Cycle Analytics. Each page will have different charts that a user can save in the future as his private view (ex: https://gitlab.com/gitlab-org/gitlab-ee/issues/6019, https://gitlab.com/gitlab-org/gitlab-ce/issues/58435)
- On the top of each page, we should have a 'global' dashboard filter by group (in the future, for the MVC not), project, milestone, author, assignee (as per your proposal here: https://gitlab.com/gitlab-org/gitlab-ce/issues/48807). I would suggest to have the data range filter separate on the top right like in your proposal but make it an actual calendar range, where people can select the timeframe with a date picker like this one (http://www.daterangepicker.com). The reason for that is that many companies want to look at longer timeframes as they don't release more often than once a month.
https://gitlab.com/gitlab-org/gitlab-ce/issues/29359 https://gitlab.com/gitlab-org/gitlab-ce/issues/28123Old issues
Permissions and Security
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.
What does success look like, and how can we measure that?
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.