Design for burndown chart in issue boards
Problems
- We need a way for teams to work together within a single iteration/sprint/milestone.
- Currently, teams (consisting of multiple people) can use labels, milestones, issues, assignees to organize work. But there's no one easy place to manage all that work and view status.
- So far, we can use group boards and board config to solve some of those problems. But if you want to track progress within an iteration (during an iteration), there is no way to do that.
- Some teams have resorted to using external tools.
- One approach is to iterate on the milestone view in GitLab. In both project milestone and group milestone views, you have a burndown chart and some ancillary data in the sidebar. But iterating on those pages is not a good design, since you are now elevating the milestone page to a first-class citizen for team collaboration. A milestone is just one attribute in GitLab. There are labels and assignees and others. We should have a separate place to aggregate information for teams.
Problems for GitLabbers
- No easy way for teams (UX, FE, BE teams) to see what it is going on together.
- No way to status, (e.g. burndowns) of work you care about.
- No way to see statistics, capacity, how your performance is over time.
Proposed solution
- Iterate on boards as the one location for teams.
- A team should always go to one board or one set of boards for everything they need from a team perspective.
- A board already has a board config. This provides flexibility to define the team itself (using labels, etc.). So we should leverage the board config as the definition/configuration of the "team".
- In this first iteration (https://gitlab.com/gitlab-org/gitlab-ee/issues/6056#note_74196155), we incorporate the burndown chart into the board itself:
- Applicable to group boards and project boards
- When you view a board, you can toggle between board mode and burndown mode.
- When you are in burndown mode, you view a burndown chart, that is already scoped to the board config. That is, the issues that are in scope for that board, are used to generate a burndown chart dynamically.
- You can further use the filter bar. When you filter in the filter bar, it re-draws the burndown chart accordingly to further scoping it down to fewer issues.
- If the board config is not scoped to a milestone with start and end dates, show a graphic/message to ask the user to do so. Illustration: gitlab-svgs!114 (merged)
Board toggle visible in top right corner | Burndown view active | Burndown empty state |
---|---|---|
![]() |
![]() |
![]() |
Design requirements
- For what is to be delivered as part of ~"design artifact" here, consider the problem above.
- Provide a solution (consider the proposed solution).
- Provide a few iterations worth of designs, and scope out the smallest first iteration to be implemented.
Edited by Pedro Moreira da Silva