Auto-scheduling issues

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

Before you start auto-scheduling work for your teams, it's important to note that the auto-scheduling functionality technically replaces the previous calculating functionality in live plans (versions 2.0 to 2.27).

As such, these are the following differences between the previous and the current functionality:

Technical details Live plans (versions 2.0 to 2.27) Plans with the improved interface
Scheduling unestimated issues

If an unestimated issue is assigned to a release, the scheduler will use the dates of this release to schedule the issue by default.

You can configure how to schedule unestimated issues in a live plan.

By default, the scheduler uses target dates to schedule unestimated issues, and the issues will be scheduled to last the duration of their target dates.

For unestimated issues that are assigned to any sprint, release, or team, the values for these will persist regardless of the auto-scheduled settings that you've configured.

Sprints, teams, and releases These can be ignored for explicitly marked issues. These can be ignored, depending on how auto-scheduling settings are configured.
Maximum people assigned per story You can configure how many people can be assigned to a story. Only one (1) person can be assigned to a story.
Plan time zone Depends on how it's configured in the plan. The available options include plan time zone, system time zone, or coordinated universal time (UTC). UTC is always used in the improved interface.
Earliest start date, resource assignments, stages, and skills All of these are taken into account when issues are calculated.

These details are no longer available in the improved interface, and have no impact when issues are auto-scheduled.

Resource join date, leave dates, and availabilities All of these are taken into account when issues are calculated. These details are no longer available in the improved interface, and have no impact when issues are auto-scheduled.
Auto-scheduling of programs The calculation of each plan aggregates into the program level. The program's schedule is derived from the target dates, sprints, and releases of each plan in the program.

Auto-scheduling in the improved interface

In the improved interface, you can choose to:

  • manually schedule work, by dragging and dropping schedule bars in the timeline
  • automatically schedule work, by letting Portfolio for Jira schedule your work automatically, based on known issue details. The auto-scheduled changes will be displayed in purple stripes as a preview. You can choose whether or not to accept these changes — and if accepted, the changes will then be implemented in your plan.

When auto-scheduling the issues in a plan, Portfolio for Jira considers several factors to come up with the ideal schedule for your teams:

  • how your teams work, i.e. in sprint iterations (Scrum), or in a continuous flow of daily tasks (Kanban)
  • for Scrum teams, the sprint assignments of the issues in the plan
  • the sequence of issues, based on start and end release dates
  • the ranking of the issues in the backlog
  • the dependencies between issues in the backlog
  • the number of members in your team, which determines how much work can be completed in parallel

Sample plan, with issues not yet auto-scheduled

Configuring the auto-scheduling settings

You can further configure the auto-scheduling settings, by choosing:

  • which fields (from sprintsreleases, and teams) can be overwritten with auto-scheduled values,
  • and how these fields will be overwritten with the auto-scheduled values, i.e. only empty fields or all fields will be overwritten.

Sample auto-schedule settings

In the example above, when you're auto-scheduling your plan, you're allowing the auto-scheduler to overwrite the values for the sprints and releases of the issues all the time. However, the auto-scheduler can overwrite team values only for issues that have no teams specified for them. Once you've configured your auto-schedule settings, you can then preview the changes being suggested by clicking Preview results.

Note that if an issue is unestimated, and it's currently assigned to a sprint, release, or team, these values will not be overwritten, even if you choose to overwrite all issue values for your auto-schedule settings.

Auto-scheduling a plan

  1. Above the timeline section of your plan, click Auto-schedule.

  2. Configure the auto-schedule settings as needed.
  3. Click Preview results. This will display a preview of the auto-scheduled changes that Portfolio for Jira is suggesting for your plan.

    Sample plan, with auto-scheduled issues being displayed in a preview

    Note that in the timeline section, the schedule bars of the auto-scheduled items will appear in purple stripes. Similarly, in the fields section, the corresponding issue details will also appear in purple stripes, of a lighter shade.

  4. Review the auto-scheduled changes more closely by hovering on each change, to see the current value saved in Portfolio, and the new value that will be saved in both Portfolio and Jira, if the changes are accepted.

    Comparing current values and new values

    In the example above, three (3) values will be auto-scheduled for the issue — target start daterelease, and sprint. If you accept the changes, the new values will be updated in your plan.
  5. Perform one of the following actions:
    • To save the changes in your plan, click Accept changes. Note that these changes are just saved in your plan, and are not yet saved in Jira. See Saving changes in Jira to know more.
    • To discard the changes, click Cancel. The changes will not be saved in the plan, nor saved in Jira.
  • While Portfolio for Jira is auto-scheduling the issues in a plan, you won't be able to review any changes that have already been made.
  • You also cannot review changes when you're previewing the results of auto-scheduling until you either accept or cancel the suggested changes.
  • If you've chosen to overwrite any values for sprints, releases, or teams, these values will be overwritten except for issues that are in a currently active sprint.
  • The number of auto-scheduled changes that you're previewing will depend on the filters that you've set up for your plan. For example, if you've set the hierarchy range from stories to sub-tasks, then any auto-scheduled changes specific to epics will not display.

    This applies to any filters that you've configured, such as filtered releases, teams, projects, statuses, and so on. We recommend clearing all filters when auto-scheduling your plan, to ensure you're seeing all of the auto-scheduled changes.

