[UX] Users can more easily understand factors impacting iteration delivery and velocity at the iteration level
Overview
-
👍 Users can move items between iterations, and within a cadence items can be automatically rolled over to the next iteration if they aren't completed when the iteration closes -
⚠ Currently once items have left the iteration, including by rollover, they no longer appear in the iteration. Users can see the previous iteration in the item's system notes, but the stats on the iteration inaccurately reflect the completion of the iteration (e.g. if all incomplete items are rolled over, and not present, then it appears as 100% completed). -
⚠ Items can be added during the current iteration, which are reflected in the burnup chart as an uptick, but users cannot easily see which item were added.
Opportunity
It can be helpful for users to be able to retrospectively analyze an iteration to see what was planned and what was completed, including changes to the scope. This can help users analyze their plans and adjust future iterations, e.g. knowing that the team completed 80% of the scheduled work, and that there were 2 bugs added during the iteration, can help convey both what happened and why.
Maintain visibility of scope, and changes to scope, both during and after the iteration is complete to support users understanding of the lifecycle of the iteration.
Success criteria
- Items that were removed from the iteration (while current) remain in the iteration list with an indication they were rescheduled.
- Items that were added to the iteration (while current) are shown in the iteration list with a visual indicator noting they were added scope
- Items moved before an iteration starts are not considered scope changes and do not need to be indicated
- Total increase in scope is indicated as part of the top-level metrics
Edited by Nick Leonard