💡 [Solution Validation] Weight Rollup

Problem

If an issue with a weight of 5 is decomposed into two tasks with weights of 2 and 3 respectively, when the issue is added to an iteration, we should not double count the weight from the parent and the child(ren).

Proposal

With child items present, show the highest level item directly-assigned to the iteration. In most cases, this will be an issue, though it is also possible for tasks to be assigned without assigning the parent issue.

When displaying progress by count, count the items shown as described above.

When displaying progress by weight, count the rollup weight of the items shown along with a count of completed weight for items with children in the iteration.

• If the rollup weight differs from the assigned weight, indicate this difference.

Timebox status of issues

• Issues with assigned tasks should be considered “started” regardless of whether the issue is assigned
• Issues with assignee should be considered “started” regardless of tasks (current behavior)
• Weight/count belong to parent’s status when parent is assigned to the timebox
  • Weight completed on child tasks counts toward burndown while issue remains “Started”/“Ongoing”

Example:

Iteration 1 has the following assigned:

Issue#1: Weight 3 - Completed

Issue #2: Weight none

• Task #3: Weight 1 - Completed
• Task #4: Weight 1

Issue #5: Weight 2

• Task #6: Weight 1
• Task #7: Weight 2 - Completed

By count: 1 of 3 completed

• Issue 1 complete; Issue 2, Issue 5 incomplete

By total weight: 6 of 8 completed

• Issue 1 (3 complete), Issue 2 (1/2 complete), Issue 5 (2/3 complete)4

UX

Questions to answer

• What level of estimation is needed at the task level?
• What level of estimation is needed at the issue level?
• What level of estimation is needed at the epic level?
• Are the "units" the same (hours, points, t-shirt size, etc)?
• What is expected to appear in velocity reports when multiple estimates exist?
• When weight is present on both issues and tasks, what is the expected roll-up weight within a parent epic?

Findings

Findings:

• Weight Rollup:
  • Most liked the flexibility to estimate a parent and the children separately.
  • Some expected the children (leaf nodes) to be the "actual" when the estimates are aggregated.
  • Others expected the "actual" to be larger between sum(weight of children) and parent weight.
• Count Rollup:
  • If a parent with children is assigned to a timebox, the parent is shown on the timebox report, and the count is 1.
  • Those I spoke with did not use the count burndown/up option because they estimated their issues and tasks.**

** This is not the case, though for teams that use Kanban and do not estimate individual issues