馃殌 New Work Items UI - Weight rollup

Problem

  1. Several customers have vocalized the desire to add weight directly to an epic. This is useful when doing ROM (Rough Order of Magnitude) estimation before an epic is decomposed into smaller vertical slices and estimated by a development team.
  2. As we move towards work items with Tasks as the first step, users will naturally want to be able to set a weight on a Task. Given that issues already have weight as a field, we need to consider how weight ought to behave within this new model.

Proposal

  • A user can set a numeric weight on any work item into an Weight field.
  • Aggregate weights from children also show alongside/next to the work item's weight in a Rollup Weight that is system calculated and not editable. This value should reflect the weight added at the lowest level of the hierarchy that has weight as a field.

In the example below, Tasks do not have a weight field. The same rollup calculations would be used if Tasks did not have a weight field.

graph TD;
  Epic["Epic <br> Weight:10 <br> Rollup Weight:30"]-->Feature1["Feature <br> Weight:5 <br> Rollup Weight:25"];
  Epic-->Feature2["Feature <br> Weight:5 <br> Rollup Weight:5"];
  Feature1-->Story1["Story <br> Weight:10"];
  Feature1-->Story2["Story <br> Weight:10"];
  Feature1-->Story3["Story <br> Weight:5"];
  Feature2-->Story4["Story <br> Weight:2"];
  Feature2-->Story5["Story <br> Weight:2"];
  Feature2-->Story6["Story <br> Weight:1"];
  Story1-->Task1
  Story1-->Task2
  Story2-->Task3
  Story2-->Task4
  Story3-->Task5
  Story3-->Task6
  Story4-->Task7
  Story4-->Task8
  Story5-->Task9
  Story5-->Task10
  Story6-->Task11
  Story6-->Task12

In this example, weight is included for Tasks

In this second example, Tasks do have a weight field.

graph TD;
  Epic["Epic <br> Weight:10 <br> Rollup Weight:30"]-->Feature1["Feature <br> Weight:5 <br> Rollup Weight:25"];
  Epic-->Feature2["Feature <br> Weight:5 <br> Rollup Weight:5"];
  Feature1-->Story1["Story <br> Weight:10 <br> Rollup Weight:10"];
  Feature1-->Story2["Story <br> Weight:10 <br> Rollup Weight:15"];
  Feature2-->Story4["Story <br> Weight:2  <br> Rollup Weight:2"];
  Feature2-->Story5["Story <br> Weight:2 <br> Rollup Weight:3"];
  Story1-->Task1["Task <br> Weight:5"];
  Story1-->Task2["Task <br> Weight:5"];
  Story2-->Task3["Task <br> Weight:5"];
  Story2-->Task4["Task <br> Weight:10"];
  Story4-->Task7["Task <br> Weight:1"];
  Story4-->Task8["Task <br> Weight:1"];
  Story5-->Task9["Task <br> Weight:2"];
  Story5-->Task10["Task <br> Weight:1"];
  • This allows estimates to be set, then see "rollup" estimates once a work item is broken down in tree and roadmap views. Organizations can learn how accurate their estimates are at higher levels.
  • Once we have velocity and volatility and teams know what they are likely able to complete in a given time period, surfacing "estimate vs actual" is an incredibly powerful mechanism to encourage trade-off discussions on the scope at a higher level of planning.

UX

See designs in this issue.

Acceptance Criteria

  • If the work item can have / has children, roll up the weight from the children to show the actual value alongside the estimate.
  • Only the estimate field is directly editable.
  • If the work item cannot have children, do not show the actual value as it will always be NULL.
  • Estimate and actual update in real-time.

Tier

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by Melissa Ushakov