Value stream analytics in board
- Time analytics is done on it's own dedicated UI in GitLab.
- Here, we first focus on issues.
- Issues can represent every stage in the entire lifecycle. Even as code is being created, reviewed, deployed, and monitored, the corresponding issue can go through those stages. So you have end-to-end analytics.
- You define the workflow stages you care about with labels.
- So in the mockup below, there is a dedicated UI tab in the issues list page. It is called the Time analytics tab.
- When you click on that tab, it retains the current filter search. In the mockup below, you care about all the issues that are Discussion backend issues.
- Of these issues, you want to know the statistics of when those issues spent time in the
Ready for devstage, the
In devstage, etc. Each of these stages is a label.
- On this page, currently, the user has selected four stages.
- The bar charts show the average of all of these scoped (Discussion backend) issues that "participated" in the given stage:
- For example, if one of these issues had the
Ready for devapplied, and then subsequently removed, that counts as one data point, and you calculate the statistic (the average in this case) for it.
- The population averages are per month. But in the design below you can also choose per week.
- For example, if one of these issues had the
- Additionally, we have a special design if you only choose to view the statistics (averages) for a single stage. We additionally plot all the data points in that month (or week), for issues that participated in that stage.
- This visualization thus provides the additional information/insight of seeing relative variance (and general distribution) of the data. So even if the average is okay, you can see worst case and best case.
- And a key use case is that you can see the worst offenders at a glance. The dots with the higher times are the worst offenders.
- And then you mouse-over the worst offenders and GitLab will show you which issue is that worst offender. So you can then immediately click through to look at the issue and investigate why particular issues were so terrible.
- In another following visualization, as a user, you have controls to specify whether one stage is useful work versus waste work. So you would set up your workflow stages accordingly. And then when you visualize them, you would be able to immediately see when during value flow stream, there is waste "leaking".
- In yet another visualization, the useful work versus waste time is collapsed together, so that you can immediately see the ratio as comparison.
Time analytics integrated in boards
- We want to make it super easy for teams to use time analytics.
- Teams are already using boards for workflows, with lists representing workflow stages.
- Also, in a board, the board configuration already represents the scope of issues you care about.
- So in a board, there is a
Time analyticsbutton. When you click it, GitLab takes you to the Time analytics UI, with the scope and stages already pre-populated. So right away, you get information you care about.
In particular, say you are the Discussion team and so your board is scoped with Discussion and 10.8 if your board is the workflow board for milestone 10.8. So you would click through to the Time analytics UI. And you would see the statistics of the issues you care about, but it would be narrowed down to 10.8 . And so if you wanted to know longer trends, you would simply eliminate 10.8 from the scope of that Time analytics UI.
Also pertinent is knowing the statistics of issues in the current board, which often times means the current milestone. So in this case, you would mouse-over a list and see instant statistics. But, these are with respect only to the issues on the board currently.
So this design is about the current iteration/sprint. It is a different use case, but related.
Time analytics integrated with deployments
- VSM also works integrated with deployments to environments.
- As an idea evolves from planning into code, and ultimately being delivered to customers, it is represented in GitLab by the issue, and in particular, the issue card in a board.
- In the latter stages, code can be shipped to different environments, and even within one environment it can be phased rollout, where it is controlled either manually, or automatically. See the example mockup.
- The issue moves across these latter stages of In UAT, In Beta, ... In Production 100%, and this movement across label lists in an issue board is automated.
- In particular, when you configure pipelines and environments with GitLab, you use
.gitlab-ci.ymland other configurations to define your flow. These configurations automatically create the corresponding labels in GitLab, so that they can be used to track stages.
- Within the GitLab CI UI, there is a feature to automatically create an issue board or append columns to an issue to indicate these labels.
- An issue can be related to a merge request. When the merge request's code moves throughout these deployment environments, the corresponding labels are added to or removed from the associated issue linked to the merge request.
- Additionally, if given issue has multiple linked merge requests, all those merge requests need to reach a certain CI stage before the associated one issue advances in the board.
- Currently, an issue can be related to many merge requests, and the coupling is not very tight. We need to build a feature to refine this further. In particular, you should be able to de-link a merge request form an issue.
- All charts and visualizations and calculating times based on issue labels remains here.
Related merge requests in boards
- Board will continue be focused on issues. That is, the first class object will continue to be boards.
- But with the deployments-related VSM use cases. we want to easily see related merge requests in boards An example from gitlab-ce#25669 is the following: