How can I use Subtask hour estimates in the Burndown Report??

[VoltaireO]

Hi All,

I apologize in advance, if this is a question that keeps getting asked. I have researched and see this has been asked, but in earlier versions of JIRA, so hopefully it is resolved in the newest version. 

My company uses three levels: Epic, User Story, Subtasks. 
At the User Story level, we use Story Points. In our case, they are not directly related to hours. The Story Points are a relative measure of Complexity and Effort.

Then below the User Story, the team creates Subtasks under each User Story. These are the tasks that need to be completed for a User Story to be done. And these tasks are estimated by number of hours to complete.

I am looking for a Burndown report that has the total, combined number of hours of subtasks on the Y axis and the days of the Sprint on the X axis.

Team Foundation Server had this feature and it was EXTREMELY helpful.  

Thank you in advance for any suggestions/assistance!

[Paul Berryman]

This function and logic is in place in ALL other major Agile project management software.   Teams update Tasks beneath the Story and EXPECT to see a DAILY BURNDOWN of effort/remaining estimates against original estimates.  THAT is what a Spring Burndown chart is!   Atlassian may not redefine the report for their own convenience.  

If they did NOT offer the Time Tracking option, that might be different, but since they DO it is clear that the TIME logged must be used for Burndown reporting.

This is similar to the Cumulative Flow Diagram only showing Number of Stories.   That is not granular enough for Scrum.   Story Points should be an option on that (posted separately).

When Time Tracking is set Remaining Estimate and Time Spent, the Sprint Burndown chart must show a daily summary of Remaining Time against the Original Estimate ideal burndown line.   Plain and simple.

[Deleted user]

I echo Paul's sentiment. I'm going to add this to the Jira Team's backlog to be addressed ASAP hopefully.

[Ryan Finco]

Some people on here are discussing "hours" for the sprint burndown -- I would offer that in sprint, the burndown is really an assessment tool for the team to see how they are progressing toward their goal - regardless of hours.    With that said, you could also just count the number of subtasks - treating all subtasks as essentially a "1" (the team then needs to realize that subtasks shouldn't ever be longer than 1 day, and if they are - they should be broken down further).

This would mean that the math that JIRA would do would simply be count the number of subtasks needed to be completed for the period of the sprint, and burn down on that.   this works very well, doesn't violate any of the principles of agile AND gives the team the immediate indicator of change.  

Jira can't do this either natively - but scriptrunner can.    You can do this natively in VisualStudio by simply putting a "1" on every subtask. (Visual studio can burn down by subtask hours as well) 

I suggest if you want to burn down subtasks by hours that you use   1/4 day, 1/2 day, full day (2,4,8 for example) as then people aren't trying to determine if it's 2 hours or 3 hours - it makes things go much faster.

[scott.fawcett]

Sub-tasks aren't all the same size, so tracking the Work Remaining is important.  As a new user to Jira (10+ years with TFS) I have to ask myself of Atlassian even uses their own product.  There is so much missing in order to effectively manage a scrum project.

[msp]

Agree 100% with all the folks who are struggling with this issue.  The only fallback is resorting to excel to manage the chart.  I feel that the scrum team not having access to this information dead right center is one of the main reasons Agile never seems "Agile" and folks struggle with adoption and fail.  @Paul Berryman stated it very well.  Other tools offer this and coming from those environments I am having a tough time understanding how Jira is really an agile tool which adheres to their version of what it should be.

[Erik Thomas]

Why can't JIRA just let people use the tool the way they want to and stop trying to enforce some academic's idea of how a burn-down chart should work.

Good software is software that adapts to how customers want it to work. It would be easy enough to allow a configuration in the burn-down chart widget to let us choose which field to use to calculate remaining work? It could be set to Story Points, or Story Original Estimate, or Subtask Estimates. 

That would solve every problem I see presented and argued in this thread. 

Shame on JIRA for not listening to such a large percentage of their customers and instead forcing their view of how Agile should work. 

I have a spreadsheet solution that's the stupidist workaround ever but it does what I need so I can see if a user is on-track or not to complete all their work in a sprint, and we as an Agile team chose to use subtask hours. 

At one time Agile was considered a self-directing concept, where teams decide these things, not some draconian software company.

We're an inch from dropping JIRA altogether. It's just stupid.

[Cagkan Urkmez]

still open :) and still needed :D

[Deleted user]

I am a plus one on this issue. I was an early power user of Jira. Spent many years working in TFS/VSTS. Intent of burndown has always been for view of progress and discussion if the team was on track for their goals. 

This change in Jira is a huge miss. Why muck with it? Allow the sprint burndown to work with hours remaining, just as it did before and other systems support. 

This is what we want and have always practiced.

[Nic Brough -Adaptavist-]

