Skip to content

Prevent double counting weight/count from parents and their children in timebox reports

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem

JTBD:

When I'm reviewing my timebox report [iteration, milestone], I would like to see accurate burnup/down charts and progress reporting, so that I can understand how we are executing, or did execute, against what we committed to.

Additional context around the JTBD:

  • Teams all have different processes and strategies for estimation and progress calculation.
  • Some will estimate parents (issues in this context) with a ROM (rough order of magnitude) weight during release planning, then refine the parent into tasks and weight each task during iteration planning.
  • Some will not estimate parents and only estimate children, but assign the parent to the iteration with a scope of tasks that can be reasonably completed within the timebox.
  • Some will estimate only the parents and not add refined estimates to children (tasks).
  • Some will estimate the parent and only partially break it down into estimated tasks, assuming that some portion of the weight in the parent still remains to be broken down into tasks to be work on during the next timebox.

Problem:

  • An issue can have a weight and be associated with a timebox.
  • A task can have a weight and be associated with a timebox.
  • When an issue and its tasks have a weight value set, how do we accurately present progress information within timeboxes?
  • If an issue with a weight of 5 is decomposed into two tasks with weights of 2 and 3 respectively, today when the issue is added to an iteration, the weight will be 10, which is double counting both the parent and the children weight.
  • The same problem applies with measuring progress by count. If I have one parent with 5 children in an iteration, does that count as 1, 5, or 6?

Proposal

  • If a parent work item has a weight and its children also have weight, the weight of the leaf nodes (children) is used to calculate the parent weight contributed to the iteration.
    • This weight is shown as the weight (for this iteration) of the parents - there is never a case where children are shown with a total weight different from the parent. The weight is read from the top-level item but derived from its children.
    • Completed weight is calculated the same as planned weight.
  • If a parent work item has a weight and its children do not have weights, the parent's weight is contributed to the iteration.
  • If a Task is directly assigned to an iteration, without its parent, it's the top level item and contributes its own weight; the parent issue is not shown.
  • If an issue has multiple tasks, and some tasks are completed in a prior iteration, only tasks in this iteration are shown/counted.
  • Total number of top level items determine the count
  • Parent and child items are both visible when both are assigned; child items are nested within the parent item.

Validation & Supporting Data

  • Qualitative - From 💡 [Solution Validation] Weight Rollup (#385921 - closed) and the limited insights from interviewing 6-8 customers (sync and async), we learned that:
    • Teams break down issues (frequently referred to as "user stories") into Tasks.
    • In most cases, it is expected that weight from children will roll up to the parent to represent the "actual weight."
    • Sometimes, parents will be estimated first before they are broken down into children.
    • Some customers expected the "actual weight" to be the larger of the two (parent itself, rollup from children)
  • Qualitative - From https://gitlab.com/gitlab-org/ux-research/-/issues/2261+ we learned that:
    • Users do not expect parent/child counts to mismatch, and it's confusing when it does.
    • Users expect child weight to supercede parent weight when it exists, as this reflects a more granular and thus more accurate estimate
    • Users want an indication when the parent/child weights are different (being added to the item detail detail to avoid confusion about which value is used in aggregates)
    • Users that do not estimate child items expect the parent to be used
  • Quantitative - On GitLab.com:
    • 3.2% of all tasks have a weight. This suggests that many teams may only estimate the parent and not the children...or not use estimates at all.
    • Of the tasks with weight, 62% belong to a parent (issue) with a weight. This suggests that teams are estimating children doing so after the parent has been estimated. This concurs with the qualitative data we collected that estimating a parent is a common practice and then further refining, breaking down, and estimating children.

Availability and Testing

Regression testing, please make sure e2e:package-and-test job is passing.

Ensure updated test coverage in unit/integration/feature tests.

Edited by 🤖 GitLab Bot 🤖