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; } } }

burnup and burndown chart issue with stories and tasks

Jenny Goh

Hi there, I am new to JIRA.

Just a disclaimer, I've done reading documentation, searching and watching Youtube videos plus Googling. I couldn't find a good answer to the problem I am facing so decided to ask here.

I was used to other platforms where task is a child of story (such as Azure DevOps). So when you move task to Done, you get a burndown. However here, I realized that task is at the same level as story. But I've already created a board - with the stories broken down into tasks! Now if I move both stories and tasks then I would get the same stories burnt twice.

For this sprint, in order to circumvent that (since it's sprint 1, I have room to maneuver), I decided to change user story points for the stories to zero. So I can move the stories and the tasks associated to it without getting the same stories burnt twice. However! It seems that JIRA Software did not take that into consideration and still count in my zero-ed stories...

Any idea what I can do? I have exhausted all avenues so any advice will be greatly appreciated.

First follow-up question is: if I broke down my task into stories, and wanted to just burn the tasks and now the stories, would that work in JIRA? If not, what is the best practice?

Second follow-up question: If I estimate using story points first, followed by doing time tracking using estimates (logging work by weeks/days/hours/minutes), would that work better? I would prefer not to do the tracking using estimated hours/remaining estimates because my client wants to track using story points. Is there any recommendation/best practice I can follow?

Thank you for your help.

Accepted answers

All comments

Trudy P Claspill

Hello @Jenny Goh

Welcome to the community.

Can you tell us exactly what you mean by ...?

"It seems that JIRA Software did not take that into consideration and still count in my zero-ed stories..."

In a burn down chart, the Guide Line (grey line) will remain unchanged when you change the story points after starting the sprint. That line is based on the total estimate statistic value when the sprint was started. The Remaining Values (red line) should change as you change story point values.

The list of issues in your sprint will be changed only by removing or adding issues to the sprint.

A burndown will include all issues that are of the Standard type grouping (Story, bug, task) that are included in your board filter. If you are using a Company Managed board, you could modify the filter to exclude Story issue types, and then they would be excluded from your board display and your sprints for that board.

Alternately you could convert your Story issues into Epics, and make the Tasks child issues of those Epics. Epics should not be assigned to sprints and so would not be included in a sprint burndown chart. Note that Jira has a limited native issue hierarchy:

Epic > Standard issue types > Sub-task issue types

You cannot expand that hierarchy without using third party apps, or getting the Premium subscription and using Advanced Roadmaps. Or, you can using the issue linking functionality to specify different types of parent/child relationships, but Jira will not recognize those automatically as parent/child relationships.

So, if you convert your Stories to Epics, they can't be children of other Epics.

If you are not already using Epics, then I recommend that you use Epics, and use the Standard issue type of your choice (Story, Task, whatever) as the entity you estimate and track in burndowns.

Jenny Goh

Hi @Trudy P Claspill thank you for your kind reply.

Let me explain a bit on the zero thing.

As it was my first time, I only realized after added stories and tasks to the board that the burndown will include both stories and tasks. But then it will burn down the same story twice.

A hypothetical scenario below: suppose story has 8 points, there are 2 tasks, each 4 points. If I move the story AND 2 tasks together to Done, then the burndown will now reflect 16 points when it's actually 8. So I tried changing the story's user story points to 0, but it seems like that did not work, The burndown is still showing me burning 16 points instead of 8. That's the zero scenario.

"Alternately you could convert your Story issues into Epics, and make the Tasks child issues of those Epics. Epics should not be assigned to sprints and so would not be included in a sprint burndown chart. Note that Jira has a limited native issue hierarchy".

-- but in this case wouldn't you end up with MANY epics? Is that the best practice though?

Trudy P Claspill

Hello @Jenny Goh

Burndown shows multiple values. Can you provide a screen image and point out the specific item you're looking at when you say "The burndown is still showing me burning 16 points instead of 8. That's the zero scenario"? As I mentioned, the grey line (Guide line) will not be changed when you make changes to the story points after the sprint starts. The red line (Remaining) should reflect changes.

As to having "many" Epics, whether that is considered good or bad is subjective, as is what constitutes "many". What problem do you foresee arising if you have "many" Epics?

Epics are a way to group together the work that needs to be completed to achieve a larger goal. The scope of an Epic is such that getting all the work done within it will span multiple sprints. There are burndown charts for Epics also that will show you how you are progressing on that larger goal.

Are you already using Epics? What do you see as the downside of using Epics?

Another choice you have is to keep your Stories and break their work down into Sub-tasks. Sub-tasks do not generally get Story Points assigned. Sub-tasks are not an independent issue type in that they:

- can only be created as children of another type of issue

- are not assigned to sprints independently. Rather they are in whatever sprint their parent issue is assigned to

- completion of Sub-tasks is not reflected in the burndown chart.

Sub-tasks allow you to break the work down into even smaller chunks. Maybe those work items can be worked on in parallel, and by different people. They can give you a more granular view of the work needed to complete a Story and the progress on that work, similar to how Stories break down the work of an Epic and help you see progress on the Epic.

I have worked in both Jira and Azure DevOps. The issue hierarchy in Jira is simpler than the hierarchy options in Azure DevOps. You will need to think differently about the scope and context of Story, Task, Bug, and Epic as you work with Jira.

Nic Brough -Adaptavist-

Hi @Jenny Goh

This is a common mistake when people try to adopt Scrum, we mix up Sprint items with non-sprint items.

In Scrum, you have a list of stuff that needs attention (stories). You estimate them, commit to doing some of them each sprint (sizing it so there is a good expectation that you'll deliver something you can show moves you towards the end-goal at the end of the sprint) and then move on to the next sprint.

Scrum doesn't say anything about sub-tasks, beyond "if they help, feel free to use them, like any other idea"

That is the important bit - sub-tasks are not sprint items. They are a part of their parent story. Scrum ()and Kanban, for that matter) dn't care about sub-tasks. So nor does Jira (at least when it's talking about estimates).

The short and easy answer is "do not estimate sub-tasks". In real life, nah, go do it, but if you do, you need to think carefully about "Sprint Estimate" vs "Estimate"

Jira will not look at your sprint estimate on sub-tasks. They're a part of their Story and the sprint estimate is on that Story. It will report happily on other estimates, it's just the sprint estimate you need to look at.

There are lots of ways you might put estimates on sub-tasks and have them contribute towards sprint estimates, but Azure Devops lets you get it wrong (it's not a Scrum tool unless you turn off estimates on sub-tasks), and Jira doesn't bother, going for the minimal implementation of "don't put sprint estimates on things that are not sprint items"

There are ways to do what you want. @Trudy P Claspill has given you a list of the best options already. There is another option I want to add to the list, but it is by far the weakest - automate some calculations that trick Jira into taking your sub-tasks into account (short story - estimate all your issues, then calculate the actual sprint estimate separately)

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

burndown

story-points