How to configure Jira such that Sub-tasks estimated hours are accounted for per person

[Deleted user]

Our team consist of multiple developers which often work together on a single Issue/Story. To divide and plan the work accordingly we use Sub-tasks. This makes it possible to assign the developers to the correct sub-tasks.

Unfortunately we are not able to use the time estimates during the sprint planning session in a proper way. This is the current behavior:

- Define parent Issue/Story name

- Define Sub-tasks

- Assign the developers to the sub-tasks

- Estimate the required time per sub-task

- The total/cumulative required times is now visible in the patent card or the details pane. But this sum is of all the sub-tasks and developers together

What we want to archive is to get the sum per developer (Of all its issues and sub-tasks) such that we can determine if his/hers workload fits in the sprint.

How do we configure Jira to make that possible?

Secondarily it would be great if we can set the developers capacity (the time he/she can actually spent in the sprint) on forehand such that during the sprint planning the remaining capacity goes to zero while we keep adding cards to the board. Is that possible somehow?

Thanks!

[Andy Heinzer · Accepted solution]

In this case, I don't believe it's possible to configure Jira in a way that will allow you to exactly what you want here with the current steps you are using.  The reason for this is that subtasks are not being used as a means to estimate task time in Agile.   Certainly these can be rolled up into the estimation of the parent issue, but there isn't a good way in Jira today to see these estimates in Agile, especially when the subtasks are broken down and assigned to different users.

Perhaps the existing feature request of https://jira.atlassian.com/browse/JSWSERVER-9167 could be helpful if it were implemented within jira in the future.

However, as of today, I would instead recommend not using subtasks in this manner.  Instead it's probably a better experience to create separate Tasks/Stories in place of the subtasks and use these instead.   If you already have these created, you can convert existing subtasks to standard issue types as well.  These issues can still be linked back to other issues in much the same way a subtask/parent issue can, but the advantage here is that you will gain better insights into how much work each user is actually been assigned to, as well as how much work as been completed.

As for your second question, if you're interested in better understanding the capacity of your team, I'd recommend looking into Portfolio for Jira.  This is an Atlassian plugin that is meant to build on top of your current Jira Software/Agile data in order to help you plan/roadmap better.

[Laura S. Young]

Willem-Jan - I was looking for a similar solution today and ran across this article. We function exactly as you described above and I don't plan to change something that works super well for us to fit the limitations of a tool.

This might be overly simplistic but as I thought about it - I created a filter that looks (very simply) for the sprint and the assignee and then I configured the fields to include story points and original estimate for time. 

My next step is to figure out if I can find a field for "next sprint" and "default to logged in user" or something like that so that the filter doesn't need to be adjusted, but what I was thinking is that we are a self-organizing team and we wanted similar functionality that you described so that we as individual team members knew whether we were appropriately resourced and when to say "I'm loaded up - no more". For managers, I think a revised filter with similar simplicity could work. It's not perfect but it's something. I tested this on not yet started sprints (which is what I really need it for) and it worked. So....maybe something to try?

I don't know how to approach your second question but it's a great idea for a built in report!

[Deleted user]

Thanks Andrew. That's unfortunate. We will stick with normal stories for now.