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. 

[Trudy 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 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 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 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)

[Jenny Goh]

Hi @Nic Brough -Adaptavist-  thank you for the feedback and advice.

To clarify - I was referring to tasks, not sub-tasks, as I understood that JIRA doesn’t take sub-tasks into account. If you re-read my replies to Trudy, what I did was breaking down the stories into tasks, not subtasks. That is why I ran into problems with the burn down because that is not how JIRA looks at tasks. In Azure DevOps, tasks is configured as a child to stories. So if you finish moving all the tasks to Done, your story is marked as complete. But since JIRA treats tasks as one issue type, in my burn down chart the same story got burned down twice because I had to move both stories and their associated tasks to Done. 

I hope this is clearer on the challenges I am facing :)

And yes Trudy provided some good food for thought and suggestions, I’m  trying to do some screen shots so I can reply to him. 

[Nic Brough -Adaptavist-]

Yes, this does help explain your challenges.  There's one bit that stuck out to me:  "If you re-read my replies to Trudy, what I did was breaking down the stories into tasks, not subtasks"

There's no difference between what you call a "task" here and a "sub-task".  Other than the name.

When you break down a story, everything is a subtask.  That might be Jira-speak, it might be Agile-speak, but the point is that there are two ways to break up a story - split it into two stories, or separate out fragments of it for some reason.

I'm afraid all I can circle back to is that sub-task estimates should feed into your sprint estimates, not be actual sprint estimates.

[Jenny Goh]

Hi @Trudy Claspill  

Here's what I'm seeing in my burnup: 

I have about 300+ stories now, so I was wondering if it makes sense to have >300 epics. I am new to this, so maybe I have not yet had the experience working with so many epics, or maybe I need time to think about what epic means right here. But, you gave a very good advice so I am weighing those options right now :) 

@Nic Brough -Adaptavist-  The sub-task concept is new to me, so I am still trying to understand. One thing that I am thinking of doing is to discuss with my team and requesting them to break down the stories into smaller pieces. That way, the stories could probably be tracked better on JIRA. I am neither a proponent of JIRA nor Azure DevOps. We might be familiar with some tools, but they are tools, so at the end of the day what matters it understanding the concepts and using the tools to reflect the work that we are doing. 

[Trudy Claspill]

@Jenny Goh 

300 is probably not a manageable number of Epics.

Harkening back to my days using Azure DevOps, I would recommend that you break your Story issues down with child Sub-tasks. The Sub-task will automatically stick with the Stories as far as association to sprints. And make sure that your. Story issues are scoped so that the work they describe can be completed ideally within the timeframe of a sprint.

You could continue to estimate your Stories with Story Points, but you would not add Story Point estimates to your sub-tasks. Instead you could go to your Board Settings > Estimation page and set the Time Tracking option to Remaining Estimate and Time Spent. Then during your sprint planning add Original Time Estimates to the sub-tasks. Those will automatically roll up to display in their parent story.

As you complete the sub-tasks you use the Log Work feature to log time worked against them and set the Remaining Time to 0.

If you do that, then you can look at the Burndown chart and choose to display it with either the Story Points or Remaining Time as the Estimation Statistic. With Remaining Time selected you will see the burndown progressing based on the Remaining Time in the sub-tasks. When you switch back to Story Points for the chart you will see a burndown of Points as the Story issues are set to done. You can even set up automation to automatically change the Story issues to Done when all the sub-tasks are set to Done.

You might want to set up a test project and experiment with that configuration over the course of a week  and a sprint or two to see how the charts look.

[Jenny Goh]

@Trudy Claspill  Hi Trudy, yes I have tried to copy to another board so I can experiment a bit. I didn't want to enter the stories from scratch as I already have so many stories in the current board, so I was thinking of converting bulk of tasks into subtasks. However, when I tried to convert the task to subtasks, I couldn't seem to do that. I tried the "move" function, but there was no option to select subtasks although I have turned on subtask and can create subtask separately. Do you know how I might resolve this? 

[Jenny Goh]

Hey @Trudy Claspill  I found the way to do that... problem solved. I will try converting those task to subtasks and see what happens. I did have one more question, with the remaining estimates... I'm assuming we can't really do that with burnup charts? 

[Trudy Claspill]

I haven't worked with burnup charts. I would recommend that you refer to the documentation for those and do some experimenting to understand how they work.

https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-burnup-chart/

[Nic Brough -Adaptavist-]

@Jenny Goh on your comment yesterday - yes, that's exactly what I would do, explain that sub-tasks are pieces of a story. 

I'd also ask teams to feel free to use them any way they want to (apart from sprint estimation), it's up to them how they break down a story into sub-tasks.  The most common uses are "it affects this specific part of the system" and "Alice, Bob and Dave all have a piece to do, so that we can assign the bits individually"

And thank you for the additional context in there, it's good to hear people understand that a tool is a tool, not a way of life!  (Although you could argue it has been for me ;-) )

[Jenny Goh]

@Trudy Claspill  Thanks - I have been exploring the burnup yesterday. After trying a few things, I am more inclined towards your suggestion of breaking stories down into subtasks and track the remaining estimates. 

@Nic Brough -Adaptavist-  Thank you for the discussion! It's not always easy to work on Agile frameworks and tools as people tend to forget why we use these concepts and tools in the first place! I look forward to learning more from you and the rest on the Atlassian community. Cheers.