:vhs: [**Video walkthrough**](https://youtu.be/LTNEC-\_ougE): [Why velocity](https://www.youtube.com/watch?v=LTNEC-\_ougE&t=0s) \[7m\] | [Iteration plan](https://www.youtube.com/watch?v=LTNEC-\_ougE&t=425s) \[13m\] | [Early design walkthrough](https://www.youtube.com/watch?v=LTNEC-\_ougE&t=1215s) \[13m\] ## Summary * **Target personas:** Sasha, Parker * **Feature description:** Teams planning their work with iterations can now see their velocity and volatility based on the team's historical throughput. Velocity is surfaced within iteration reports, the iteration cadence list, and directly within iteration lists on Boards. By incorporating velocity and volatility into timebox planning, teams will be able to set better expectations with external stakeholders on how much scope the team can likely complete in future iterations. * **Value:** Velocity helps teams discuss trade-offs and estimations meaningfully. It is not a measure of a team's success but a valuable way to spark conversations about the cost for different items in the backlog and when those could be reasonably completed based on the team's historical throughput. ## Proposal Discuss with UX and Engineers on the best way to approach: - Calculating velocity/volatility for a label over `n` number of iterations. We need a way for a team to understand what their velocity is. As it stands, teams can be represented by both groups/projects and labels. - We will want to surface velocity/volatility and other iteration metrics within Boards. What's the best way to set ourselves up for success there? - Where should we show this sort of historical information? Where should we put some of the settings we will eventually build? ### **Iteration plan** **MVC1: Users can effectively use tasks in iterations** UX: https://gitlab.com/gitlab-org/gitlab/-/issues/440494+ * Parent/child relationships are clear in iteration detail * Weight rollup is used to avoid double counting Validation: Weight rollup behavior was [previously validated](https://gitlab.com/gitlab-org/ux-research/-/issues/2261 "Weight rollup logic solution validation"), UI changes are minimal within existing patterns **MVC2: Users can track and use velocity to plan and track pace across iterations** UX: https://gitlab.com/gitlab-org/gitlab/-/issues/440497+ * Velocity/volatility shown in cadence list for each cadence * Velocity shown in iteration detail as context to total planned * Velocity shown in iteration-based board lists Validation: Internal design feedback; short unmoderated usability tests if needed to resolve narrow questions. **MVC3: Users can more easily understand factors impacting iteration delivery and velocity at the iteration level** UX: https://gitlab.com/gitlab-org/gitlab/-/issues/440498+ * Added late/exited early items denoted in iteration detail Validation: Internal design feedback; unmoderated usability tests if questions remain. Can likely combine any testing with MVC2. **MVC4: Users can analyze trends across iterations** UX: https://gitlab.com/gitlab-org/gitlab/-/issues/440499+ * Cadence report exists with current and historical iteration details * Cadence report shows planned vs. completed over time Validation: Moderated solution validation on proposed design to cover both usability and alignment to workflow/data needs. **MVC5: Users can more easily plan and manage work within an iteration** UX: https://gitlab.com/gitlab-org/gitlab/-/issues/440500+ * Easier to use iteration lists (iteration detail) * Simplified methods for users to set up and use iteration boards (e.g. iteration report boards) **Validation: Solution validation, moderated usability test with additional focus on workflow alignment/additional data needs** **MVC6: Burndown charts better reflect team structure** * Add ability to exclude weekends in burndown charts * Add ability to specify iteration start/end times and reflect in burndown charts **Validation: Solution validation, unmoderated usability test to confirm ability to configure and use charts.** ### Calculations Calculating Velocity: ``` velocity = SUM(iteration_weight_completed, ...n) / n ``` Calculating Volatility: ``` volatility = (STDEV(iteration_weight_completed, ...n) / current_velocity) * 100 ``` Given the following previous iterations: - Iteration 1: 10 weight completed | Velocity = 10, Volatility = N/A - Iteration 2: 13 weight completed | Velocity = (10 + 13) / 2 = 11.5, Volatility = (STDEV(10, 13) / 11.5) \* 100 = 18.4% - Iteration 3: 15 weight completed | Velocity = (10 + 13 + 15) / 3 = 12.67, Volatility = (STDEV(10, 13, 15) / 12.67) \* 100 = 19.86% - Iteration 4: 12 weight completed | Velocity = (10 + 13 + 15 + 12) / 4 = 12.5, Volatility = (STDEV(10, 13, 15, 12) / 12.5) \* 100 = 16.7% - Iteration 5: 16 weight completed | Velocity = (10 + 13 + 15 + 12 + 16) / 5 = 13.2, Volatility = (STDEV(10, 13, 15, 12, 16) / 13.2) \* 100 = 18.1% - Iteration 6: 13 weight completed | Velocity = (13 + 15 + 12 + 16 + 13) / 5 = 13.8, Volatility = (STDEV(13, 15, 12, 16, 13) / 13.8) \* 100 = 11.9% ## Resources & Links - Examples of a velocity report generated automatically by a script: - Original prototype: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118436+ - Newer version (permalink): https://gitlab.com/gitlab-org/remote-development/remote-development-team-automation/-/blob/2ee560a7d29975854ca6cd44cb6182db62000199/lib/automation/planning_report.rb - Latest version (main branch link, may become outdated as code evolves): https://gitlab.com/gitlab-org/remote-development/remote-development-team-automation/-/blob/main/lib/automation/planning_report.rb?ref_type=heads - Example report output of latest version: https://gitlab-org.gitlab.io/remote-development/remote-development-team-automation/remote-development-iteration-planning-report-latest.htmlq