nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

burndown chart to show story points from sub-task (or technical task)?

Mark_6pm0qs

Hi All,

We use epics for specific large features, stories for the individual capabilities of the larger feature, and technical tasks (aka sub-tasks) for individual work items.

When a technical-task is complete, I want to see this reflected in the sprint report (or any burndown chart)

So far, I've figured out how to add story ports to the technical-task issue type. (custom field) However, it's not showing up on the burn down chart, after assigning story points to technical tasks and then completing them.

It looks like this used to be possible by using context filters to add sub-tasks to the context. However, this only applies to Classic boards, and I haven't figured out how to get it to work in the 'new boards'

with just epics and stories, we can't break down tasks enough to see appreciable change on the burndown chart - basically we would only see story’s completed near the end of the sprint. We can't break down the Epics any more without polluting the epics list a LOT more.

Can we count the story points from technical tasks on the reports, before the owning story is complete? I would prefer to avoid manual time tracking/updating time remaining.

Accepted answers

Jayaprakash Puttaswamy

folks,

I'm an Agile coach, currently coaching a few teams on using JIRA Agile effectively. We are using JIRA Agile 6.6 which is the latest version as on today. Here is my suggestion for the above confusion:

The source of confusion:

JIRA Agile has a field called "Estimate" for issues of type "User Story" and it represents Story Points and this field is editable only in Plan mode only if the issue is still in backlog. (which means that we can't edit it once it is in a sprint). That is a good aspect.

It also has other 2 fields called "Original Estimate" and "Remaining Estimate" which can be edited any time.

In addition, it has another field called "Time Spent" which gets updated whenever we use "Log work" functionality for an issue.

Catch: There are two ways of updating ""Remaining Estimate" field.

First way, using "Log work". If we use this, the tool automatically updates the "Remaining Estimate" by subtracting latest "Time Spent" value from "Original Estimate" field value.

Second way is by updating the "Remaining Estimate" field ourselves manually instead of using "Log work" facility.

Effective Solution:

To have a meaningful Sprint burn-down chart, I recommend that team members stick the practice of updating "Remaining Estimate" field value directly and manually ever day instead of using "Log work" facility. And, if we ensure that "Estimation Statistic" is configured to use "Story Points" for estimation and "Remaining Time" for time tracking, then, Burn-down chart automatically uses the total "Remaining Estimate" of all the tasks mapping to all the stories planned for a sprint.

This means, there would never be a need for us to change "Estimate" field at story level since they are anyway relative size of stories. Only thing team needs to worry is to update ""Remaining Estimate" field of all the technical tasks they are working every day.

The only time we may need to use "Time Spent" and hence "Log work" facility is if we really need to track if the team is spending extra time in doing unproductive work other than their technical tasks. This includes waiting time, dependency wait, spending time on understanding scrappy code, etc... and all this is considered software waste in Lean thinking. This way, we can identify waste and possibly source of waste (by entering meaningful comments when we log extra work) and taking proactive action.

Last bit: Finally, this whole approach would be successful if we realize that Sprint burn-down chart's purpose is different and purpose of analyzing actual "Time Spent" is different and hence it is wise to d-link them.

All comments

Kim Poulsen

I have tried to find a solution for this as well. We call it a cliff hanger burndown :-)

To the solution: There is none involving story point estimates. The charts are solely looking at "Story" Issue type issues. Sub-tasks (technocal or otherwise) are only meant to perform a work breakdown of a story. Individually they do not get a story point value in Jira Agile (as you noticed when adding the cusom field yourself).

So until further: Use time tracking if you want a nice burn down graph. OR re-estimate the story points during the sprint on the sprint issues. This solution however has the disadvantage of rendering the reporting section useless when it comes to the velocity chart and version/epic charts.

I doubt Atlassian will change this behaviour as time tracking is the path Agile describes when taking an issue through sprint planning (story points gets handled and estimated in hours on its way into a sprint). But like you we think it is over the top and not motivating so we trust eachother, talk about impediments (use the flagging feature actively) and live with the cliff hanger burndowns.

