Show the points of the sub and parent tasks in the Task Graph
Open, WishlistPublic


Root Problem

We are using the Scrum method to organize our work. Every product backlog task has several sprint tasks of varying complexity, stored as points in the sprint task. In the project workboard of a sprint it is good to see an overview over all tasks and the number of total points of each column. Sometimes it would be nice to see the complexity of a product backlog task, or more specific: the complexity of all the sub tasks of the product backlog task. As the product backlog task itself does not have any points, we could put the sum of all sub tasks as points in the product backlog task, but 1. this would also be added to the total number of points of the sprint and 2. as soon as a point of a task changes or a new task is added, the points of the product task has to be updated, too.

Feature Request

Best solution for us would be to show the points of the sub and parent tasks in the Task Graph. One could think of showing the sum of all tasks in the project workboard, too, but I guess this would add unnecessary complexity to the overview.

mirrom created this task.Thu, Feb 16, 9:18 AM
epriestley triaged this task as "Wishlist" priority.Sat, Feb 18, 2:50 AM
epriestley added a subscriber: epriestley.

I don't think this is necessarily unreasonable, but I'd like to see significantly more interest in it from other installs before we pursue it.

The complexity of building any version of this feature which sums points in a robust way is potentially very high because a task may have an arbitrarily large number of subtasks, and some tasks here and on other installs have (or, at least, had, at the time we shipped task graphs) hundreds and hundreds. When we're drawing the task graph, we degrade into various summary modes where we show only part of the graph if we find too many nodes, but we can't add up just part of the graph.

Additionally, because task relationships are a directed acyclic graph -- not a tree -- we can not simply sum the children of a node to arrive at an aggregate point total. Consider this graph:

If we naively add points recursively, we'll compute A = B + C, B = 5 + C, C = 3, and end up with A = (5 + (3)) + 3, which is 11 points, which is wrong. X will be worth 8 points, which is also almost certainly wrong, since X + A are then worth 19 points together.

We can conceivably just put the point value of each task onto the graph without trying to sum anything, but I think this only serves fairly vague informational goals ("it would be nice to see an overview") and isn't especially valuable.

We could do sums and just give up in all the hard cases (non-tree children, too many nodes, etc) but I'm also unsure how valuable this really is in general.

T12278 suggests that "sprint tasks" are being used in this workflow -- not milestones -- and "backlog tasks" are being used -- not columns. But this task also mentions columns and workboards. A more detailed description of your workflow would be helpful in understanding where the intended tools (milestones and columns) are falling short.

Thanks for your feedback! As you said it might be very complex to automatically sum up the points of all sub tasks. Of course this would be a very nice to have, but it was not my intention to request this quite complex feature. For us a "simple" UI change would be absolutely sufficient. It would be great to see the points of all sub tasks in the Task Graph at a glance.

Actually we are using milestone projects as sprint iterations and are using columns to separate "sprint tasks" and "product backlog tasks". Sorry for the confusion here, I have to clarify this. The product backlog tasks describe the story and have no story points. Deriving from one product backlog task we create sprint tasks (or "backlog tasks") that describe the actual steps we need to do to finish the product backlog task and that keep the complexity as points we estimate for every step. I have visualised this in a typical sprint workboard of a milestone project we use:

For demonstration purpose I set the priority accordingly to visualise which sprint tasks belongs to which product backlog task. On a typical workboard you cannot see this connection, so it is hard to tell how complex a product backlog task might be. This is where the Task Graph would help us. I came up with a simple mockup: