## Known Problems To Solve 1. There is no way to see which specific work items churned (not closed within the timebox's date range) within a timebox. (https://gitlab.com/gitlab-org/gitlab/-/issues/358959+, https://gitlab.com/gitlab-org/gitlab/-/issues/408063+) 2. There is no way to see which specific work items were added (scope creep) after a timebox started. (https://gitlab.com/gitlab-org/gitlab/-/issues/358959+) 3. Iterations do not surface velocity/volatility data, which is a valuable metric used to size and commit to scope within an Iteration properly (https://gitlab.com/groups/gitlab-org/-/epics/435+). 4. Now that `weight` is present on Issues and Tasks and we want to support associating Milestones to Epics eventually (https://gitlab.com/groups/gitlab-org/-/epics/329+), we need to figure out a standard pattern for displaying parent/child relationships within timebox reports and prevent double counting weight (https://gitlab.com/gitlab-org/gitlab/-/issues/381879+). 5. We have received feedback that people prefer the general format of the Milestone report view vs. Iteration report view (https://gitlab.com/gitlab-org/gitlab/-/issues/384343+). The primary difference between the two is the location of the metrics and the presentation of the individual work items within the report view. 6. There are a number of quality of life improvements that customers are looking for. Examples include omitting weekends from burndown charts, setting an explicit timezone and start date for iterations (https://gitlab.com/gitlab-org/gitlab/-/issues/345119+), and other usability improvements (https://gitlab.com/gitlab-org/gitlab/-/issues/365047+). 7. The timebox detail view is vital for reviewing a single iteration or milestone. Still, we do not provide aggregated metrics that provide insight into a team's performance across many timeboxes. This frequently comes up in discussions as an essential problem to solve for customers (https://gitlab.com/gitlab-org/gitlab/-/issues/358960+, https://gitlab.com/gitlab-org/gitlab/-/issues/358961+). 8. Customers have expressed a desire to filter timebox reports by various attributes and have the burndown/burnup/metrics/work items listed automatically recompute based on the active filter criteria (https://gitlab.com/gitlab-org/gitlab/-/issues/378587+) ## Desired Outcomes - Increase the value of planning with timeboxes in GitLab by improving the reporting experience and integrating key timebox metrics into planning workflows such that they positively impact the team's ability to set more realistic commitments while also receiving feedback on how they are improving (or not) from one timebox to the next. - Achieve relative consistency between Milestone and Iteration report views. - Iterations use the most modern implementation details. - We should be able to leverage the same FE implementation for Iteration and Milestone detail views. ## UX TBD ## Iteration Path TBD