Add burnup chart to milestones
Problem to solve
- When a milestone ends, issues are typically moved to the next milestone. Burndown charts on the previous milestone then don't accurately reflect what was completed on that given milestone. We add a
missed xx.xxlabel to all issues as a current workaround.
- If issues are added to a milestone once it begins, that represents "scope creep" and there is no way to surface this on a milestone level.
- By not storing the amount of missed issues in a given milestone, teams don't have effective feedback to help them set better expectations for the next milestone.
- Parker (Product Manager)
- Delaney (Development Team Lead)
- Scrum masters, Agile coaches, Managers, Directors, Executives
- Sasha (Software Developer)
- Presley (Product Designer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
- Dana (Data Analyst)
- This is one of the important steps towards our goal of providing better first class support for modern "agile" methodologies.
- Not having this is currently a deal breaker for a lot of customers switching their project management functionality over to GitLab as there is currently no way to easily to see the difference between original commitment and the actual outcome of a milestone.
- Include a second chart on the milestone view for
burnup, which tracks two lines throughout a milestone -
completed. The scope line is variable depending on the amount of scope added or removed to a milestone once it begins.
- Completed tracks the number of issues
closedduring the given milestone.
- Include the total count of issues (and weight) added/removed from a given milestone.
- The scope line is time series like data where it is simply the count of issues in a milestone at a given point in time. Count should be immutable once it is recorded.
Follow on iterations:
- See the epic: &1957
- This is also happening (#19445 (closed)) so the designs should be based on the current Project Milestone view (Example: %10.0). Once we have this issue and that issue completed, we will revisit the content and overall design of the milestone view.
- In the coming releases, we will also be working towards segmenting data on milestones by teams/groups so that each team has meaningful insights into their contribution towards a company level milestone. This will include calculating additional derived data such as velocity and volatility as well as providing burndown/burnup charts scoped to teams and/or issue boards.
Permissions and Security
- This presents no suggested deviations from our current security and permissions model.
- We will want to add documentation around the additional data points now available on Milestones.
- We should write acceptance and unit tests for this.
What does success look like, and how can we measure that?
- Milestones and the burndown chart load in two seconds or less.
- We make significant progress converting some customers over to using GitLab's Issue Tracking capabilities.
- The behavior in the proposal is working.
- Necessary tests added.
- Uses GraphQL first.
- Necessary updates to public GraphQL and REST APIs.
- Documentation added.
- Pajamas first. If major changes are required for the graph, consider contributing to the unified dashboard project.
- Milestones load faster than did before making this change.
What is the type of buyer?
- The problems this issue would solve and the corresponding additional data added to a milestone is not something an individual contributor would necessarily care about. According to our pricing strategy the likely buyer is Manager and above, so this would fall within the GitLab Starter tier.
Links / references
- Directly related open issues are linked below the description.
Pre-Build Task List
- UX / workflowsolution validation completed
- backend implementation spiked and documented (please consider using a checklist in the description and/or adding a description of the suggested implementation approach)
- needs weight resolved
- Prioritize and schedule
- Display a report of total counts of each event over the duration of the milestone period. (i.e.
- It might also be nice to consider displaying a list of the issue corresponding to each event, but this could also get noisy.
- Burndown charts as currently implemented, are largely stateless.
- We will introduce a little more state to account for issues added to a milestone in the middle of a milestone. See https://gitlab.com/gitlab-org/gitlab-ee/issues/6174.
- But even with that change, burndown charts are mainly stateless. In particular, when you remove an issue from a particular milestone, the burndown chart treats that issue as if it was never part of it.
- We plan to introduce burndown charts into boards. This will allow the scoping of issues to be flexible/customizable based on the board scope/configuration. So instead of bringing scoping to the milestone page (where the burndown chart currently exists), the idea is to bring the burndown chart to the board, which already has a scoping.
- Burndown charts currently do not capture state. In particular:
- If in the past, an issue was part of a milestone, but then subsequently removed that milestone, our current implementation doesn't account for it.
- If in the past, an issue had a certain label, but then subsequently that label was removed, even our burndown chart in board feature (https://gitlab.com/gitlab-org/gitlab-ee/issues/6864), will not account for it.
- This problem above is not a major problem currently. We have not received any requests (per my knowledge) to have those more accurate burndowns. My suspicion is that teams typically use burndowns during a milestone as the issue counts/weights are burning down. After the iteration is over, they do not care and even if the issue is moved to another milestone, that is okay.
- However, what is a real problem for GitLabbers right now, is the ability to track missed deliverable rates. We have some ongoing work to do this outside of the product. See https://gitlab.com/gitlab-org/gitlab-ce/issues/49201. But eventually we want to solve this inside GitLab. If the burndown chart can account for historical state, then perhaps it can be used to address that particular problem.
- Long-term (we might never need the long-term solution), we entirely use events (&224 (closed), &48) to build historically accurate burndown charts.
- In particular, this will solve tracking missed deliverables for GitLabbers. You would look at a burndown chart, and be able to see (given a particular scoping of labels and other attributes), how many issues that were open at the beginning of the milestone, and how many were closed at the end of the milestone. So you can capture the missed deliverable rates immediately from there.
- In the first iteration, we only use milestone events for historically accurate milestones. This will probably be enough for GitLabbers to track missed deliverables rate, since our team/product area labels are unlikely to change significantly for issues.
- In the second iteration (which we might not need), we consider label events, and make that accurate.
- In iterations after that (again, which we might not need), we consider weight events, assignee events, etc.
We are moving forward for now with adding a BurnUp chart to the Milestone view. Users will be able to filter by issues and weights on the two charts at once but they will be viewed side by side as separate metrics. Ideally, they should be side by side in a horizontal row until they reach a min size of 500px. At that point they should stack vertically.