Agile board: how to change report setting to include sub-tasks data?

[Miki Yuzawa]

Hi,

It seems that reports in Agile boards do not contain any sub-tasks. My Scrum team uses Story and Sub-tasks, and I would like to include data of Sub-tasks in the Sprint Report and burndown chart. Where can I change the setting?

Thanks,

Miki

[Renjith Pillai · Accepted solution]

It ofcourse uses the estimates from the sub-tasks. What is the option you have selected that you have done in the 'Estimation' tab while configuring the board?

[Miki Yuzawa]

Hi Renjith,

Thank you for your quick respond.

I selected:

Estimate Statistic -- Original Time Estimate

Time Trancking -- Remaining Estimate and Time Spent

Miki

[Renjith Pillai]

Are you estimating the values at the story level as well? I just did a test based on a couple of stories and with sub-tasks with estimates and I am able to see the burndown summing up the sub-task estimates.

Which version of GH?

[Miki Yuzawa]

No, we don't estimate at story leve. We add estimation to sub-tasks only. We use story as a place holder.

GH version: Atlassian GreenHopper - 6.1-rc1

[Renjith Pillai]

Sorry for my earlier question, missed the fact that you are OnDemand. Can you post a screenshot of the burndown and a couple of sub-tasks, if possible?

[Miki Yuzawa]

I attached a screenshot of last sprint.

As you see, it listed only Story as completed issues. No sub-tasks.

[Renjith Pillai]

OMG, story points are not used for sub-tasks. It is conceptually wrong, AFAIK.

Story points is always with a 'Story'. If you want to track the burn down of sub-tasks, use the time tracking in board configuration.

So it goes like this, IMHO

• The story points are estimated at a story level for velocity and release planning
• Sub-tasks are estimated by the team during sprint planning and the burndown monitored to check how they go with the sprint (again by the team, no managers involved :)
• End of sprint, when the story is closed, the velocity will reflect the total of the story points.

[Miki Yuzawa]

I understand what story points are for. We are not using story points. I am not looking for getting velociy based in story points. I simply wanted to includ sub-tasks data in sprint release. I guess I cannot to configure to do that?

[Renjith Pillai]

Did I sound a bit rude in my previous comment? If yes, sorry!

If you are looking at including sub-tasks data estimated as story points I guess the answer answer is No, you can't do it.

If you are looking at including sub-tasks based on time estimation the answer is Yes, it can be done.

[Ana Teixeira]

HOW can this not be an option? I only estimate tasks if they contain no subt-tasks, otherwise I'll only estimate the later. Now I can't see ANY of the reports because the tool simply does not contain an option to display ALLLLLLLL types to tasks in the report. Absurd!

[Nic Brough -Adaptavist-]

The estimates on a sub-task are of no use in scrum.  In scrum, you say "We will do X points, covering these stories".  You then deliver them, or you do not.  There is no partial delivery (your customers do not care if you deliver 1 point or 99 when you promised them 100 - you either deliver what you said, or you do not)

In real life, the estimates on sub-tasks can be useful during a sprint to see how it is going.  Jira takes the easier and technically accurate route of ignoring sub-task estimates.  It would be nice to see them internally, but as they are pointless in scrum, I am afraid the reports don't show them.

[Ana Teixeira]

Hello Nic,

I understand that the Scrum methodology requires some specific configurations if you're following it 100%. What I argument is the ability to adapt the reports and gadgets to teams who wish to personalize independent of how the management tool suggests/imposes. Jira prides on their "custom" reports, but there's certain limitations that I see no reason for considering the data source is the one and the same. I simply believe if not to include the subtasks, a manager should have the option to sum up their estimates.

I honestly don't wish to start a thread on the subject here considering it is truly a product owner's choice, I have already contacted the support for a change request where I can add my vote. After some research I know I'm not the only one around the community.

I appreciate the quick follow up though!

Regards,

[Jason Sacks]

I understand the reply above but it seems to me there is inconsistent behavior in the way JIRA reports estimates for Stories.

Scenario:

• Team creates Story
  • Time tracking estimate left blank pending Dev & QA loading subtasks
  • "Include Subtasks" checkbox checked in Time Tracking section
• Dev & QA team members load their subtasks with estimates
• The Estimated total automatically adjusts in the Time Tracking section of the Story to show total subtask estimates
• As subtask remaining time decreases, the Remaining time decreases
• When all subtask work complete, the Remaining time reaches zero. Hooray, the Story is complete
• Demo happens, PO signs off and customer is happy
• Scrum Master views Velocity Chart at end of Sprint
• Completed work is not shown in the Velocity Chart
• Scrum Master gets beaten up by his management team because his Scrum team under-delivered

Please help me stay in my management team's good graces.

[Nic Brough -Adaptavist-]

