Is there a way to add estimates / story points to sub-tasks?
The estimate field shows up fine for stories and bugs, but not for sub-tasks.
Thoughts?
Hi Michael,
Scrum doesn't dictate that sub-tasks are estimated in time (or even that you use sub-tasks as your "Sprint Plan," though lots of people do it and Greenhopper enables it). So in this instance, I think Greenhopper is over constraining people. There are plenty of Scrum teams that use "Estimation Points" or "Story Points" to estimate the sizes of sub-tasks as well.
You should not estimate story points for sub tasks. Story points as the name suggest are only for stories. An alternative for sub-tasks is to use the orig estimate field and estimate them in time, e.g. hours.
I've found a similar query as your's. Please see https://answers.atlassian.com/questions/68846/how-to-estimate-story-points-for-sub-tasks
Hope it helps.
Regards,
Monique
While I understand the answer for this post, and that "Story Points" are for stories, this limitation makes it difficult for my team to use sub-tasks effectively.
If we have a story, that needs parts done by multiple developers, we often create a sub-task of that story and assign it to the developer. We ideally want to track how many points each developer has assigned so we know who is and isn't overloaded, etc. In the current model we can't do that. We can only assign points to the Story and thus to a single user of say 3 working on the task. This throws reporting off.
It would be a great enhancement for Jira to offer this as a customization, where an admin could enable an option to "Allow Story Points for Sub-Tasks". If enabled then points could be assigned to sub-tasks and be summed in reporting just as hours are. This would be useful for teams like ours that use points instead of hours for tracking work.
So what method would you use to sum up? Or how would you implement a way to do the various schemes people might want?
Nic,
At my previous company, we only used hours for estimates, not story points. Developers would estimate tickets during backlog grooming sessions. We then logged out time on the tickets, and at the end of the day, as a manager, I could see the work ratio showing me how well we estimated and completed the task. It actually made us much better estimators, and was a tangible metric I was able to use annually on employee reviews.
When we had sub tasks, we would put the hours estimate on the sub-tasks. The parent ticket would show the sum of those hours. When I ran the Time Tracking report with the option to include sub-tasks option enabled, and I could see an accurate picture of how complete an Epic was. I could also run Workload report and see who was overloaded and who wasn't.
In my current team we use Story Points instead of hours. Its been an adjustment for me, but I see the value. I do wish in general SPs had some of the features of hours, where I could log the time I used and see a similar work ratio. Right now, we just work within the points assigned, and if we went significantly over or under we adjust the points when we're done. That way we have a more accurate picture at the end of the sprint.
To answer your question, I would hope that SPs on a sub-task would work the same as hours do. I log points on the sub-tasks, then the parent shows the sum of those points. The benefit would be, when we look at the SP breakdown on our agile board, we can still see that I have 6pts, and Joe has 3pts, and Mary has 5pts. Right now, the way it works I see Joe (the owner of the parent ticket), has 14pts, while Mary and I have none. That's the root issue we have with not being able to put SPs on sub-tasks. We can't evaluate workloads accurately.
Sorry, I was not clear. It doesn't actually matter whether you use Story points or Time estimates - the question is how you want them to work with the story.
As an example, would you estimate a story and then reduce the estimates on it as you create sub-tasks with their own estimates? Or keep a low or zero estimate on the story and let them add up? Or add the estimates up as you create the sub-tasks?
There are lots of variations on that, and whichever one you pick, you'd need to approach building Scrum reports and doing the processes differently, possibly choosing when to burn down, which could render your Scrum process pointless if you do it on sub-tasks.
Atlassian have chosen to keep it simple for now. They simply don't take account of estimates on sub-tasks in the Scrum process.
I'd prefer to be able to rig up one of those schemes, but Atlassian can't pick any particular route, they'd need to build something that can be configured to work for all users. Until they've got a way to do that, you simply don't estimate on sub-tasks.
Hi, @Testing User
You can use this plugin to estimate your subtask:
https://marketplace.atlassian.com/apps/1219833/hierarchical-calculation-field
Personally, I don't get why this is so hard. Azure DevOps does it already in it's own way, but for Jira... you just give a setting (probably at the project level) that says where points are going to be calculated from:
The outcome of this has 3 side-effects, the way reporting runs, the way a sprint board looks, and the way points are handled on the individual tickets.
If I were to choose Story level:
If I choose SubTask level:
Lastly, If I chose BOTH (the route I feel most people would choose):
Also, why the heck doesn't Jira allow you to move only a couple subtasks from a ticket forward into another sprint. Just seems stupid.
Yes, that's just one of many possible schemes for working with estimates on sub-tasks. There are plenty of others.
But you still have to come back to the fact that sub-task estimates are not directly relevant to the sprint.
Also, you ask "Why doesn't Jira allow you to move only a couple subtasks from a ticket forward into another sprint" - because it is complete and utter nonsense to do so. Sub-tasks are a part of their story, not separate items. It's a bit like going for a park-run, but not finishing it and then entering your left leg in the next one.
It looks like you're new here. Sign in or register to get started.