Sprints burn down when stories you commit to are done.  Not when bits of them are done. 

There's a load of stuff above (and in other conversations) that covers that, as well as explaining that Atlassian have taken the easy route of doing burn down properly by ignoring sub-tasks.

[Ryan Finco]

They did it wrong.  Sprints do not burndown by story - projects do.   Atlassian did it wrong.

[Nic Brough -Adaptavist-]

No, they didn't.

A project is a collection of Stories (and often other stuff) that needs doing for some reason.  There's usually a good logical reason to group them into a project. 

A Sprint is a time-box, where a team of people commit to completing some Stories.  Often these are drawn from one project, but often, they're drawn from many.

Sprints absolutely burn down by story.  They have to so you can measure velocity properly.

Projects also burn down by story, but that's relative to the project, and is not that useful for trying to predict outcomes (and useless for velocity because you can't correct as you go).  Many projects can burn down by story too.  It's useful to know sometimes, but it's a different thing to a Sprint burn down.  Atlassian haven't built for project or project-set burn down.  Not sure why, but I get the sense that they expect us to use other reports to get a better idea of how projects or sets of them are going.

[Ryan Finco]

Sprints don't measure velocity.  Velocity is the result of several sprints total effort - also called an "increment".  Velocity of a sprint is a single datapoint and isn't assessed mid sprint.   Sub tasks are to do items that make up a user story.  Knowing the progress of a user story is 100% useful.   The work of a sprint is subtasks to achieve the greater story.  Knowing how subtasks are progressing is critical to rapidly working with the team on potential impediments.   Not having insight into the progress of a " 8" point story or knowing where a 8 point story may have massively increased in effort and needs to be re-assessed and or broken into multiple stories to be refined for future sprints - not having insight into that is foolish.  

You and I won't agree on this one.  yes, Atlassian got it wrong and visual studio got it right.

[Nic Brough -Adaptavist-]

Wow, that's gone so far through missing the point, it almost makes sense.  But let's go back to the actual point.

I have a story.  I estimate X.  I say I'm going to do it.  Burn down measures completion, which is completely binary.  The sub-tasks are an irrelevance, as they're either all complete (so the story is), or they're not (so the story isn't)

Knowing the progress of a story is useful in other places, and Atlassian ignore that.  But there is no partial in burn-down.

[Deleted user]

I an new to Atlassian forums but not new to Agile. 

"Sprints burn down when stories you commit to are done.  Not when bits of them are done." - I would have to disagree. I think many other do too:

"The Sprint Burndown Chart makes the work of the Team visible. "

https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/sprint-backlog

"A sprint burndown chart shows only one thing: How much work remains."

https://www.mountaingoatsoftware.com/blog/sprint-backlog-sums-all-work-remaining

"The Sprint Burndown Report shows the progress within the Sprint toward reaching the Sprint Goal."

https://www.scrum-institute.org/Sprint_Burndown_Reports.php

"Scrum does not mandate a burndown chart to monitor progress. Scrum requires only that:

• Remaining work for a Sprint is summed and known on a daily basis.
• Trending toward completing the work of the Sprint is maintained throughout the Sprint."

https://www.infoq.com/news/2011/07/UpdatedScrumGuide

Summary is burn downs are for progress and work remaining. You say "completed stories" but have visibility into many tasks that are being worked on and impact as well as ability base on time remaining is essential and is best when having insight to the sum of the parts. 

For many of us the hours don't matter. It opens up the discussion to the team that there is still work remaining and what it will take to get it done (swarming, more people on more tasks in that story) or not.

There is a whole other discussion when you try to cut story so small to track based on story points, business value simply gets lost. Or lack of progress displaying as stories showing no movement for days in the sprint because they are waiting to complete.

I'm not saying this is the only route, but make it an option.

[scott.fawcett]

Nic is entirely wrong.  Stories, estimated in days, is far to high-level of an estimate to review the status of a sprint and react accordingly.  If most of your story estimates are 2-4 days long (and many are longer) I'd HATE to wait until day 4 to find out you have sub-tasks that are not on track.  If you use 2-week sprints, and plan to adjust after 4 days, you have NO chance of meeting your sprint goals.

Tasks are in hours and the sprint burndown should track according to tasks.  Again, using the 4 day story example, it could (and should) have multiple 2, 4, 8-hour tasks.  Since your'e probably reviewing the sprint burndown daily wouldn't you want to know that story is "burning' down rather than waiting until day 4??

[Nic Brough -Adaptavist-]

Mmm, I'm afraid I'm not wrong.  You just haven't understood what I've said.

[scott.fawcett]

Your comment below is another example:

"But you can't burn-down until something you committed to (the story) is done.  Visual Studio is not useful for Scrum because it's wrong.  Jira avoids the question."

