Story Point Estimates in Sub-Tasks

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?

2 answers

This widget could not be displayed.
Anna Cardino Atlassian Team Jul 28, 2014

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


This widget could not be displayed.

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.

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.

Makes sense, but it's not going to work for a good proportion of the users, the community has a wide range of needs in doing this.

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.

I would also like to 'vote' for what Phillip is describing. Not allowing the parent task to just accumulate the effort (or story points) of it's sub-tasks makes our processes very manual. 

Another vote here for Philip's requirement! At the moment we also estimate our subtasks per developer, and then have to sit and manually add those points to assign the total to the story. Not ideal.

Completely agree with Philip too...where can make this feature request to Atlassian! Seems like we're building support here!

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted Wednesday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in   talking to 20 people planning t...

150 views 2 0
Join discussion

Atlassian User Groups

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!

Find my local user group

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

Groups near you