Burn Down Chart Using Sub-Tasks

[Tina Rusnak]

Greetings! I have squads who are using story points for backlog refinement and quarterly planning. When it comes to sprint planning, the Product Owner will place enough items in the sprint backlog based on the average story points, but after that we focus building a tactical plan the squad can commit to based on the availability of squad members in hours.

Starting at the top, we break each story into sub-tasks, folks volunteer for the sub-task and then they give an estimate in hours for how long it will take them to complete that sub-task.

We create a sub-task within the user story, add the details, the person volunteering and also record their estimate into the "Original Estimate" field in hours. After we've done this for enough stories that meet the teams hourly availability for the sprint we complete sprint planning and start the sprint. So at when the sprint begins we have the number of story points committed to as well as the total number of hours to support that delivery. We do not assign points to people; stories have multiple sub-tasks assigned to different people.

In the past, I used to have squad members simply update the remaining time on their sub-tasks and the sprint burndown would update nicely. Something has changed, when they do that the burn-down is not affected.

My trouble is that I'm not sure what the correct approach to burning down sub-task hours is - what are the steps to have the hours spent reflected in the burn-down?

We have "Story Points" set as the estimation statistic so we can track velocity via SP which supports all the refinement and short/long range planning and then we have Time Tracking set to "remaining estimate and time spent".

Are we to use BOTH the "log work" AND also have to update the remaining time? I was hoping this would not be complicated as it's hard enough to have anyone update time tracking! I saw an impact on the burndown using "log work", but it is not consistent. I'm not sure if squad members are also updating remaining hours or not....ughhhhhh. This seems (Log Work) to be the correct place to enter time to burn-down sub-task hours; if we have set an OE on the sub-task - do we leave it as "adjust automatically" so the remaining updates on it's own?

We also have this TEMPO add-on that we are NOT using, I think it is also causing confusion. When you select "Log Time", it adds those time entries into the TEMPO spreadsheet, it does not burn-down the OE on the burndown chart. See two screenshots below.

Thank you and FYI pretty please on the soonest response!

Cheers!

Tina

[Nic Brough -Adaptavist- · Accepted solution]

There is a lot here to talk about, but I think there is a big question to ask, to try to avoid huge if/then essays.

How do you want to work?  Are your teams aiming to be "agile" or "waterfall"?  Or something in-between?  Or something else?

[Tina Rusnak]

Thanks for reaching out! I didn’t think there was that much to unpack; these are agile teams. I’m looking for clarity/confirmation with how Jira works in the above scenario. Maybe I gave too much background.

[Nic Brough -Adaptavist-]

Not at all, you might be surprised how much "lack of background" can mess up an answer or suggestion!

There could be a lot to unpack, but just saying "Agile" really helps us focus.  My next question is a bit more vague though.

Agile allows for a lot of flexibility and is a broad set of principles, not a specific method.  When you start to use a tool to track stuff, and you want it to be Agile, you usually need to look at what within "ways of working that help you be Agile" might work for you, alongside whether the software can do it that way.

So, a less vague question - are you imagining something very "Scrum" as the way to go, or a bit more kanban etc?

(I ask about Scrum because this is common, but it also pretty much does not work if you put estimates on sub-tasks, because that misses the point by a long way)

[Joshua Main]

Hi @Nic Brough -Adaptavist- , how does putting points on subtasks miss the point of Scrum?

[Nic Brough -Adaptavist-]

In Scrum, you list a set of items that need doing, and commit to doing them within a sprint.  In Jira, the items are issues.

It measures your progress on the binary "is it done or not?"

Sub-tasks are part of issues, not sprint items in their own right.  They are fragments of sprint items, they do not contribute towards "done" other than you can't say an item is done until all the sub-tasks are.

The analogy I was given (mumble) years ago, is that you have a story "do this jigsaw".  The jigsaw is a sprint item, and each piece a sub-task.

There's no point estimating each piece because there's no "done" until all of them are placed.  Same as in scrum.

Now I don't actually think estimates on a sub-task are "wrong", but it does not work in Jira because Jira does not expect you to do it, it breaks all the reporting.  You can do it, but you need to build a counting strategy that works with Jira, and automate it (and no, "just add up all the estimates on the sub-tasks on to the parent" does not work, you need to think more carefully)

[Uwe Pilz]

I at least found a way to track open/done sub tasks. That is less accurate then time tracking but avoids the time estimation overhead. Have a look here:

https://www.novatec-gmbh.de/en/blog/how-to-add-the-missing-sub-task-burndown-chart-to-jira-software/