It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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?

3 answers

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.  

Like Macmild Gealogo likes 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.

Like mlr likes this

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.

Like Abdelrahman Sinno likes this

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!

Backed also.  Story (or Task) would benefit greatly from having aggregated values based on the Sub Tasks it contains.

+1 for Phillip's proposal.

I found a related issue on Atlassian's roadmap board for Jira Cloud: https://jira.atlassian.com/browse/JRACLOUD-70150?jql=project%20%3D%20JRACLOUD%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22sub-task%20estimation%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

 

We may vote there as well so it is easier to give this issue more visibility.

@Guillermo Marqueta this isn't exactly what Philip's post was referring to, as this isn't related to story points...story points are more important that time tracking IMHO

Another vote here! We are using Epics as a ugly workaround for this! Would be a HUGE difference if subtasks points were considered at sprint burndown 

And another +1 for this!

Current JIRA behaviour seems to assume that all sub-tasks for story are done by the same person.  I bet this is not the case in at least 50% of JIRA use cases.

Examples:

1) publishing a new web page on a web site needs:

  • UX - designer
  • copy - product/marketing manager 
  • HTML/CSS/JS - developer

2) building a smaller software product feature

  • backend developer
  • frontend developer

(to keep it simple. Yes, for bigger things one would use Epics, but you don't want to have an Epic for everything.  You just want to have JIRA configurable to give you "story points by assignee, regardless of whether the story point is on a story, task, or sub-task level".)

Btw. I've seen the same request in N other threads here.  I see Nic responding in more or less the same fashion in all those threads.  The main reactions being "You are using JIRA wrong", "It is not designed to work like that" and such.  If there are so many people asking for this exact same thing, and numerous example in those threads illustrate there is a real need for this, then I would imagine/hope Atlassian would listen.  Users (customers!) are giving you valuable feedback when they invest themselves by spending their time describing the missing functionality.

Like # people like this

Otis is completely on point here. I echo the same sentiments as both his posts.

 

@Otis, can you point us to where you found the other threads? And whether you've found a public JIRA issue we can comment on as well?

Jordan, I googled and found N other threads from 2013, 2014, 2015 and such.  Now I see "Related content" in top-right of this page with links to even more threads, some of which are very fresh. Same questions, same answers.

 

Otis

So, after hearing the same request over and over again for all these years, is Jira finally going to start listening?  Simply summing subtask points, time estimates, and time totals with the values in the story, presenting the read-only total next to the corresponding entry fields in the story, and including that total in all higher level totals would clearly and simply address every use case: just clear the values entered in the story/subtask if you want something simpler.   And yes, I've drunk the Agile estimation kool-aid, but it's fallacious to argue that you can't sum story points in this use case, when that's exactly what you do to determine when a sprint is fully booked!

Atlassian listen, but no-one has yet proposed a simple solution to this that works with Scrum in a way that works for everyone.

3 votes
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


Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira

Demo Den Ep. 7: New Jira Cloud Reports

Learn how to use two new reports for next-gen projects in Jira Cloud:  Cumulative flow diagram and Sprint burndown chart. Ivan Teong, Product Manager, Jira Software, demos the Cumulative ...

334 views 1 3
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you