Mark_6pm0qs

After asking this question, we created an interim solution. I added Story points to "task" issues. Now we create tasks instead of sub-tasks when we plan our sprint, and add story points to them, and link them to the coresponding story (which does very little). Now when we complete tasks, they are correctly shown on the burndown chart.

The good part is that I don't have to update time remaining (ever) and they're pretty easy to create.

Kim Poulsen

Sounds like a path to go by even though your backlog will get pretty polluted with (sub)tasks not belonging to the backlog.

Of course it all depends on how you practice the Agile meetings, i.e. if you do a lot of grooming leading to a number of almost planned sprints or if you have a huge sprint planning session including the user story break down at that time.

We are in the first category so having maybe 2-3 times as many issues visible in the backlog is not a viable solution for us (okay, så quick filters can be made to remove "task" type issues but still)

Your release notes is probably also becoming very long and impossible to understand when all subtasks show up in an extremely long list. But if this feature is not used, then it doesn't matter.

The issue linking is also kind of a hassle compared to creating sub-tasks but I definitely see your idea and it can definitely be usable for some ways of Agile practitioners.

Good thinking though. If there is an issue to vote for for getting story points on sub tasks tallied up on the charts I'd vote immediately.

Kumaran C_o7fbqh

Hi,

I am also looking for a solution. Our problem is we need to estimate on the sub-task level during planning mode and then log work against sub-task during work mode. We want to see the burndown chart for everyday scrum meeting. Can you suggest?

I tried the below options

Have the Estimation Statistic based on Story Points and use Remaining Estimate and Time Spent for Time Tracking. Update the story points to be same as remaining hours at the end of planning. Below are issues I am facing with this approach

In-Progress and Done points/hours in the plan mode doesn’t show up when the time spent for sub-task is updated
It affects Velocity chart since we estimate in sub-task level and the original estimate for parent is 0

Have the Estimation Statistic based on Original Estimate and use Remaining Estimate and Time Spent for Time Tracking. This leaves to the question of whether we need to estimate the parent issue or estimate only the sub-tasks. Both approach have it’s own plus and minus

If we estimate only the sub-tasks and leave the parent original estimate with 0. This has the same disadvantage as the previous approach.
If we estimate only the parent and log work against sub-task, this does not reduce the remaining hours for parent. Burn down chart looks flat.
Finally tried with estimating parent and sub-task. Now the remaining estimate in burndown chart is doubled

I am now left out with the only option to create tasks instead of sub-task. We will have to manually create tasks and link them to parent and we will not be able to create sub-tasks from Plan mode screen. Can anyone suggest me a solution?

Arthur Dobelis

This seems to be a popular question/request. I find it quite surprising there is no way to integrate subtasks into burndown charts (say, through percolation of subtask story points to parent tasks) and plan view. I am sure some people prefer the current behavior, but it seems many users also want these other integration features to enhance project analysis, reporting and overall transparency. It would seem to be something that could be easily optioned out through one or more project management option toggles.

A common answer to this question seems to be of the "principled" sort: i.e., "subtask completion does not actually burn down work so it should not be integrated into burndown," or the like. But isn't part of the point of agile to improve process and outcomes in ways that are appropriate to the project demands? I don't buy that we are all "doing it wrong" if we want greater subtask-task integration.

One way I've heard many people deal with this is by not using subtasks at all. That seems an unfortunate abandonment of a useful feature.

P_36k08z

Interesting track!

Suggested solution!

As far as I am concerned it could be done using the team velocity to calculate the estimate for the story based on story point. i.e. StoryPoints/StoryPointsperHour(Velocity) and using that as a baseline for the stories original estimate on the burndown. The logged work could then be added to the sub-tasks as it is today. This also helps me to track the accuracy of my story point estimates and doing it this way I 'only' need to track and use my velocity somewhere and don't need to 'estimate' time in the sub-tasks (which kind of defeats estimating in Story Point in the first place). The rest could be automated smile

I know I've simplified this issue somewhat, but it would be nice to have a 'better' solution that the one we have now.

