nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automation: Assigning based on who has the least amount of estimated time in sprint

Pfdev11

Is there a way to assign tasks/sub-tasks to whoever has the least amount of estimated time dedicated to tasks in the current sprint? I'm new to jira automation but I went through and didn't find anything that could aggregate the time estimates like that. I do see that the rest API provides a "timetracking" section that shows the original estimate and remaining estimate.

Is there anything I'm missing?

Thanks!

Accepted answers

Marc -Devoteam-

Hi @Pfdev11

Welcome to the community.

First how would you define who has the least amount of estimated time in the sprint?

To me this in my opinion is bad planning, as items in a Sprint should be assigned in Sprint planning

A Sprint should be planned with work based on the teams capacity, this is the task of the SM. This based on Stories, Tasks and/or Bugs.

Sub-tasks creation should be the task of the assignee of the Story, Taks and/or Bug, they also should no have an estimation ins Scrum.

What is you take and opinion on this?

Even if you know you team capacity, then you would first have an automation that would calculate per team member their current combined total of estimation, then you would need to deduct this form the time a team members works in the sprint length and then you would have the time remaining for a single team member.

Then you would need to comapre this number to the estimate of any issue in the sprint unassigned (weird) to see if you could assign this issue to this team member

All comments

Marc -Devoteam-

Hi @Pfdev11

Welcome to the community.

First how would you define who has the least amount of estimated time in the sprint?

To me this in my opinion is bad planning, as items in a Sprint should be assigned in Sprint planning

A Sprint should be planned with work based on the teams capacity, this is the task of the SM. This based on Stories, Tasks and/or Bugs.

Sub-tasks creation should be the task of the assignee of the Story, Taks and/or Bug, they also should no have an estimation ins Scrum.

What is you take and opinion on this?

Then you would need to comapre this number to the estimate of any issue in the sprint unassigned (weird) to see if you could assign this issue to this team member

Pfdev11

So during planning, any new tasks that will be brought in get assigned and given an estimated time to complete by the assignee. The thought of using Round Robin or balanced workload occurred, but the issue was that if someone is working on a single task but with a long estimated time, they might get constantly get assigned the subtask resulting from this possible automation.

I was asked to do this, but I don't necessarily agree with it

Marc -Devoteam-

Hi @Pfdev11

There are no options in automation to based assignment based on estimated time.

Unless what I proposed earlier, you would first need to get for each user the current count of estimated time, related to their current assigned issues.

Then assignee the issue to the user with the least amount of estimated time.

Still the question is then is this doable for the user, will this not exceed the team/user capacity for the sprint length?

Aleksi Rajamäki

Hi @Pfdev11

I have worked in Scrum teams for 6 years, including 1 year as a Scrum Master, and I have noticed that sprint planning is not that simple.

The real capacity of the upcoming sprint needs to be considered as a whole: holidays, absences, team composition, focus time, and unfinished work that has been carried into the sprint.

Carry-over work should not always be treated as if the full original estimate consumes capacity again. You need some way to estimate how much work is still left. That can be based on workflow status, such as In Progress or In Review, or based on logged time if the team uses worklogs.

I agree more with planning around team capacity: how much the team can realistically complete in the sprint, not just how much work each individual has assigned.

In our team, people can then pick a suitable ticket from the sprint, start working on it, and assign it to themselves.

Past sprints can still help, but mainly as historical context: who was in the team, who was absent, what the capacity looked like, and how much work actually reached Done.

Automation can help show workload, but I would not let it decide sprint commitment or ownership by itself.

Full disclosure: I built ScrumNav around this kind of Jira sprint planning workflow: team capacity, sprint load, carry-over impact, estimation, and reports.

kh-federico

Hi @Aleksi Rajamäki I removed a promotion that’s against our Atlassian Partners - Rules of Engagement . Please take a moment to review our rules so you're aware for next time. Thanks!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-data-center

automation

data-center

jira-automation