I can't imagine tracking a project at the story level.  You can definitely burndown a story as it's being worked on.  That is NOT the same as counting it Done, which is how your velocity is tracked.  Velocity is only tracked based on Done stories.

Let's take a more real-life example.  You want to build a house.  Your builder says it will be done in 6 months.  For you, you'd be happy having the builder come back in 6 months and tell you if he's on track to be complete on time.  After all, he can't "burn down" his work at the task level and provide updates prior to that...correct?  Good luck with that.  For me, I'd rather see a plan that shows when the ground work will be done, when the slab will be poured, when the frame will be complete, when the roof will be done, when the windows will be installed, etc.  Each of those is a sub-task that can be tracked independently in a sprint.  So, when the frame is not complete on schedule I can ask "what are you doing to get back on schedule" 3 months before he's scheduled to be done.  But, the builder doesn't get paid until the entire house is Done.  That's when he gets credit for completion.  When the story is done.  His velocity is 1 house every 6 months.  Nobody cares how many windows he installs in 6 months, how many roofs he completes, etc.

[Deleted user]

@ScottI thought I should update where I am on all this since Nov.

We have been able to successfully leverage Story Points on User Stories and hours on Subtasks within the latest version of Jira. It took some fumbling around with Jira settings but it's there and available. 

Here's the workflow:

- Stories are estimated and pointed as expected within Jira. This is occurring during backlog grooming and sprint planning.

- In sprint planning sub-tasks are being created for each story.

- When developers pick up subtasks (at end of grooming or in sprint) they are putting in original hour estimates.

- daily (preferably outside of stand up) they are using time tracking and updating time remaining.

From here was can look at the Burn Down Chart while we are in the sprint. Once Jira is configured correctly you can change the view to look at Remaining Time Estimate.

It's providing a heart beat of the work in progress. If we see and uptick in hours remaining we know that some new information came in (new task that was not expected or task was harder then expected). This helps inform a conversation while we are in the sprint. Something changed, do we need to review acceptance criteria? do we need to swarm on a story that to provide more help to get completed? 

Note that you can also view the  Burn Down Chart with Story Points as well. 

[Ryan Finco]

make sure that you are having strong discussions in planning regarding subtasks - estimating them in isolation without a discussion or validation of assumption can be dangerous when you have multiple developers.  If a developer, without talking to the team puts a "6" on a task, but didn't talk to the team - what if another team member knows more about that, or knows a better faster way to do something - what if it's not a "6" but really only a 10 min tweak?      

As I've said before, the relative agreed upon value is what I seek on teams.   

With all that said - I do see how this could work, acting more like a "burn up" - regardless of how it behaves you said the key words "heartbeat".   that's exactly it - it's a granular indicator of health, specific to the current moment, the immediate sprint.   

Oh, FYI - if you go to a conference or anything like that watch out for calling it "Grooming" -- the various powers that be have moved away from that due to what the slang "grooming" means.   The new word for it is "refinement".    As far as I'm concerned you can call it whatever you want as long as people know what you mean.

[Deleted user]

I've always kept the sub-tasking light. Specifically, they should be clear about what each one is for - but the estimate is based on who is working it. And it should really just be, "when do you think you will complete it". Example, if after 3 days with the developer working on on the story and hours remaining is say 8 day after day. That should prompt a conversation with the team to understand if someone from team can help, or perhaps there's confusion above and beyond acceptance criteria that was never raised up.

Bottom line that "heartbeat" should no incur operational overhead, if it does - you're doing it wrong.

right, "grooming" replaced with "refinement" :)

[Ryan Finco]

nailed it on all points!   I've found a little rigor is useful - it's critical to reduce the "on-going re estimation"  i.e.  oh that will take till lunch....next day same task - oh, probably till lunch....next day same task....I should have that shortly, 2 hours or so.... and so on.    in this scenario the first throw was a "4" - it's up to a 20+ now.  It's highly probable this could have been avoided had the team talked about this as a team.  dragging it out could be mitigated by the team immediately seeing that something is not what was expected and swarming, or re-evaluating etc.  

I've found this is something that newer developers are prone to, or developers that lose focus for whatever reason through the day and get sidetracked (be it their doing or another person asking them for help or things outside of the sprint, etc) 

