Auto-scheduling not changing dates
Asked by Stephen Bond:

Hi,

I am a new user of advanced roadmaps, and experimenting with auto-scheduling. I have a set of sub-tasks assigned to one person, and was hoping that auto-scheduling would move them to ensure that person is not overloaded (i.e. change the dates so they are sequential, rather than concurrent). However, when I run Auto-Schedule, the dates are unchanged.

I'm wondering whether this is something that auto-schedule should be able to do, and if so, what I need to do to achieve that?

Thanks,

Stephen


Answers:
author: Dave
body: Hi [@Stephen Bond](/t5/user/viewprofilepage/user-id/4325131),

Although auto-scheduling does take the number of members in a team into consideration and schedules issues with respect to them, unfortunately it does not explicitly assign issues to any specific individual - only to the team that the individual belongs to.

To give a concrete example of this - if you have 2 people in a scrum team, with a velocity of 10 points, the auto-scheduler will not assign an 8 point issue into a single sprint because it assumes that the velocity is split evenly between the 2 team members. It also works on the assumption that individuals will not "swarm" on a single story level issue but that only one person will work on any one story level issue at a time.

For the most part you could possibly argue that it makes more sense for issues to be manually distributed throughout the team in rather than having everything assigned - I would expect that Atlassian would get quite a bit of push back if this was how it worked, but I'd be interested to know your thoughts.

We're actually looking into individual capacity planning in quite a bit of detail at the moment so I'm very interested in your use cases here. We're thinking of ways in which we can visualise how loaded each person is but there are various edge cases we want to consider.

For example - do you find that individuals only belong to a single team? Or can they split their time between multiple teams? Would you want the assumption to be that all individuals contribute evenly to a team or you would you like the ability to control each members contribution?

Regards,

Dave

comments: author: Stephen Bond
body: Hi [@Dave](/t5/user/viewprofilepage/user-id/510225)

Many thanks for your quick response.

