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
Hello - I would like to add subtasks for the different components of a story, task or bug i.e Android, FE and BE. I then want to report on the amount of points delivered by each dev (against their subtask). what is the best way to report on this?
Hello @Andrea Smart
Welcome to the community.
Generally Story Points should not be assigned to sub-tasks. All the built in reporting concerning Story Points considers only the Story Points assigned to issues at the Story/Bug/Task level.
Technically you can add a Story Points field to Sub-tasks, and you could construct your own custom queries to gather that information. But the built in reports will not include that information and there will not be any automatic roll up of the sub-task Story Points to the parent issue.
Can you tell us more about the problem you are trying to solve with this strategy?
Hi @Trudy Claspill
Thanks for your response.
Our solution is divided into multiple components, android, front end and back-end. Each user story typically comprises a combination of these components which would be assigned to different team members to perform. The issue that we have with assigning points at a user story level is that we are unable to see how many points have been assigned to an individual component or user. If we had sight of this we would be in a better position to identify whether a resource has been over allocated or not.
Do you use time tracking? You could be assigning Original Estimates to the sub-tasks (in minutes/hours/days) and basing your reporting on that. You could use the Workload Pie gadget to generate a report of Original Estimate grouped by Assignee or by Component.
Thank you Andrea for sharing this need,
myself and my teams have suffered from this missing feature in Jira for years and unfortunately Atlassian has never took this request seriously.
By using subtasks we are trying to promote the team collaboration in getting a story/task to "Done" so developers, testers and ... can work closely together on one story together rather than on separate tasks which is against agile culture.
However, there are no simple way to see individual story points assigned to subtasks:
1- Jira does not roll up story points of subtasks to the parent story/tasks
2- Manually added story points to the Tasks/Story is credited toward the assignee of the task/story and subtask owners don't get the credit.
This feature is very much needed for years and all teams I have worked with wanted to use it but unfortunately Atlassian doe snot seem to see this as a problem.
Very frustrating indeed!
Welcome to the Atlassian Community!
Atlassian does not see this as a problem because it is not a problem with the software. Jira Software supports scrum, which has nothing to say about sub-tasks. In scrum you put estimates on sprint items, not fragments of them, which is what a sub-task in Jira is.
The "problem" here is not Jira ignoring estimates, it's your process trying to not do scrum while using a scrum tool!
I don't agree with this answer; I am talking about a feature called subtask in Jira which existed for many years and as you said correctly this has nothing to do with Scrum. Scrum is not dictating how teams should use Task and Subtask.
Many teams find using subtask helpful and would like to add their estimate per subtask and I think Atlassian should provide a feature or improvement that its customers/users are requesting instead of policing scrum teams.
I am sorry to be so blunt about it, but your "agreement" is irrelevant. Scrum does not see Jira sub-tasks as sprint items, so their estimates are ignored.
Atlassian are not going to change that, because it would move it away from the way Scrum works.