Notes when auto-scheduling issues

Jump to the following sections, depending on the type of team you have, and the estimation unit you're using:

For Scrum teams using story point estimation

  • Portfolio will schedule issues into the corresponding sprints, based on team velocity, sprint length, and the story points of the stories themselves.
  • The following default values will be set, though you can change these as needed:
    • Team velocity: 30 story points
    • Sprint length: 2 weeks
  • When auto-scheduling work, the team's capacity will be treated in a more precise way. Portfolio will break down the story point estimates, and then assign work to days based on how much free capacity there is in each day.
  • Any issues that don't fit into a sprint will then be assigned to the next future sprint in the timeline.
  • You can drill down in the capacity details by clicking the capacity bar of the sprint. See Grouping by teams to for more details. Note that the precise allocation of capacity (as you see in how issues are scheduled in the timeline) will not be reflected in the capacity details.
  • If an estimated epic is scheduled across multiple sprints, the proportion of the epic in each sprint will be aggregated to the relative capacity. For example, you have an epic that's estimated with 30 points, and it equally stretches across 2 sprints. Each sprint would then be allocated with 15 points. This also takes into account projected future sprints.
  • If you're auto-scheduling work frequently, we recommend that you estimate issues only at the story level, and that you show rolled-up values in your plan. This avoids any duplicate values that the scheduler might take into account when auto-scheduling the issues.

For Scrum teams using time-based estimation

  • Portfolio will still schedule issues into the corresponding sprints, based on the team's weekly capacity, and the estimation of the stories themselves.
  • The team's weekly capacity is set to 200 hours by default. You can change this as needed.
  • When auto-scheduling work, the team's capacity will be treated in a more precise way. Portfolio will break down the time-based estimates, and then assign work to days based on how much free capacity there is in each day. For example, if ABC-123 has an estimate of 6 hours, and there's only 2 hours of free capacity for 27th May 2019, then Portfolio will schedule 2 hours on 27th May, and 4 hours on 28th May.
  • Any issues that don't fit into a sprint will then be assigned to the next future sprint in the timeline.
  • You can drill down in the capacity details by clicking the capacity bar of the sprint. See Grouping by teams to for more details. Note that the precise allocation of capacity (as you see in how issues are scheduled in the timeline) will not be reflected in the capacity details.
  • If you're auto-scheduling work frequently, we recommend that you estimate issues only at the story level, and that you show rolled-up values in your plan. This avoids any duplicate values that the scheduler might take into account when auto-scheduling the issues.

For Kanban teams using time-based estimation

  • Portfolio will schedule issues on a per day basis, based on the team's weekly capacity, and the estimation of the stories themselves.
  • The team's weekly capacity is set to 200 hours by default. You can change this as needed.
  • When auto-scheduling work, the team's capacity will be treated in a more precise way. Portfolio will break down the time-based estimates, and then assign work to days based on how much free capacity there is in each day. For example, if ABC-123 has an estimate of 6 hours, and there's only 2 hours of free capacity for 27th May 2019, then Portfolio will schedule 2 hours on 27th May, and 4 hours on 28th May.
  • At this time, clicking the capacity bar will only show the number of days or hours that are booked for that weekly iteration.
  • The precise allocation of capacity (as you see in how issues are scheduled in the timeline) will not be reflected in the capacity details.
  • Even if work seems to be scheduled during weekends, weekend hours aren't really taken into account when issues are auto-scheduled. This is just because work for an issue goes over the work week, and will be completed in the next week.
  • If you're auto-scheduling work frequently, we recommend that you estimate issues only at the story level, and that you show rolled-up values in your plan. This avoids any duplicate values that the scheduler might take into account when auto-scheduling the issues.
最終更新日 2019 年 7 月 28 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.