Burndown Chart By Subtask Original Estimate

Joshua Krinsky_q9qtfk

We would like to configure our burndown chart to use the original estimate field for time estimates provided on the subtask level in a nextgen project. I am the project admin, but not a Jira admin. 

Anyone know how to do this in a NextGen project? I only see "Issue count" and "Story points" in the "Estimation Field" select list for the Burndown Chart in our project. We track our progress by creating subtasks with time estimates. Team members update the "Orginal Estimate" field with the time remaining as they progress through the subtasks. Subtasks that move to "Done" status should also have their original estimates automatically set to 0, but that part is a nice-to-have. It's imperative that we be able to see subtask original estimates as the Estimation field in our burndown chart.

Seeing a lot of arguments in other threads about the "right" way to track progress. I think people forget that Agile and Scrum are frameworks, and the "right" way to track progress is the way that works best for your team and business, imho, and this is the way that I've experienced provides the best realtime burndown. Oftentimes, stories won't close until near the end of a sprint, and the reality is that stories change in scope and may roll over as discovery and implementation progresses. Using story points or issues remaining does not reflect day-to-day activity or progress for our team.  

Please help!

Josh

Nic Brough -Adaptavist-

Your burndown chart will not reflect estimates on sub-tasks directly.

This is not about the "framework" or "right" way to track progress, it is about what Scrum is about and what sub-tasks are.

Think of a sprint - it's a timebox.  At the beginning, you commit to completing one or more stories (which have estimates on them).  At the end, you have burned down on what you completed, and not burned down on the incomplete items.

Sub-tasks are not sprint items you commit to, they are a part of the story.  Scrum has nothing to say about sub-tasks, they're not relevant.  If you want to break up your story to better manage elements of it, fine, use sub-tasks, but they're not committed to as anything other than as a part of their parent.   They count towards that committment/done, but indiviudally, they're irrelevant - the only burndown data a sub-task really holds is "we're not done, so by definition, our parent is incomplete" or "we're all done, so you are free to make our parent done".  There's no difference between 0% of your sub-task estimates being done, 10%, 50% through to 99% - the story (and hence burndown) is "not done".  When the sub-tasks are 100% done, then you can let the story become done (and a lot of people who use sub-tasks do have a "last sub-task done, parent is done" automation)

Now, there are loads of schemes that you could do putting estimates on sub-tasks and having them roll up (or not) on to their stories, but if Atlassian were to try to cater for them all, there's a lot of code and config to be supported.  They've chosen not to do this, kept it simple and Scrum compliant and simply don't do estimates on sub-tasks.

Even if you were to implement one of the schemes for rolling-up/down, you'll never see sub-task estimates on burndown as anything other than as a part of their parent.  Sub-tasks are a fragment of a story, not a sprint-able item in their own right.