Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Improve burndown chart incl sub-task

I am a Scrum Master & Jira administrator seeing a value in velocity measuring on Sub task level.
I propose to improve the burn down chart to be able to gain more learnings from the sprint.

Add a 'drop down list' in existing 'burn down chart report' covering the scenarios below:
1) Sub-task & Story Point
2) No of Sub tasks
3) Storys & Story Point
4) No of Storys
(5. Storys and T-shirt sizes)

All these gives valuable learnings to bring to the team on both individual level and team level, to get better on estimating time and improve predictability for sprint. This data is important especially in a newly created team with little knowledge in Scrum.

(Background: Hardware business: We are using Story to bring a value, Sub tasks to describe the work needed and each resource are estimating time in story point on sub-task level. We use T-shirt size on Story Level to get early estimates on velocity.

2 answers

1 vote

You've got a bit of a problem here, one which can be summarised as "your process is not Scrum".

Jira Software's scrum boards are built to support scrum, so they are not going to work for your process.  The main reason for this is that scrum does not have anything to say about non-sprint items, and sub-tasks in Jira are not sprint items, they are a fragment of their parent issue. 

A sprint estimate on a sub-task is an irrelevance, as it is already part of the parent, or at least should be.

If you are doing scrum, you do not put sprint estimates on sub-tasks, and you do not look at them to derive velocity.

There's another problem in your question when you say "individual velocity".  That is not what velocity is for, it is for the team.

So, the first thing to do is look at your process - if it works for you, then that's fine, but you're going to need to change it to fit with Scrum, or do some work in the Scrum tool to make it fit (if you want to estimate on sub-tasks, you're going to need to build something that takes account of them on the sprint items, and educate your not-quite-scrum teams on how to use it)

I can here you have not worked with the transition nor as a scrum master in change or not mature scrum teams.

I rest my case.

Recommendation is to start to listen in to scrum masters need instead of trying to educate. Big mistake. 

For your understanding. I am working in hardware business and scrum and agile work differs a lot from SW business. Learn the difference and you will understand why this is needed in Sub-task level. The challenges in HW development are completely different from SW development!

I have to agree with Nick. Jira reflects the default Agile framework methodology, which measures velocity at the team level, not the individual, and tracks story points (effort) at the story level, not the sub-task. The fact that Jira lets you also use story points at the sub-task or epic level is just a convenience for you, if you want it, for supplementary reporting.

If you really, really, really must track the efforts of the individual, I'd suggest you either:

  • Buy the add-ons that provide that functionality for you
  • Hire a couple of good Jira devs or technical BAs / Data Analysts who can build the custom functionality / external reports for you.

I'm also a scrum master, and I can tell you that every course I've been on, the original and all the refreshers, were very clear that sub-tasks (as implemented in Jira and most other scrum tools) are not sprint items.

I've worked in all sorts of places that try to do scrum-like patterns, ones well outside just software or hardware development.

That's exactly why I say "you're going to need to implement something that changes the way your scrum tool works, to adapt it to your not-quite-scrum processes".  

I think estimates on sub-tasks has a place, but as that's not scrum, you can't expect a scrum tool to handle it the way you want.  I am not saying you are doing anything wrong, beyond trying to wedge a Scrum tool into doing your not-quite-scrum process.  

I regularly set up people to work well with estimates on sub-tasks - the main trick is to have two fields - one for estimates on all your items and a calculated one that you then use for your sprint estimates.   This, of course, still means you can only apply velocity reporting to the team, as it is supposed to be, and it imposes some training on to your people, as they need to understand the impacts of adding or editing the estimates on issues in an active sprint in more detail, but it can make Jira work better for people who use sub-tasks.

Hello @Elvira_Edenlund 

If you Google 'jira burndown chart subtasks' you will see how many times that topic has been discussed before. The search results will also lead you to JSWSERVER-6007 which is the existing feature request for adding sub-tasks and their story points to burndown charts.

Feel free to add your vote to the feature request, but now that Jira Server is a discontinued product, it's probably a moot point.

Great, I have votes and watching the issue.

I have a propose a usability solution with drop down list on different scenarios to optimize the usage of the burn down chart during the team retrospective. I can't see this is included in the feature, so I hope you can take that on also. 

If you could add assignee velocity for a sprint that would be a great feature also i.e use filter in burndown chart.

Paid add-ons like Advanced Burndown Chart allow you to create custom charts that show story point burndown per sprint per person.

If you wanted the additional capability of being able to lookup story sub-tasks using JQL and using that as a filter for an advanced burndown chart, then I believe JQL Booster pack will add that functionality to JQL. Refer to this prior thread on that topic.


I understand paid add-ons might see like a good solution for Atlassian, but not manageable for me working at a huge company. This is basic scrum need to be able to monitor velocity on program and team level and if you can´t provide it as basic functionality in JIRA I guess we will start using other scrum IT tool which is in discussion for time being.   

But now I at least know that Atlassian will not provide this functionality due to use if paid add-ons strategy Atlassian have. Thanks for that knowledge. 

Pease, let me know if I have misinterpreted the situation.

Suggest an answer

Log in or Sign up to answer