My basic use case is actually very simple (and I realise I didn't explain it very well initially...). I have a set of Jira tickets (mostly sub-tasks), which are assigned to individuals. I don't want to change that assignment. However, I do want Jira to change the dates of those tasks such that each individual is not assigned more that one task at a time - in other words, for each individual, to make the tasks sequential instead of concurrent. In some cases there may be dependencies between tasks which need to be honoured; in other cases the tasks can be done in any order.

I am currently not using scrums and have not defined teams - is it valid to try to use auto-scheduling in this scenario? When I auto-schedule, it seems Jira wants to add teams to each task, so I guess I need to do something there (but I'm not completely clear what should constitute a team in this sense).

To answer your question, in most cases, individuals will be just working on one broad set of tasks, rather than splitting their time between multiple teams.

Another thing that would be nice would be to see where individuals are overloaded. I can see this functionality is available in the WBSGantt plugin, but not in advanced roadmaps (as far as I know).

Stephen


author: Dave
body: Hi [@Stephen Bond](/t5/user/viewprofilepage/user-id/4325131),

So generally speaking the auto-scheduler will want to assign teams to issues, but as I mentioned it will never explicitly set an assignee (or change an existing one). However, it might schedule issues in the assumption that they could be picked up by another member of the team.

If you've not defined a team yet, then I would expect that you'll find that a team has automatically be created for you and is associated with the issue source (i.e. the project, board or filter) that you used to create the plan - and this is the team that the scheduler is being assigned.

By default this generated team will be empty and you can choose to add members to it. The benefit of adding members is (currently) somewhat opaque but the main benefit is that it will evenly divide the teams weekly hours or point velocity between it's members.

However - based on what you've said, I'd be concerned that unless you're creating a single person per team that you're going to lose the ability to control overbooking - i.e. you might want a single person to do all the sub-tasks for a specific issue but the auto-scheduler might be expecting them to be picked up by others in the team (and the dates set on the issue will reflect that).

So the only way I can see that you can get the auto-scheduler to work as you'd like is to have single member teams and that is probably too much overhead or might prevent you from doing other things with teams.

The visualising individual overloading is something we definitely want to get to and is something I've recently been prototyping, but it's too early to say if/when that will be available.

Regards,

Dave


author: Stephen Bond
body: Hi [@Dave](/t5/user/viewprofilepage/user-id/510225)

Thanks for your helpful response. I've been experimenting some more, and I have had some success by setting up one-person teams. However, this has led to another issue: in some cases I have sub-tasks (of a particular task) which are assigned to different people. These sub-tasks seem to automatically inherit their team from their parent task - it doesn't seem to be possible to assign different teams to them. Is there any way around this?

Thanks,

Stephen


author: Dave
body: Hi [@Stephen Bond](/t5/user/viewprofilepage/user-id/4325131),

The reason why sub-tasks inherit teams from their parent story is because it is not possible to assign a sub-task to a different sprint than it's parent, and because sprints are associated with a team then it also makes sense to not allow different teams to work on different sub-tasks of the same issue.

However, this obviously breaks down when you're using single person teams as I recommended - I should have considered this but I hadn't really considered that you might want to distribute sub-tasks of a single story like this.

Unfortunately I'm not sure that there is a way to work around these two problems. One change that we are going to be rolling out very soon is the ability to "selectively schedule" issues (i.e. you select issues and then the auto-scheduling is just applied to those issues) and that might help you avoid issues that you have got setup as you'd like, but realistically I'm not sure this is going to solve the problem either.

The only other thing that I can think of (which I acknowledge isn't particularly practical) is to shift everything up a hierarchy level so that sub-tasks aren't the smallest issue type that you're using ... although that's obviously not a simple shift and has a knock-on effect elsewhere in how you might be using Epics, etc.

We've also considered having an additional option in the auto-scheduler to prevent setting certain attributes (so at the moment you can choose to just set empty values or override all values) but if we added the option to prevent team (and also sprint and release values) from being updated that might also help?

I'd be interested to know what you think about any of these proposals although I completely acknowledge that none of them are perfect,

Regards,  
Dave


author: Stephen Bond
body: Hi [@Dave](/t5/user/viewprofilepage/user-id/1183605)

Many thanks for your reply and apologies for the long delay in getting back to this.

Since there doesn't seem to be a better solution, I have now shifted all my Jira issues up a hierarchy level as you suggested, so I am now dealing with tasks instead of sub-tasks. I can now assign them to different teams as expected. Using one-person teams, I'm able to run auto-scheduling in the advanced roadmaps.

However, I would like to automate the assignment of the "Team" field so that whenever an issue is assigned, the Team is also set. I have tried this using Project Automation. It seems it's necessary to use json code here, as the Team field isn't listed. I have therefore done the following:

{  
"fields": {  
"Team": "Team Stephen"  
}  
}

However, I get an error saying "Team with ID 'Team Stephen' could not be found". I have checked that Team Stephen does exist, and I can set the Team field to this manually, so I don't knoiw why the automation doesn't work.

Any suggestions?

Thanks,

Stephen


author: Dave
body: Thanks for getting back to me on this [@Stephen Bond](/t5/user/viewprofilepage/user-id/4325131), I know that there have been some issues with automating the Team field on Cloud (with the additional automation tools that come with Jira Premium) but I notice your question is tagged as server and I'm not familiar with Project Automation (which I assume is a marketplace application, but I couldn't spot one with that exact name).

I do know that the ID of the Team definitely won't be a string, it will be a number - maybe that is the issue here? In my experience I have found that building a new JQL filter using the Team field will convert the label and actually reveal the number. This might be an option to explore?

I appreciate that this isn't the best answer to your question, but hopefully it might provide some assistance,

Regards,

Dave


author: Stephen Bond
body: Many thanks [@Dave](/t5/user/viewprofilepage/user-id/1183605) - that's working now :-) I was able to get the numerical team ID from a JQL filter, and used that in my json code for my automation.

Stephen


author: Dave
body: No worries [@Stephen Bond](/t5/user/viewprofilepage/user-id/4325131) - glad I was able to help!


Tags: advanced-roadmaps

server