You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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)
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:
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.
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.