Ok, yes, it is inconsistent, but it's because there's two different products anticipating two different ways of working.

Plain Jira adds up sub-tasks to their parents.  It always has (since Jira 2 if memory serves).  This is because in a waterfall-ish project, you do break up issues into sub-tasks, for several reasons, and it makes sense to estimate / log work on sub-tasks as they get created and dealt with

Then Jira Software arrives.  With Scrum.  Where an estimate on a sub-task is useless because in Scrum, you do not commit to doing part of a story in a sprint.  There is no "partially complete", you either complete the story or you do not.  So Scrum totally ignores sub-task estimates, because they don't count.

Now, there's a good argument for adding up the estimates in various ways for all sorts of other reporting (there's at least three different strategies for this), but the sub-task estimates still have to be ignored by Scrum until the issue is complete.   Many other "agile" tools implement a way of doing this, which nicely breaks all your proper Scrum reports, but does fix the problem in general.  Atlassian have simply ignored the problem (because to fix it, they need to implement all the possible roll-up non-scrum strategies, which is a lot of work), leaving us with a simple rule - don't estimate on sub-tasks in Scrum projects in Jira.

[Jason Sacks]

Nic, I appreciate your honesty in this response, and I will communicate to my team "Don't estimate on sub-tasks in Scrum projects in Jira."

I'm not sure I understand your comment "an estimate on a sub-task is useless", because it allows my team to track completion of a Story. In simple terms, we want to see a full set of green checkmarks and 100% completion of all Sub-tasks for a Story. It appears you are suggesting we deprecate that extremely useful ability.

I have some follow up questions.

We have found the ability to see aggregated estimation and logged work from Sub-tasks in a Story to be extremely helpful in tracking a Story's progress towards completion. You say "Scrum totally ignores sub-task estimates" but JIRA contradicts that comment by providing a rollup of sub-task estimates in Stories. It even provides convenient tools to track completion of sub-tasks.

Should we change our methodology? 

Moving from philosophical to practical questions: Are you suggesting we no longer use that very convenient feature and instead have all team members log their work in the Story? Doesn't the completion percentage panel in the Story argue that we should track in the story? If we should continue to use estimation and completion in Sub-tasks, should we then also add an estimate to the story such that if the Sub-tasks add up to 7.5d of work, we add a 7.5d to our Story estimate? When we do that, it does 15d of estimate for the task. Is that expected? We tried that and my team gave extremely negative feedback in a retrospective.

Again, all I want is for my team to receive credit for the work they have diligently completed. Please provide guidance on the right way to proceed here.

[Nic Brough -Adaptavist-]

>I'm not sure I understand your comment "an estimate on a sub-task is useless",

>Again, all I want is for my team to receive credit for the work they have diligently completed. Please provide guidance on the right way to proceed here.

Both of those go back to the fact that there is no "partially complete" in Scrum, you either complete the story or you do not. 

> You say "Scrum totally ignores sub-task estimates" but JIRA contradicts that comment by providing a rollup of sub-task estimates in Stories.

Yes, that's why I pointed out that there are two different products aimed at different methodologies here.

If you want to do Scrum, you can't estimate on sub-tasks, because it doesn't work.

[Deleted user]

 This last comment is so misguided, I don't know where to begin to decompose it.

"If you want to do Scrum...".  You don't "Do" Scrum, you use it (what's defined within it) to help you figure out what your "ideal" process should look-feel-smell-sound like in *YOUR* context (i.e. not the context Jira wants you to operate in).

You ask yourself..."Is this useful?" all over the place.

While it's not ideally a good practice to estimate at the Task  (or in this case because of Jira's wonky data model. Hello "Task <==> Sub-task" with 9.9 out of 10 humans, even that 0.1 Human isn't happy with the disparity.), if someone wants to do so...Scrum doesn't say you can't. It doesn't even say TO estimate, it says if there is some refining going on, and that should you estimate, that sort of detail would behoove you to include them for your own benefit. It doesn't say WHERE to apply those estimates, or what those estimates even look like. (as silly as some of them might be....again...you'd be asking yourselves, "Is this useful?")

What if you were using Storyotypes, which allow capturing your Definition of Done as individual tasks on a Story, and you wanted to visualize your Done-ness that way (Hint: It starts to look like a Burn-up or Build-up if you can do simple counting of things. Which, by the way, Scrum doesn't say you can't do...."Is it useful?")? What? That's wrong.....of course it's not. It's actually pretty SMART.

Regardless of "getting credit" or not. Seeing progress of "tasks done", when you've built a plan of "Tasks to be done" to complete a Story (which is an ABSOLUTELY reasonable thing to want to do), should be a given. Period. Full Stop.

The fact that Jira's data model has a misguided association with:

