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.
  • バックログ アイテム間の依存関係
  • 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

Schedule recalculation default mode

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.

 

How to configure the manual scheduling mode

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.

この場合、リリース割り当てが "計算" に設定されているバックログ アイテムは、それぞれの優先度のランクに応じてリリースに自動的に追加されます。 

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.

割り当ての計算と静的な割り当て

The following fields can either be assigned statically, or suggested automatically by the scheduling algorithm: 

  • リリース - 手動: "このアイテムはリリース X に同梱します"、自動: "どのリリースに最適でしょうか?"
  • チーム - 手動: "このストーリーはチーム A が実装します"、自動: "スキルとキャパシティに基づいて最適なチームはどちらでしょうか?"
  • メンバー - 手動: "ピーターとサラ、または彼らの両方がこれに取り組みます"、自動: "スキルと空き状況に応じ、X、Y、または Z がこのストーリーに取り組むことが望ましいです"

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.

最終更新日 2018 年 6 月 15 日

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

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