Provide alternative constructs and progress reporting other than milestones for organizing a team's workflow
Problem to solve
Situation: When breaking down a release into multiple iterations/sprints...
Motivation: I want to track progress of the iteration/sprint outside of the broader release/milestone burndown...
Force: It's annoying that I have to go from my issue board to Milestones > Select Milestone > wait 10s for the page to load before looking at relevant progress data.
Force: I'm anxious because I feel like I'm flying blind in terms of where the team is at and where I should direct my focus to help maximize value of what we're working on.
Expected Outcome: So I can understand if we are on track, further investigate what is taking us longer than we expected, and adapt the plan / adjust the scope as necessary to deliver the maximum customer value for the iteration/sprint.
Intended users
Engineers, Designers, Product Managers
Further details
Our Customer's Real Use Cases
We’ve been told to use gitlab’s milestones to capture agile sprints, as they’re the only thing that can have burn down, they work well with boards and have concepts of time. The default way epics get their start/end dates is based on the milestones of the issues attached though – doesn’t make sense as an issue shouldn’t be assigned to an agile sprint until the sprint is eminent. (root of problem is that gitlab milestone must either be equated to agile milestone or agile sprint, not both – you’re missing a concept)
Proposal
- TBD
Permissions and Security
- TBD
Documentation
- TBD
Testing
- TBD
What does success look like, and how can we measure that?
- TBD
What is the type of buyer?
- TBD