Calculating stage times and statistics in value stream management
- In the current design of value stream management of GitLab, a stage is represented by a label. So any label represents any stage in theory, but in practice, a label would represent a stage when it is visualized in a board for value stream management purposes (i.e. https://gitlab.com/gitlab-org/gitlab-ee/issues/6323).
- In particular, this means that for stage time calculation purposes, you don't need the notion of a board. You just need labels and timestamps. So we have the following assumptions.
- Consider any object (for the short to medium term, it will be issues and merge requests).
- Consider any label. Consider all the times in history that that specific label is added to and removed from the object.
- Let all the times that the label was added be
a1 < a2 < ...
. - Let all the times that the label removed be
r1 < r2 < ...
. - By definition of how labels work, we are guaranteed that
a1 < r1 < a2 < r2 < a3 < r3 < a4 < ...
Simplifying assumptions
- Objects could be in multiple stages at the same time. But you assume the user would not allow that.
- Explain how it would throw numbers off.
- Given the board lists (stages) that the user sets up, you assume that objects appear only in those stages, and not in other stages.
- Explain how it would throw numbers off.
- Calculating entire end to end directly versus summing up the individual stages.
- Summing up the individual stages is more straightforward. No weirdness/inconsistencies.
- But this simplifying assumption means you can only capture averages, which is likely okay!
Edited by Victor Wu