Jayaprakash Puttaswamy

folks,

I'm an Agile coach, currently coaching a few teams on using JIRA Agile effectively. We are using JIRA Agile 6.6 which is the latest version as on today. Here is my suggestion for the above confusion:

The source of confusion:

It also has other 2 fields called "Original Estimate" and "Remaining Estimate" which can be edited any time.

In addition, it has another field called "Time Spent" which gets updated whenever we use "Log work" functionality for an issue.

Catch: There are two ways of updating ""Remaining Estimate" field.

First way, using "Log work". If we use this, the tool automatically updates the "Remaining Estimate" by subtracting latest "Time Spent" value from "Original Estimate" field value.

Second way is by updating the "Remaining Estimate" field ourselves manually instead of using "Log work" facility.

Effective Solution:

Ronen Barenboim

Thanks for a great explanation!

Jeff Atwood

This is what we are thinking about doing, but 1. where can you change tasks to story points and 2. if you move "story" and "tasks" into sprint...it will consider double the story points (i.e. story has 13 points and all tasks equal 13 points. If both dragged into sprint, it would show 26 points, no?).

Reg Hawkins_qlak9y

Be warned subtasks are not reflected in Epic reports or Release reports

Scott Baierl

What's funny is that you can put story points on sub-tasks in Portfolio, and they get automatically summed up to the story level, and that gets summed up to the Epic, etc... So, you can let it auto-calculate the story points on the story, as a summation of the story points on all subtasks. But, once you get over to the team "board" and try to use this for sprint planning, you are out of luck. This does not appear to be supported on the Board or Backlog views.

Because the way subtasks work, for us, it has changed the meaning of a story from an individual piece of value we would deliver to a customer, into the smallest piece of work you would want to assign to a team member.

We try to minimize work in process in our teams, and would like to have many team members collaborate to deliver a story, but without the ability to track story point allocation to each team member at the subtask level, it becomes much more difficult to see if a team member is over-allocated or not.

Dave Ingram

Good explanation as far as it goes, but I think you missed the particular question about sub-tasks. :-)

Evangelo Panagi

Thats the answer I'm looking for too!!! So far the only way i'm getting around this is by having Tasks estimated, and manually linked to a Story which consolidates the delivery of that function / component.

Danut M _StonikByte_

Hi @Mark ,

The latest version of our Great Gadgets plugin offers this. The sprint and release burndown gadgets have an option to include sub-tasks, which you could use to achieve this. The plugin is available for both Jira Server (https://marketplace.atlassian.com/apps/1218777/great-gadgets-for-jira-server?hosting=server&tab=overview) & Jira Cloud (https://marketplace.atlassian.com/apps/1216564/great-gadgets-for-jira-cloud?hosting=cloud&tab=overview).

Danut.

Kim Dinh

We're evaluating your gadget and I'm not seeing completed subtasks points on the burndown. Poring through your documentation and no luck. The only time I see any data is hovering over a part of the graph, which is not very useful.

Maybe we can chat offline?

Danut M _StonikByte_

Hi Kim,

Yes. Please send some screenshots with the gadget and its settings to support@stonikbyte.com. Do you have Jira Cloud or Jira Server?

Also, please make sure that you have the latest app version.

Thank you,

Danut

Kim Dinh

Done!

Ardani

We do the same thing here. Since sub-task is not represent the burndown chart. We specifically breakdown every small tasks and put it into task and put story points there. I think t would be nice if we still can use both task and sub task to monitor the progress. Maybe auto sum all story points from sub tasks into 1 particular parent task. So we don't have to put story points in task. Just some thoughts

Vijay Kulkarni_klg5oe

Rally tool (from CA Technologies) is able to easily handle this. They have planned Story points field which is updated durign planning. Then durign sprint execution, team keeps updatign how many story points remaining. Towards the sprint end, it is expected to come to 0. That means during the sprint, we are able to see how its progressing and how much work is still remaining to be done.

I wonder how difficult is this for Jira to implement it.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

burndown

sub-task

story-points