Story -> Sub-Task... instead of Story -> Task...

Yet is unable to task completion of Sub-task count as a report is completely and utterly wrong. It's not just that it's broken. It's wrong. Period. Full Stop.

The funny part is that in Next-Gen projects, even THIS is broken. Next-Gen projects don't include "Sub-task" by default, but STILL, require a Task to be "relates to" to a Story for them to be counted as completed in the Burn-Up report ("by Issues Completed" filter). Again. Broken. Period. Full Stop.

"No Partially Complete in Scrum". Do you understand how Done works? 

Why do you think an Increment is defined as "Potentially Releasable"? Because it's perfectly reasonable to have...wait for it....UN-DONE work. Which means, while the Increment is DONE as far as the "Definition" it was given by the PO and the Development Team, there may YET be further work to.....wait for it....Release it.

Now, if I understood the question (or maybe I didn't, and I'm going to pose a different though related scenario to you), the desire is to track PROGRESS, during the Sprint, towards the forecast (after all, an estimate is a FORECAST, not a commitment. Not sure about that? Go look up what Commitment means in Scrum. It's to the other humans and their agreed upon Goal, not the items nor their estimates because....you know....agility means responding to change...so much for the estimate, the forecast calls for a different objective when the needs change. But I digress).

If this desire/need is to track progress, tracking:

Points Completed towards Forecasted Estimate for the Work. Check! You seem to have that just fine. 

Completed Task Count towards the overall Done-ness of the individual activities or components (i.e. The "HOW" of the work. Remember, the Stories are the "WHAT's".)...Miss! Remember that Scrum doesn't say HOW you have to visualize progress, rather recommends that a team SHOULD. It only mentions Burn-down/ups, and CFD's as examples of such. It doesn't say HOW or HOW NOT to.

The Burn-up in Jira completely misses this secondary opportunity to be truly useful. 

First, start with an understanding of the mechanics of what Scrum says, and THEN adhere yourself to its flexibility (yeah, let that sink in for a little bit).

Stop trying to make others adhere to your definition for Scrum, there already is one.

It's called the Scrum Guide. I should know, I translated it to Spanish 9 year ago for Scrum.org and had to keep it true to its essence while translating phrases that don't exactly match in another language. I kinda have a handle on this.

So, Atlassian.....fix this. It's not that hard....really, it's not.

[Reg Hawkins]

Be warned sub-tasks are not reflected in Epic reports or Release Reports

[Jason Galicinski]

I too am finding sub-tasks AMAZING to use during a sprint, but VERY VERY hard to report on.  I'm not sure why JIRA makes it so hard!!  

Our team switched from Story Points to Time Estimation so that sub-tasks would burn down.

As you can see, the burn down chart DOES works with sub-tasks (it's the only report that does):

SS 2016-08-08 at 6.15.17 PM.png

Notice it says, "112h" at the top of the burn down.

Then, if you switch the Velocity Chart, it says the total Committed was only 3d 5h??

SS 2016-08-08 at 6.14.45 PM.png

When Sprint planning, the Workload report DOES NOT include sub-tasks, even though I'm telling JIRA to:

SS 2016-08-08 at 6.20.53 PM.png

Is there some magic setting in JIRA to just make all reports work with sub-tasks? 
We really like sub-tasks because they stay attached to the story as you move the story around.
We have thought about changing to just using TASKS and linking to stories.... This would fix the reports, but then actually keeping track of all those tasks would be impossible.

 How do other people do this?  This seems so broken to me!  Has anyone fixed this?

[Deleted user]

It is broken.

[Patrik Klinger]

I would also like to understand how I can have sub-tasks included in all of my reports.

Currently it seems that no reports will include data located in sub entitites such as stories in an Epic or sub-tasks in a Story.

This of course results in a reporting machinery that is next to unusable by me and my organization.

We have rough estimates in Stories while they are in the backlog and once they are handled on a sprint palnning meeting and brooken down into sub-task (with sub-tasks given an estimate) the top story is ZEROED out.

[Hitesh.Kumar]

@Miki Yuzawa - Sorry to inform but even now this is clearly not possible in the current JIRA and I could not find any reference that JIRA is working on improving on this feature 

view-and-understand-the-sprint-report 

[Danut M _StonikByte_]

Hi @Miki Yuzawa ,

In the latest version of our Great Gadgets plugin, the sprint and release burndown gadgets have an option to include sub-tasks, which you could use to achieve what you want (not as a report but as a chart).  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.

[sbbv2]

I suggest using regular issues only and then using "Link" -> "depends on" to Link tasks to their subtasks. However, then you cannot put them into an order or see the total cost of all subtasks easily...

[Andrew Hinkens]

This is very frustrating. Atlassian needs to offer true customizability rather than forcing users to adhere to their processes.