Story Point Estimates in Sub-Tasks

[Testing User]

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?

[Phillip Molaro]

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.

[Nic Brough -Adaptavist-]

So what method would you use to sum up?  Or how would you implement a way to do the various schemes people might want?

[Phillip Molaro]

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.

[Nic Brough -Adaptavist-]

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.

[Phillip Molaro]

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.  

[Phillip Molaro]

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.

[Nic Brough -Adaptavist-]

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.

[Phillip Molaro]

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.  

[Carl Brewer]

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.

[Eric Lundberg]

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.

[abbie giffin]

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. 

[Nikki Smith-Wragg]

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.

[Jordan Hauer]

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

[Steve Carlin]

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

[Guillermo Marqueta]

+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.

[Jordan Hauer]

@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

[Guillermo Marqueta]

You are right, @Jordan Hauer :)

[credpago]

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 

[Otis Gospodnetić]

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".)

[Otis Gospodnetić]

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.

[Jordan Hauer]

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

@[deleted], 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?

[Otis Gospodnetić]

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

[GlennWidener]

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!

[Nic Brough -Adaptavist-]

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

[Joe Marczewski]

Nic nobody is suggesting that SP's are mandatory on the sub-tasks so I don't understand why it wouldn't work with Scrum.  if people are currently using sub-tasks and then not estimating them then they could continue to do the same.  If users  do want to estimate them then as per the solution that Phillip suggested they could aggregate to the story.  Better still, the aggregation (or not) could be an optional configuration for an Admin to turn on or off.

JIRA are either going to be prescriptive in how people and organisations to navigate their way through the unique challenges that their businesses experience, or, they can provide a toolkit for people to adapt their processes and embrace the 'Agile way'.

I also can't believe that JIRA are waiting until a customer gives them the right answer before deciding to make a change.  Their customers are presenting a requirement, and I am pretty sure that they have workers on their payroll who are more than capable of turning that requirement (that has been out there for years now) into a workable solution for all!

[Eric Lundberg]

This thread is a perfect example why Atlassian isn't truly an Agile organization, which is terribly ironic because the goal of Jira is (supposedly) to enable more Agile development. Listening to users, meeting their needs, and delivering value to them should be your core goal and everything should flow from that (see "Law of the Customer" https://www.forbes.com/sites/stevedenning/2016/09/08/explaining-agile/#596b5a30301b)

When you suggest "you should not estimate story points for sub tasks", your prescriptive view about how your tool is used is frustrating your users and preventing us from achieving our goals with your tools.

We have different needs. We're users. This should come as no surprise.

There are plenty of tools which allow us to meet our needs, but they're all third-party add-ons which cost money. I use an automation tool to sum up the story points.

Just bring automation tooling into the core product and let us solve our own problems on these edge cases.

[Nic Brough -Adaptavist-]

Ok.  There's a couple of essays as responses now.  They're good topics, but they show that the authors do not understand Scrum estimation and commitment.

Please, go read the Agile manifesto, dip into a bit of SAFe, Lean, Less, DaD, etc if you have to, but please please, please go read up on what to estimate and how to talk to your product owners.

Then ask yourself

• What did I commit to doing
• Where are the estimates on my commitment
• What does my PO (and eventually customers) care about.  If you're struggling with that, some numbers might help - what do they care about  0/100 subtasks, 1/100 subtasks, 50/100 subtasks, 99/100 subtasks and 100/100 subtasks being complete?

There is no problem to solve here in software.  The problem is how you think you are working.

[Eric Lundberg]

@Nic Brough -Adaptavist- thanks for bringing this back to principles. However, as a consultant, I'd expect better tact from you than saying "that the authors do not understand Scrum" (you can't possibly know what people don't understand) and "the problem is how you think you are working" (it's very brave to presume you know the problem without discussing it with us face-to-face)

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

That aside, I have a few questions:

Fundamentally, is Jira a Scrum tool or an Agile software development tool?

If it's a Scrum tool, nowhere in the Scrum Guide (https://www.scrumguides.org/scrum-guide.html) are story points mentioned.

I imagine they're an artifact to, as you mentioned, to make it easier for POs to prioritize and for teams to predict completion dates or scope.

If it's an Agile tool, then nowhere in the Agile Manifesto (http://agilemanifesto.org/) is this described. In fact, it says "Individuals and interactions over processes and tools", suggesting if we have an issue with Jira we just ignore it and use a different tool.

In terms of the Principles, they're also high-level (http://agilemanifesto.org/principles.html) and don't cover the topic of estimation.

Ultimately, estimation supports the overall software delivery process and if it works for someone, then it works.

[Nic Brough -Adaptavist-]

As a consultant, it's my job to explain why things don't do what people expect them to.  It is often that they have not grasped something, rather than a flaw in the software. 

Jira Software tries to support Scrum at its most simple and plain usage.  If you are using estimates on sub-tasks, then you're probably not using it to measure delivery against commitment, and that's not Scrum.

In real life, you might actually be fine, as long as your people understand what they are doing, but you need an accumulation strategy if you're going to use estimation as a measure to help you improve and deliver, and those rapidly become complex, meaning that you have to favour process over people (Cherry picking bits of the manifesto is so easy isn't it?)

Jira avoids falling into that by simply not supporting any accumulation strategy.  Lazy, perhaps.  Because if you are doing it, you aren't doing Scrum and measuring delivery vs commitment properly - probably another reason they don't bother.  Not wanting to support every possible strategy for it - another good reason not to try.  You can do it, of course, with apps and code.

Look at the simplest strategy - add up the estimates on sub-tasks and the issue.  Simple, intuitive, and what most people think they want.  You now need to amend your process so that every single sub-task is known and sized before the sprint begins.  Your process is now rigid and means you no longer have the ability to split a story up during the sprint.  You might as well stop using sub-tasks, they're not helping you much here, just imposing process.

Other strategies work a lot better, but, of course, mean more code, and still, more process over people.

[Anna Cardino]

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

[Josh Tinsley]

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:

1. At the Story level
2. At the SubTask level
3. Both

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:

• Then everything works as is.
• No story point field is displayed on sub-tasks
• Even if the field is manually added, those points wouldn't matter.
• Board and Reporting only care about story level points and so on...
• (The way it is out of the box right now.)

If I choose SubTask level:

• The story points field on the stories becomes a read only field that displays the sum of all the points added to sub-tasks.
• At least one sub-task would be required (maybe).
• The sprint board would reflect the points added to the sub-tasks, and reporting would as well.

Lastly, If I chose BOTH (the route I feel most people would choose):

• Story points could be set either at the story level or subtask level
• If subtasks were added AND points were added to those sub-tasks, the story point field on the STORY would show a read only calculated sum of the points added to it's sub-tasks.
  • On hover it could say something like, "Story points have been added to sub-tasks of this issue. Please address each sub-tasks points individually.") 
  • You could even give a "Clear" button to clear all sub-task points from the story if you decided to just add the points at the story level for a ticket. 
• Then on the sprint board, you would see total points wether they came from sub-tasks or stories. Reports would show the same.

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. 

[Nic Brough -Adaptavist-]

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.

[Dang Thi Thuy Tien]

Hi, @Testing User 

You can use this plugin to estimate your subtask:  

https://marketplace.atlassian.com/apps/1219833/hierarchical-calculation-field