Scheduling
This page refers to Portfolio classic plans. If you're using Portfolio 2.0 and later, please check this section for frequently asked questions about Portfolio live plans.
We've gathered some frequently asked questions about scheduling in Portfolio for Jira below.
How does the scheduler work?
In brief, it takes the priority-ranked backlog, available resources, release dates, dependencies and other constraints and figures out an optimized selection of resources for each backlog item in order to finish the highest priority items as fast as possible. Here are some more details on it: Recalculating the schedule.
Is the dynamic schedule algorithm user configurable?
There are several configuration parameters available in the plan settings, such as the number team members that can work simultanuously on a single story, or how stages are scheduled. These settings control the most significant input parameters to the algorithm.
Epics and Stories
How does the scheduler know which skills are required for a story?
When specifying a total estimate, this estimate will be split up into efforts for each stage and skill based on the percentages configured in the plan settings. Additionally, the estimates column in the backlog table can be expanded, and instead of entering a total estimate, you can enter estimates for the specific skills that are required for a story.
Is an estiamate required for every story and epic in order to get accurate forecasting?
Yes, currently Portfolio for Jira only considers backlog items that have an estimate. In practice, in some cases this means entering (time) budgets and not real estimates, as you might not have enough details yet to provide a realistic estimate. Either way, a value is required in order to book the resources accordingly.
Do you need to specify start dates on every story and epic?
No, start dates are computed automatically based on the estimates and available resources. This is where the automatic scheduling algorithm does the heavy lifting for you.
Sprints
How do you model a release sprint, regression or stabilization effort inside a release date being calculated?
There are different options to achieve this goal.
- Put a placeholder epic with an effort estimate to represent the stabilization effort. You could size it in such a way that it fills out the capacity for a full time for a sprint. You might have to work with dependencies or an earliest start date constraint to ensure the capacity is reserved only after the other work is done.
- Another approach is modify the start date of the next release to leave a time buffer inbetween, i.e., the subsequent release starting 2 weeks after the end of the previous release.
Any plans for sprint capacity planning? I'd like to know where my resource bottlenecks are during a given two-week iteration. Jira doesn't do that natively and as a result I have to create a capacity plan in Excel.
Portfolio for Jira should be able to help you with that today. It might be a bit counter-intuitive since you work in sprints, but in order to plan exact capacities on a day to day basis you would have to switch the team to Kanban mode (in the people section, team schedule column). You could use releases to represent sprints instead. This will give you a day-to-day plan within your sprints to see how people are allocated.
Jira Integration
Please provide some more detail on how Jira figures out how long a story/epic is going to be.
The calculated duration is based on the effort estimate you enter into Portfolio for Jira and the available capacity of the assigned team(s) and members. So if a work package has an effort of 10 days, and 2 people are scheduled to work on it, the duration will be 5 days. However, bear in mind that when scheduling in sprints, the graphical schedule always shows the work item from the start to the end of the completed sprint, even though it takes only few days within the sprint. This is because at this granularity level, Portfolio for Jira only matches the total capacity within a sprint, but not a day-to-day plan within a sprint itself. If this is required, teams need to be switched to Kanban mode.
People and Teams
I need to manage a mixture of teams. Can Portfolio for Jira be used for teams that don't use sprints? How can it help Kanban or waterfall teams?
Yes, in the people tab it is possible to switch teams to a kanban / continuous day-to-day schedule. Different teams can have different settings, i.e., it is possible that some teams work in Scrum mode, and others in Kanban or with traditional methodologies. Common to both modes is that the scheduling algorithm always focuses on finishing individual work items completely before starting new ones. This means that in Kanban mode, when design of a story has started, the first the implementation if it will be scheduled before starting design work on another new feature (unless of course there is sufficient capacity to do it in parallel).
All of our teams don't follow the same sprint intervals, is that configurable?
Yes, in the people tab, there is a column called "Team schedule". If you drop down this value for a team, you can configure the sprint interval.
Can multiple users be assigned to the same story through Portfolio for Jira?
Yes, Portfolio for Jira allows multi-assign on stories. The maximum number of people that will be assigned to a single story is configurable in the settings.
When you assign an initiative to multiple teams, does it assume that all teams will work on it, or that the initiative can be picked up by any of the selected teams? For the latter, could Portfolio for Jira suggest the best team(s) to work on the initiative?
Currently there are two options for team assignments: (a) assign exactly one team, then this one will work on it exclusively, or (b) don't assign a team at all, in this case Portfolio for Jira will suggest the best team(s) to work on it, based on who can deliver it the fastest. In case of epics, multiple teams will be assigned if possible, a story is always assigned to a single team.
Can you specify people starting work ahead in time (future capacity)?
In a way, the whole scheduling is focused on future capacity planning. If you put in an effort estimate and available capacity of a resource in a timeframe, this work item will be automatically scheduled into this future capabity block. You can use an earliest start date constraint to define if items can only start after a certain point in the future. What you cannot do currently is to specify a targeted start and end date manually for a piece of work - start and end dates are always forecasted dynamically based on the resources and constraints.
If the team that works on a specific initiative is not important, can Portfolio for Jira suggest the best team(s) to assign to that initiative based on the schedule?
Yes, if you don't assign a team manually, Portfolio for Jira will make an automatic assignment and suggest the team(s) who can deliver it the fastest.
General
If you have dependencies, and you change the dates, will all dependencies update automatically?
Yes, if there are dependencies between work items and any of them changes in the schedule, the others are automatically adjusted.
How I can change the release period?
In the releases tab you can enter releases, and define start and end dates (either fixed or dynamic/relative dates) for each release. In addition, in the people section you can configure the sprint cadence for each team (e.g. 2 week sprints or 3 week sprints)
What would be the best approach to model fixed duration tasks? E.g. having a test phase of 4 weeks that is done by external testers, not part of your team? I would rather not have to create virtual people to model the testers.
There are two options to do this: Either use a release for this time period (and don't bother too much about time capacity within this release, instead use it to make sure the dependent work in the next release/phase does not start too early), or you could also put in a blocker epic for the external testing effort, and use an earliest start date constraint for the time it is being delivered. Using an earliest start date is a bit counter-intuitive, but it basically means that since the blocker item does not have any efforts, it can both start and finish on that date, and you can set a dependency from other epics waiting on this testing effort to be done.
Can you manually update a story map for a release? By that, I mean can I move stories around on the story map view?
No, this is currently not supported by Portfolio for Jira. Sprint assignments are determined dynamically by the scheduling algorithm based on priority and available capacity.
What's the best way to deal with interruptions (i.e. sprint impediments) in the plan? Should the team change their estimates to factor in the delay?
It depends on the desired outcome. One way is not to worry about it during the sprint, and instead do a plan update (Plan > Update from date) after the sprint to see what has actually been achieved which is probably less than what was originally planned, and after that re-plan based on the remaining effort. If you want to evaluate the impact during a sprint, the best way would probably be to put in an absence for the concerned team members to indicate they were unavailble for the desired feature work for certain days, and the schedule will adjust automatically.
Can I use Portfolio for Jira with projects with traditional methodologies, not just Agile?
Generally yes, even though the focus of the design has been on agile PPM. Nevertheless, you can, for instance, use separate releases to represent project milestones or phases, and assign work to each of the phases to ensure it happens in the proper order.
How does the calculation of multiple skills work? i.e French speaking analyst or someone who can do either design or analysis.
Every resource can have an arbitrary number of skills. For each backlog item, the person or group of people is picked who can deliver it fastest. If a single person doesn't have all the required skills, multiple people will be assigned to a story. Portfolio for Jira optimizes the allocation based on available and required skills for the items in the backlog.
How does the scheduler resolve resource conflicts with simultaneous users with shared resources?
Within one Portfolio plan, resources can never be overbooked. There is always a deterministic "winner" as to who gets a resource assigned, based on the priority in the backlog. If multiple backlog items require the same resources, the lower priority one will be pushed out in the schedule automatically until there is an open slot.