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.
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.
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.
So this could work in a few ways.
First, if I make a story, and give it say 2 points (we do 4h points, so that 8h), then get into it and decide, hey I need a sub-task for Joe to do part of this, then I would want to make that subtask, give Joe 1point on it, and my parent story task would now automatically change to 3 points (this is how hours work today).
Most often, when we know ahead of times we need sub-tasks (a story is going to take 3 devs), we'll make the Story with no points, add the sub-tasks and put the points on there. Again, I would expect the parent story ticket to sum those points.
An example of this is we are currently working on an Epic to make our site ADA compliment. We have Story tickets set up for specific sections of the site (ex. product details page), then sub-tasks set up for the specific sections of that page that need to be addressed. Depending on what the section is, the subtask is assigned to various devs. We want to continue to track points to devs, so being able to put the points on the sub-task gets that.
From the reporting side, I would expect you would EITHER track only stories (with the summed points) which seems to make the most sense given my first scenario, OR you would choose to only track subtasks and ignore the points sum on the parent story. Otherwise you'd get duplicate points.
I fully respect the simple approach Atlassian takes. As I originally suggested, I think this should be a non-default option an admin could enable for their team. I know several teams that work in a similar fashion to ours so I know there is a need for this.
After re-reading my response, I think you would need to treat points on sub tasks and parent tasks as equal weights and not sum them. Of if you did sum them make sure that in reporting, each user only gets associated with their points.
In my first example, I have 2 its, Joe has 1. We need to see that the task took 3 total, but from a reporting stand point, we need to know I did 2 and Joe did 1. Hope that makes sense.
Thanks and I understand "the needs of the many". I will say, it would be nice if something changed in regard to this. At my last job we completely stopped using sub-tasks because it was tough to keep track of time on the reports. At my current shop, we keep going back and forth on using them or not using them, again because we have a thought time seeing the points summary, and keeping the related tickets in a group. We often use labels and filters but its not as clean IMO.
Thanks for hearing me out on this though. Its good to know that Atlassian is aware in general.
I'd like to add my vote for exactly what Phillip described. I lead a multi-discipline engineering team (as opposed to just software), and we have adapted several agile concepts to meet our needs. Rolling sub-task story points into the parent would be a huge plus for our team. Report generation at the end of a sprint is nearly useless without it.
Agreed with Phillip and Carl; our stories might involve multiple developers with different skillsets, so lower-level estimation would help us allocate work better during sprint planning.
Secondly, since our development work is highly unpredictable, we've found that estimation isn't meaningful at the story level, so we have to estimate at the task or sub-task level. Again, it would be nice to see the point level at the story level, or even at the epic level.
This avoids duplication and allows us to make higher-level strategic decisions on which epics and stories to pursue, without having to go through the manual process of summing the points and then, whenever the estimates change, propagating those changes all the way up.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Hi Atlassian Community! My name is Shana, and I’m on the Jira Software team. One of the many reasons this Community exists is to connect you to others on similar product journeys or with comparabl...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs