Recalculating the schedule
This page refers to Portfolio classic plans. If you are currently running Portfolio 2.0, please check this link to access the latest page version.
The automatic scheduling mechanism is one of the core capabilities of Portfolio for JIRA. It continuously computes an optimized and realistic resource allocation, and forecasts release dates, resource utilization, and bottlenecks in your work.
When scheduling work, the scheduling mechanism takes into consideration the following:
- Priority of items in the backlog
- Sequence, which is comprised of start and end release dates
- Estimates and required skill-level capacities
- Teams and people's availability
- People's skills - what type of work can do each team member.
- Varying availability and absences. For example: vacations, people available only from certain date and so on.
- Dependencies between backlog items
- Work's stages - activities that can happen either in parallel or sequential activities.
- Team's schedules - iterations and sprint lengths, or continuous, day-to-day schedule.
Configurable constraints, for example how many people can work in parallel on a story.
Scheduling calculation triggers
The automatic recalculation is triggered with every change you make by default.
Tip: Use the automatic calculation mode, if you have your plan already set up and are trying to work through smaller scenarios, and want to directly see the impact of changes.
Select your plan, go to Plan > Recalculation and select Automatic.
Every time you make changes, the calculated fields turn grey/hatched indicating that the values are potentially outdated and might change with the next recalculation.
The manual update happens only when you click the Recalculate button that appears in the upper side of the screen as soon as you make a change.
Tip: Use manual calculation if you need to make a couple of changes at once, like estimating multiple backlog items, or do a larger backlog grooming session.
Select your plan, go to Plan > Recalculation and select Manual.
Automatic release assignment
Automatic release assignment only works in the following case:
At least one release is defined with a fixed end date.
In this case, backlog items with release assignment set to "Calculate" will be put into the release(s) automatically based on their priority rank.
The scheduling algorithm currently optimizes for scheduling the highest priority items first. Even if there might be a scenario where the team could fit in a bit more capacity into a release if it started with a lower priority item, Portfolio for JIRA will not suggest this in the schedule. Items that have highest priority, should also be started first. Also, you might want to prioritize items with highest risk first to tackle uncertainly early in the process.
Calculated and static assignments
The following fields can either be assigned statically, or suggested automatically by the scheduling algorithm:
- Release - manual: "item should be shipped with release X"; automatic: "into which release does the item fit?".
- Team - manual: "this story should be implemented by team A"; automatic: "based on skills and capacities, which team can deliver this best?"
- Members - manual: "Peter and/or Sarah should work on this"; automatic: "based on their skills and availability, it would be best if X, Y and Z work on this story".
If you set a field to 'Calculate' in the dropdown menu, a value is assigned automatically upon the next recalculation, and the field gets a blue background.
Automatic team and member suggestions
The automatic assignment of teams and members is based on the team member's skills and availability.
One story is always assigned to exactly one team. Multiple members can work on a story, the maximum number is configurable in the settings.
The selection policy takes several factors into consideration. Here are some examples for what is considered: Multiple people might have the skills to do a particular story, but they may have other skills as well, which are still required for other stories? If yes, Portfolio for JIRA prefers those who don't, so the other stories can be assigned more flexibly. Based on availability/weekly hours, who could achieve a high-priority item faster? There's a list of factors influencing the optimization algorithm, but these are some of the most decisive parameters.
Scheduling for a one-piece-flow
With its origins in manufacturing and lean production, the concept of achieving a one-piece flow has long found it's way into software development. Portfolio for JIRA also borrows from this concept. The scheduling algorithm is tuned to complete individual deliverables (in this case, stories) as quickly as possible.
- Finishing stories end-to-end has priority. Once the effort of a story is started, it would rather complete the first story before starting a new one.
- Schedule for deliverable increments: Take stories into an iteration / release only if can be delivered completely, no "partial" scheduling just because there are some man days of capacity left.
- Run through stages of work per work item: When planning e.g. for design and implementation, this means design for one story, and implementation for one story, rather than a design phase for all stories, before starting all the implementation tasks.
Note: We've picked this scheduling approach, since it reflects most intuitively what happens in real life. Once you start working down your backlog, you'd rather try to complete full work packages before starting something new. Some things need to happen sequentially, like you'd first write a user story before implementing it.
At the same time, it gives full flexibility: If you need to do for example larger up-front design, just add a work package with effort estimates only for design capacities.
Portfolio for JIRA has a planning horizon of 5 years by default. If you believe that your schedule isn't being displayed properly and your estimates are for less than 5 years, please check your team's capabilities and estimates. If you require a planning horizon up to 30 years, please contact Atlassian Support.