I do avoid "capacity planning" like the plague - I've found teams can get caught up in "meeting the number"and then second-guessing themselves of why the capacity values don't match up to previous sprints, etc.  (I had one team that got really wrapped up in the offset of capacity vs story points, i.e. "we had a story that was a 5 that took 41 hours, but this one is a 7 yet it took 34 hours", they had to learn to let that go, and they did once they realized it wasn't really important.  

[Alina Fecheta]

Hello,

In your Burndown chart you can change the estimation to "Original Estimate". JIRA automatically sums the extimates/logged time from the children to the parent.

[Caroline]

Hi - I'm having the same issue and have tried the above,  Still doesn't work.  I'm not sure what else to try

[Iva]

Jira does not automatically subtract the logged time from the child to the parent on the Burndown chart. It continues to use the 'Remaining Estimate' field, which is not the same as the 'Remaining Sum' field (which contains the subtraction from children). 

[Nic Brough -Adaptavist-]

Don't put estimates on sub-tasks, it does not make sense and Jira ignores them.

[agrigul]

And this is a bug.  The key point of correct and accurate estimation is split of the big story onto smaller tasks:

Story: Do login
sub-task 1: add UI (2 inputs for login and password and login button. Estimated - 3h
sub-task 2: add backend (authentication checks) - Estimated - 5h

sub-task 3: ask DBA for new tables. - Estimated - 2h

Total estimation of story is sum of sub-tasks: 3+5+2 = 1 day and 2 hours.
The same with logged time. 
And that's it.

If you don't split then you may have wrong estimation like 5 hours.

[Nic Brough -Adaptavist-]

Bug: When software does not behave as designed or intended.

So this is not a bug, Jira is doing it as designed.

Sprint estimates do not go on sub-tasks in Jira (If you do want to do it, you will need to implement a summing scheme, and unless you implement a scrum-aware one, you'll just make it a mess)

[Danut M _StonikByte_]

Hi @VoltaireO & all,

Try our Great Gadgets app. It includes sprint / release burndown chart gadgets that can also calculate by time remaining  & time spent. Also, it offers an option to include subtasks. 

For more details, please read this blog post.

Don't hesitate to contact support@stonikbyte.com if you have any questions. 

Danut 

[Dang Thi Thuy Tien]

Hi, 
You can try with Hierarchical Calculation Field (https://marketplace.atlassian.com/apps/1219833/hierarchical-calculation-field)

Cheers,

[Andy Johnson]

I've given up trying to wrestle with timing and estimation using subtasks as JIRA does a horrible job above the Story level - unlike VSO/TFS and other Agile PM tools.

Our team has pivoted this sprint to estimating entirely using Story Points at the Story level, and are no longer putting any time tracking (estimates and/or actual time spent) at the subtask level anymore.

It's a massive shame that Atlassian has ignored issues with subtasks, that so many have had problems, but for the sake of trying to use JIRA in some way that works they've won.

Oh .. if you do change your workflow to use Story Points, I found today that Tasks cannot have Story Points assigned to them.  So that's a thing also.   :(

[Ryan Finco]

Andy - As I had mentioned, if it's something you really want to have access to - you could do a excel sheet, there would be prep work at the beginning of the sprint, but once that is done a simple daily update could give some transparency.    This would be fairly low effort, even lower if you treat all the subtasks as a "1"     Also, I do know that you can do a "all subtasks = 1" burndown in JIRA if you use the Scriptrunner plug in.     I have the link to how to write it if you need it.    basically it just counts the number of subtasks and burns that down over the course of however long the sprint is.    it's far more accurate and useful than the native JIRA burndown.    

[scott.fawcett]

Which assumes all tasks are the same size?  Frightening and results in a hugely inaccurate burndown. I realize you're just providing a workaround, but even that just goes to show how it's fundamentally missed functionality.

[Ryan Finco]

It really doesn't at all.    I live by the rule that subtasks cannot be more than 1 day, i.e. 8 hours.   I've had multiple teams do this successfully for years (30 - 70 sprints).   Now, I generally don't advocate STARTING a team with this, it's something to grow into as a team becomes high functioning.  

You absolutely can assume all tasks are the same size PROVIDED!!! that you have good refinement and discuss tasks as a team and know what is expected by everyone involved.  it also means you do things like "walk the board" in standups, and in general team members are very aware of each other's work.     

The only reason why I don't start teams with this idea is because I want the discussion that comes from considering what a task will take.   for that i use  2,4,8 (or quarter day, half day, full day as I'll talk about it)  The hours on subtasks don't matter in relation to the stories.    Once a team is in the habit of discussing subtasks - then the effort alligned to those subtasks doesn't matter.

One thing that i don't like is when subtasks become things like "dev"  with no detail - I want subtasks to have some descriptive quality as it's important to see where things are "stuck" as well as when multiple developers want to work on the same story.  

I don't draw any parallel from subtask hours to story points.   reason being, story points are relative and their accuracy is independent of any hours or values that are put on subtasks.  This is key.  It's key because the abstract value component means accuracy isn't derived from subtask which makes the hours on subtasks only for in-sprint management.   In fact, if you think about it - making story points "more accurate" really means your forecast is LESS accurate because you tampered with the abstraction.    A team that does a "54" in a sprint, may have the exact same work that a team that does a "17" in a sprint.   the number doesn't matter, what matters is the dynamic between the number over time in realtion to the amount of work.     If you make your estimations "More accurate" you create the possibility of changing your velocity VALUE (not the amount of work actually done) - if you change the value, you no longer know what your velocity is and will need to re-baseline.   

[Ryan Finco]

Subtasks aren't the sum of user stories.  Subtasks are the "to do" list of the user story.  You don't add up your to do tasks and determine if something is done on the basis of their sum.

Also if you are adding up subtasks and you want to get to an epic level via subtasks, I would say you are forecasting using the wrong information.

[Andy Johnson]

Not for forecasting but tracking time spent, JIRA has the option in the Epic Burndown to track via Original Time Estimate - does this not total from subtasks?

If not then does this field pull from the Story, and if it does why do Subtasks not total into a Story and then the Epic Burndown pull that from the Story.

Implementation of subtasks in JIRA seems flawed in many ways from a function PoV, or maybe it's JIRA being overly rigid over the intended (required) use of.

It's annoying and I'm not the only person having issues with this.

[Ryan Finco]

Jira is built from a hour tracking perspective and they then added over time some agile tools.  these things didn't necessarily align.     but with that said, subtasks have little to do with Epics.  and subtasks in hours doesn't "equal" stories in story points - this isn't how team-relative estimation works.

I guess I'm asking why the cascade matters.   Why does tracking hours at a subtask level matter here?   The team estimates their stories in story points which are a relative value to that specific team, and after a few sprints establishes a velocity.   You forecast based on velocity with is a specific empiric value that is relative to the team.   Again, why do hours matter at a subtask level if it's really about the work being delivered, and the project-level forecast?   I have had great success with using a subtask hour be simply a progress indicator for the team, and that value is essentially relative as well - as I mentioned, you could treat all subtasks as a "1" and still get the progress indication in-sprint.   Subtask estimation shouldn't be used in reporting, it's a tool for the team.

Subtasks are seldom the entirety of the story.   As I've mentioned before, subtasks really are the "to do" list for the team.    Think of this example.   If you know this weekend you need to "paint the garage", you will put together a to do list.   get dropcloths, buy paint, warn family, etc.    if you add up all those "to do" do they equal the garage being painted?    I would say 99% of the time they do not.  They're in essence starter notes for the tasks ahead.     Subtasks are for the team, not for management.   

Now, if you aren't using an agile methodologies/frameworks, or are billing hourly I can see the need for hours, but hours as a tracking function within agility and user stories as an agile requirement methodology don't really mesh.    A subtask hour roll up doesn't really matter in agile, so what is the problem you are trying to solve?  perhaps there is a different way to solve it?  

[Deleted user]

If you refer to the thread, you'll see why this is needed. Look at my post from LAST May above - May 17, 2018. It amazes me that this functionality is not available - it's a simple ask to tie hours to Sprint Burn-Down - which is an option to choose. But the chart is worthless because the hours entered in subtasks don't roll up. Just make this work PLEASE.

[Ryan Finco]

many of the charts have less value than they should because of things like this.     As I said, when I am working in Jira and not Azure Dev Ops (I work with both depending on clients)  - I do it myself using excel.   

[Andy Johnson]

Ryan - Looking at your comments you said:

Have you solved this problem / how did you manage the work-around / what have you done differently to change your mind?

[Ryan Finco]

I have not solved this problem.  Jira is not my favorite tool for Agile, so nothing has really changed my mind.  With that said, I understand that it's a choice some companies make and since I work with multiple companies I need to be comfortable working in multiple systems.  Azure Dev Ops is probably my favorite when thinking on a "team" level - i.e. day-to-day in the work.   I know Azure Dev Ops at one time (when it was TFS) did not do reporting that well for a program level perspective - i.e. SAFe for example - TFS reporting capabilities were minimal.   JIRA on the other hand has some really good management level reporting capabilities, but working day-to-day with it is painful.     It seems to come down to who the tool was made for.    Azure Dev Ops was made for developers and project managers and it shows in how it works on a sprint and feature level.    Jira seems to have it's roots in more of an "Oversight" capacity and it shows in it's powerful reporting and flexibility at the cost of daily usability and sprint level team needs.

When other POs and SMs that I work with need to use JIRA many of them opt to just do physical boards and then essentially enter information retroactively into JIRA - making their dynamic day-to-day operations driven from a different tool or tools.  

Now to get back on track,  I never solved the close the sprint / reopen the sprint problem.  I don't think it can be solved by native JIRA.  it might be able to be solved using scriptrunner.   This problem isn't a problem in Azure Dev Ops because azure dev ops doesn't burn sprints down by user story - it uses subtask estimates.  In turn, you can add to a sprint, and it adjusts gracefully.     For example, in the last sprint I was just in, after getting half way into a story, suddenly way more tasks were needed, we needed to re-estimate and even determine if it's something we could still do.   This happens.   Azure Dev Ops rolled with our changes with 0 issue.  Our burndown spiked (as it should because we increased the amount of work) and we kept working - the tool never got in the way.

Azure Dev Ops reminds me a bit of apple.   The design is quite good, but it isn't very flexible.  "this is what you get - most like it, but if you don't too bad"  JIRA reminds me of Android - it's powerful, but in order to that that flexibility it's design language is limited, and it's UX can't truely be catered.   "You can have this do almost anything, but this flexibility comes at a price, and because of this flexibility many things have to be manually done."     Both tools require some level of administration but Azure Dev Ops is way easier to distribute responsibility.     In fact, enough people complained about JIRAs massive need for a heavy-handed administrator that Jira "next gen" projects were created which give teams a much larger amount of flexibility in how they work.   Think about that.  JIRA became so difficult to work with that they had to release a stripped down version to people, who's feature set is that it has less features.

[Andy Johnson]

Thanks Ryan, this helps.

On your Stories increasing in size/not completing in sprint issue, we do the following work-around:

1. Clone the Story without cloning subtasks
2. Rename the cloned Story, usually updating to new(er) title or adding next Sprint/continuation to the title
3. Move the cloned Story to the next sprint
4. Move the subtasks that won't make that the current sprint out to the cloned Story, that's on next sprint

This allows us to close out a Story and keep that work in the sprint rather than having to move the entire Story out of the sprint.  The Stories are linked, so have a relationship if you need to dig back into completed work later down the line.

I also worked on Visual Studio Online prior to this (latest) JIRA experience, and JIRA is really rigid lacking the customizability of VSO from a project/daily management PoV.  I do agree with you on the reporting functionality difference between the two.

We'll keep trying to work through how to make best use of Story <-> Subtasks.

All the best!

[scott.fawcett]

Agree with Ryan's comment that this issue is entirely built into the scrum template in TFS out of the box.

Subtasks are not the sum of the user stories, but one level lower in granularity, providing more iterative and faster feedback.  Stories also may have been estimated some time ago, so estimating the various tasks to complete the story provides an opportunity to "re-estimate" the story (for sprint planning) with new information you may have discovered...and as such your sprint planning is significantly more accurate.  I would hate to have to believe story estimates that were completed long ago and track whether the sprint was on track based on that info.  It could be horribly inaccurate.  And, if not, you spent way too much time doing your story estimating when you had the least amount of information available (because your team learns more every day moving forward).

Stories use story points (or days).  Tasks use hours for sprint planing.  Track against your tasks, as they're the most granular and accurate estimates.

[Deleted user]

I've given up on this thread. Since no one from the Jira Product Team wants to state their plans for supporting this, I'm assuming it's a dead issue and won't waste anymore time convincing them to support this - even though it's absolutely foundational to holding teams to estimates and the ask to include this is small. Why allow the burn-down charts to support a time metric vs. story point if you aren't going to support summing up the hours allocated to a US across teams. The feature is worthless as implemented from a 'real-world' scenario.

[Csaba Schwarczinger]

"JIRA automatically sums the extimates/logged time from the children to the parent."

It's not true, it counts just the parent items, but we have hour estimates just the subtasks, so it's still a problem.

[Nic Brough -Adaptavist-]

Yes, it absolutely does sum them up.  You can click on the button to toggle the parent's view between "this issue" and "this issue and sum of all sub-tasks" in the main issue view.

However, that is only done in the issue display, and in the issue navigator when you use the "sigma" fields to display the sums.

Jira Software however, is written to look at estimates on stories, not their sub-tasks.  So you should not expect to estimate and burn-down on sub-tasks.

[Amy Saxton]

>So you should not expect to estimate and burn-down on sub-tasks.

Then what's the point of having estimates on subtasks at all?  Story sizing is an overall representation of the mass of the work that's being tasked out, not a measure of the weight of each task.   We don't burndown stories, we burndown tasks.  I think the general consensus among the community over the last several year is that the burndown chart is useless for the majority of users. 

[Nic Brough -Adaptavist-]

That is the point - you should not be estimating on sub-tasks.  Burndown is supposed to be done on stories, when the whole item is delivered, not bits of it  That's part of the reason Atlassian have never implemented anything for sub-tasks.

[Jeremy Upright]

Nic - If subtasks estimates roll up to the parent to provide an estimate of 40 hours, why would the burndown chart not burndown the total number of logged hours as those hours are also rolled up to the parent?

In theory, I understand your previous message, but not sure I understand the logic.

[Nic Brough -Adaptavist-]

There's probably a long essay here, and, for what it's worth, I think Atlassian have made a bit of a mess of this one, although it's an "evolved" thing rather than a "we chose to mess it up" thing.

Jira, before "Software" arrived, tracked time.  The time logged on sub-tasks rolled up to the parent and you could (and still can) toggle that display between "all" and "just the parent".

Agile does not work that way.  You commit to doing a story in a sprint, based partly on the estimate for it.  You can break it up as much as you like, but the work done flag is binary - either you succeeded in completing it or you did not.  The various fragments you might have split it up into are irrelevant, what matters is whether what you committed to is done.

This is why they don't appear to work in Scrum, and why Atlassian don't use them in the boards.  Sub-tasks don't matter for estimates.

[Deleted user]

This needs to be fixed PERIOD and SOON. Or have it as an option. Enterprise teams do not estimate hours across teams at one story (i.e. US), I have QA, Dev, Automation Testing, Integration teams. Each team estimates their portion of the US in subtasks. The estimate of each team is what they are held to. The fact that subtasks do not roll up to total US hours makes no sense. Jira's competitors do this - look at Microsoft VSTS for example.

[Nic Brough -Adaptavist-]

If you want a fix, you'll need to come up with a strategy that meets all the different ways of adding up the hours without breaking the basic "deliver or do not, there is no 'try'" principle of Scrum.

[Deleted user]

Nic: I'm not sure you understand me. This is not a ? of DOD or any of that Scrum mantra. Trust me, I understand what you are saying.

The issue is that multiple tasks (i.e. subtasks) are needed to complete a US across teams. The DOD for US is when all teams work is complete. So if you don't have teams aligned using subtasks - you need to link US to track when the work across teams is complete. Linking does not work because QA does not complete their effort until Dev says is ready to be tested. If you don't group the various team members tasks to a US, managing QA and DEvOps workstreams to a US is a nightmare. Look here for how it's done in VSTS - https://docs.microsoft.com/en-us/vsts/work/scrum/task-board?view=vsts.

I appreciate Jira for it's simplicity and adoption but fail to see why this request is not core to the product. It makes no sense when dealing with a US tied to multiple teams. Is Jira's design saying to flow QA testing into a separate US LINKED to another set of US that has one task assigned to it. That seems to me more work than simply giving an option to sum up subtasks. 

[Nic Brough -Adaptavist-]

I don't think you've understood what I've said.

Please explain how to code for all the various estimating on sub-task strategies that the Jira user base might use, and how partially done estimates work with the flat "done or not".  Once you can do that, someone can write it.

VSTS adopts one strategy and fails scrum principles immediately.  Jira just dodges the question by ignoring it.

[Deleted user]

Nic: All I'm asking for is the following assuming using Jira:

- How do I track total hours to complete one US with multiple teams involved in the US. We don't mark a US complete until all tasks(Subtasks as I understand it in Jira) are complete. The burndown chart now does not recognize hours from subtasks supposedly. If so - is the process to let each team member enter the hours at the subtask level and have a scrum master sum the hours at the parent US to make the hours in the burndown work?

- What is the use of subtasks if you don't track hours to a team member. It appears to not provide ownership of hours estimate to the granular level of a subtask that is assigned to one team

Tell me how to use the tool as designed to accomplish the use case. My team can't find links that explain it.

Whether VSTS breaks scrum is open for debate - it depends on how you define the workflow for US DOD. We use both currently and are moving to Jira. I just need my team to understand how to use the tool for what is noted. As you can tell from this thread, I'm not alone in questioning the use case. I appreciate your involvement in the community.

[Nic Brough -Adaptavist-]

If you want to estimate and do scrum on hours, put them on the story.  It won't work on sub-tasks because it's not built to.

A better approach would be to estimate and burn down on story points on the stories, then put time logs on the sub-tasks (and estimates if you find them useful).

[Paul Berryman]

This function and logic is in place in ALL other major Agile project management software.   Teams update Tasks beneath the Story and EXPECT to see a DAILY BURNDOWN of effort/remaining estimates against original estimates.  THAT is what a Spring Burndown chart is!   Atlassian may not redefine the report for their own convenience.  

If they did NOT offer the Time Tracking option, that might be different, but since they DO it is clear that the TIME logged must be used for Burndown reporting.

This is similar to the Cumulative Flow Diagram only showing Number of Stories.   That is not granular enough for Scrum.   Story Points should be an option on that (posted separately).

When Time Tracking is set Remaining Estimate and Time Spent, the Sprint Burndown chart must show a daily summary of Remaining Time against the Original Estimate ideal burndown line.   Plain and simple.

[Ryan Finco]

This in JIRA is absolutely wrong.   It's mixed up the idea of what each "measure" is for.  Sub tasks in hours, even if just done in a  1/4, 1/2, full day concept allows for Scrum Masters and the team to quickly make assessments and to shift if need be, determine when to swarm on things, etc.   This same thing allows for the team to see when they've run into a problem and they are no longer on track to achieve what they wish to in the sprint.  This is one more tool that the team can use to communicate.

This isn't for "reporting" it's for the team to assess themselves on a daily basis if need be.  Story points determine different things as user stories and subtasks are indeed, different things.  For teams to truely be self governing they need to have some sort of indicator of where they are in their sprint that they all can agree upon as a basis of understanding.    

Burning down on the user story level isn't useful to a team on a daily basis, where the work actually gets done specific to the goal.    User story burndown also isn't granular enough to adapt quickly.   halfway through a "5" - if the team is stuck, it's important to know this, and subtask burndowns are an excellent indicator of things like this.  

So right now, for example I have a "13" and a "8" and a "5" across multiple developers - so instead of a burndown, I have a "block" that won't reduce itself until one of these is complete.   that is worthless to the team in sprint.   

Again, this isn't about reporting - it's about indication - being able to empirically see something and do something about it accordingly.  

As mentioned - Other tools do this, and do this very well (VisualStudio does an excellent job at some things, others not so much).   why can't Jira?

[Nic Brough -Adaptavist-]

But you can't burn-down until something you committed to (the story) is done.  Visual Studio is not useful for Scrum because it's wrong.  Jira avoids the question.

[Ryan Finco]

Normally I side with you Nic, in fact I've told peers and clients that "If Nic says it, it's probably true" but I've been working with Agile for a long time now as a coach, a SM, a PO - etc, at various clients - many of whom use Jira.   I've found that Visual Studio works better "in the trenches" on the day to day, but program level reporting out of it is painful.   While, Jira has incredibly good reporting on a portfolio and program level it's working day-to-day is painful, and it needs to do some things that are really well done in Visualstudio.      

The SPRINT burndown as is in JIRA isn't useful as is.  A burndown on a project level makes sense based on story points, velocity, etc.   but the subtasks - the pieces that a team uses to complete user stories, there needs to be some indicator of the movement to the goal.   the burndown in JIRA isn't a burndown, it's "stepped" and in turn misses the key component of a burndown, and that is the ability to rapidly respond as needed (if a team has a velocity of 24 - thinking that an "8" doesn't affect a burndown till it is a "0", is just not operable.)  As I mentioned a burndown, software, etc is only 1 of numerous tools teams can use.   The purist in me says throw it away and do a physical board, but sometimes that's not possible.  

I think part of the issue is what I use the burndown for - which isn't "reporting" - it's an empiric indicator.   honestly it doesn't have to be "hours" - it can be story points, it can be planets, etc.   If the team discusses a subtask and it's a "pluto" and yet it's in work for days - a burndown will show that it needs to be re-examined and see if there are impediments, and shows it fairly quickly.   It's also a great way to convince the various powers that be how empiric Scrum can be - i.e. it has the same information that they want, but it just manifests in a different way.     I've had great success showing burndowns and how there are ways to see into something that seems often to people without form. 

I simply wanted to respond to this as I have a huge amount of respect for how much information you provide to the community, but at the same time I wanted to voice my general disdain with Jira at times.   It seems that Jira wants to be everything and in turn it is a bit mediocre in some areas - I've also seen JIRA used to really undo Agile because of it's flexibility.

Also - sidebar:  I'm really curious as to how you feel Visualstudio fails scrum principles - this isn't a challenge, I'm genuinely curious.   

[Daniel Roussel]

The scrum guide doesn't mentions burndowns last I checked. My teams would also like to have a burndown per done tasks and see if a task as been in progress for longer then originally planned. As Ryan mentions, it is a tool used by the team for its own planning and assessment. Whatever makes their work more efficient, and things more visible, is OK.

[Ryan Finco]

You can easily make one in excel or download one out there.    Because JIRA can't do even a subtask count burndown (all subtasks = "1" and burn down on subtask completion) I use a excel file that I made.   In this, for kicks,  I have 4 burn downs.    Burndown by user story points,  Burndown by subtask points,   burndown by subtask hourly progress, burndown by subtask count.     It shows very quickly to people why burning down on user story points is ineffective and why burning down by subtask hours or count is far more useful to the team to make rapid adjustments in-sprint.

The only point of estimating on subtasks is to have a relative size value AND to get the conversation going in Sprint Planning (if 1 team member thinks it will take some of their morning and another thinks it will take all day - the discrepancy is revealed and discussed), and as I mentioned you can even just treat them all as the same size.

I started with this one, and then made some changes.  For now, this works - but it does have to be maintained manually.   I miss Visual Studio....

   https://www.coria.com/en/insights/blog/project-management/HowToCreateABurndownChartInExcel 

[Andy Johnson]

2019 and still no fix on summing subtask completion up to the Epic Burndown level?   :(