## Context Popular agile methodologies such as Scrum and ExtremeProgramming (XP) use a time-boxed model for planning and releasing software. Most teams work within two distinct timeboxes at any given time: - Sprints (Scrum), Iterations (XP) are shorter timeboxes ranging from 1 week to 1 month. - Releases (Scrum and XP) are longer timeboxes, typically 1 month to 1 quarter, that contain many smaller timeboxes. It gets even more complicated when enterprise agile frameworks such as [SAFe](https://www.scaledagileframework.com/#) and [LeSS](https://less.works/less/framework/index.html) are implemented. SAFe Chart: <details>  </details> ## Problem - Right now, there is no way to associate an issue to a shorter timebox that lives within a longer timebox. - There is no way to reliably understand capacity or velocity from one milestone to another that are of the same kind such as recurring 2 week iterations. - There is no way to report "progress" against more than one timebox. - A large amount of customers are handling their "project management" reporting outside of GitLab via spreadsheets, which are time consuming to maintain. * We do not surface velocity in a meaningful way * We do not provide any other constructs for when an issue is done other than closed. Many teams are "done" when they hand it off to a downstream process, thus making most of our reporting within milestones and epics meaningless. - We currently [calculate velocity manually](https://about.gitlab.com/handbook/product/categories/plan/#historical-capacity) as well and are [running into constraints](https://gitlab.com/gitlab-com/gl-infra/delivery/issues/610#note_269895240) using a single milestone. ## Potential Approaches - Allow milestones to have children milestones: This would solve for the majority of use cases but would not provide flexibility in those instances where the user wants to associate an issue to two milestones with separate parents. - Allow issues to belong to 2 or more timeboxes (milestones) simultaneously - A "sprint" timebox and a "milestone" timebox. - Extend the concept of a Project's Release to the group level so there can be a top level release shared across many projects. Add meaningful information to the group level release like burndown, etc. This would allow Milestones to serve as iteration/sprint timeboxes. The problem with this approach is that Release are tied to a git repo in that they represent a time-specific tag/snapshot within the repo and have little to do with project planning and management. ## Additional Outcomes From This Epic - Decrease friction for moving issues from one milestone to another; especially at the end of a given milestone. - Decrease friction around manually creating milestones that recur on a regular schedule. - Allow milestones to be related to one another so things like velocity and/or capacity can be tracked and reported in a meaningful way. ## Proposed Solution - [x] An issue can be assigned to multiple timeboxes. (https://gitlab.com/gitlab-org/gitlab/issues/5135) - ~~[ ] The top level group can define timebox types. (https://gitlab.com/gitlab-org/gitlab/issues/35290)~~ - [x] An issue can belong to only one of each kind of timebox. - [ ] We treat Timeboxes of the same type as related, allowing for the calculation of velocity over `n` of previous Timeboxes. - [ ] When closing a timebox, prompt to move to currently open issues and MRs to another timebox. - [ ] Timeboxes can be set on a recurring schedule based on their type. - [ ] Within recurring timeboxes, add option to automatically move issues and MRs to the next timebox once the current milestone expires. ### Follow-on Epics - [Scope change within a Milestone](https://gitlab.com/groups/gitlab-org/-/epics/1957) - [Team velocity and volatility](https://gitlab.com/groups/gitlab-org/-/epics/435) ## Customer Feedback > “Needs to be a way to have a team velocity, as a scrum master be able to go through and say “This feature requires ~100 points of work, we can do 25 points per sprint, will take 4 sprints (8 weeks) – you want it done in 6 weeks, will either require to be simplified or increased resourcing.” > “Need burn-down chart/progress status of sprints, features, initiatives, and milestones.” > “During sprint planning, need a way to see what my team’s velocity has been last several sprints to have a good idea of how much we should be planning for upcoming sprint.” > “Need an easy way to see how much I’m assigning to each team member during sprint planning (team members aren’t interchangeable – sprint can have user stories less than velocity, but if user stories are only doable by one team member then the work can’t get done).” > “During sprint, need tool to check in during daily stand ups, quickly see current state and progress.” “Need to be able to answer questions around “which teams/members are working on this feature?”, “are we still on track to meet this milestone?”, “we want to add this new feature, how will that slow down other development?”, “This team is needed for another project, how will that effect timelines on this project?”, etc…” > “Our team (Bronze Plan w/ 7 users) would very much like to see this implemented. We work with multiple clients that have specific milestones, but also have an overall team sprint that spans all group issues. Right now we're having to use Asana to manage the overall sprints which cause us to lose time with duplicate content entry." > “Our organization (250 employees) is currently deciding between Gitlab and JIRA Software and the inability to assign multiple milestones makes it impossible to use Milestones for sprint planning while still maintaining a clear overview of project status. Please consider implementing ASAP.” ## Competitors That Are Solving This Well - Pivotal Tracker only has a single "milestone" that is calls a release. Sprints are auto calculated and aren't considered a "milestone". This works REALLY well as it basically auto schedules releases based on a team's running velocity - https://www.pivotaltracker.com/help/articles/organizing_releases/. Additionally, there is a really nice suite of analytics and reports that are available. - JIRA has releases, milestones, and versions. ## Rice | Item | Value | Narrative | | ------ | ------ | ------ | | Reach | `10.0` | This is a really large blocker to adoption of GitLab's planning capabilities within larger organizations | | Impact | `3.0` | The above points and the entirety of this issue largely speak to this. A solution is also highly requested. | | Confidence | `100%` | This paint point is widely felt internally and externally. We've received support requests for this, and it is a widely adopted feature in some form or fashion in nearly every competing product. | | Effort | `?` | PM, FE, BE, Designer @ ? months = ? | | ------ | ------ | ------ | | Score | ? | | ## Links / References - [Opportunity Canvas](https://docs.google.com/document/d/18hUEH2hyQumu829ryomR4AaJd5LWXDPmfs3tbKRvS9U/edit) (Internal) ## Current milestone data According to the data shared in https://gitlab.com/gitlab-org/gitlab-ee/issues/6157#note_84167563 the majority of GitLab.com milestones are configured as: - 28% have **both start and due date**. - 24% have **only due date**. - 18% don't have any date set. Old Description: <details> Currently, a GitLab milestone is intended to be used as a sprint/iteration only, where that is a finite time period of work scoped for a team to work on. How can we expand the milestone to also represent and solve the use cases of a release? A release being a one-point-in-time representation of a release of code (from a technical sense) and features (from a business sense). According to the data shared in https://gitlab.com/gitlab-org/gitlab-ee/issues/6157#note_84167563 the majority of GitLab.com milestones are configured as: - 28% have **both start and due date**. - 24% have **only due date**. - 18% don't have any date set. The majority of milestones with dates have: **both start and due date** and **only due date**. This might have to do with the dual usage of milestones: as iterations/sprints and as releases, respectively. For iterations/sprints it makes sense to have both, but for releases, one might just care about the actual release date. ## Group milestone as a sprint/iteration - With the start date and due date of a sprint, these values timebox the sprint. - Issues and merge requests are put into the sprint through milestone assignment. - Boards integrated with milestones solve the tracked workflow use cases. - Burndown charts solve the within-a-sprint tracking/risk mitigation problem. - https://gitlab.com/groups/gitlab-org/-/epics/6 are remaining group milestone parity gaps to project milestones. - Capacity planning and tracking remain unsolved. https://gitlab.com/gitlab-org/gitlab-ee/issues/3975 </details>