課題のスケジュール

このページの内容

お困りですか?

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

コミュニティに質問

Scheduling issues is as easy as adding the duration for issues directly in your timeline. Alternatively, you can add target dates for the issues, and these dates will display in the timeline section accordingly.

Note that you need the Portfolio for Jira user permission to save scheduling changes in Jira.

1

Set the duration of work for an issue

  1. タイムライン セクションで、期間を設定する課題のを見つけます。
  2. 行にカーソルを合わせ、+ アイコンと課題の期間が表示されるのを待ちます。
  3. Click the row to add in the duration for the issue.
    (info) Note that the default duration for issues would depend on the timeframe in which you're viewing the plan:
    • 3M: 1 週間
    • 1Y: 1 か月
    • Fit: The default duration depends on the date range of the issues in the timeline, which in effect, affects the width of the issues in the timeline. If the width fit is small, then the default duration could perhaps be a week or a month.
    • Custom: The default duration depends on the duration that you set between the start and end dates. If you set a short period of time, then the default duration would be shorter as well.
  4. 次のように変更を保存します。
    1. [変更をレビュー] をクリックします。[変更をレビュー] ダイアログが表示され、既定ですべての変更が選択されます。
    2. 必要な変更に関するチェックボックスが選択されているのを確認してから、[選択した変更を Jira で保存] をクリックします。

    You need the Portfolio for Jira user permission to save changes in Jira.

2Set the target dates of an issue
  1. In the scope section, find the issue that you're setting target dates for.
  2. Set the target start date and target end date for the issue. This will create a schedule bar for the issue in the timeline section.
  3. 次のように変更を保存します。
    1. [変更をレビュー] をクリックします。[変更をレビュー] ダイアログが表示され、既定ですべての変更が選択されます。
    2. 必要な変更に関するチェックボックスが選択されているのを確認してから、[選択した変更を Jira で保存] をクリックします。

    You need the Portfolio for Jira user permission to save changes in Jira.

課題からすばやく日付を削除するには、日付の横にある "x" アイコンをクリックします。

3Monitor the status of releases

While scheduling work for your team, we recommend you keep track of the status of the releases in your plan.

Click one of the release icons in the timeline section, to view more details about the release.

Sample release icons and details

  • You can click on the left and right arrows at the top of the release details, to jump from one release to another.
  • The icons stay green while the release is on track. At any time a release becomes off track, the icon turns red.
  • You can highlight any release that's off track on the timeline. This makes it easier for people to spot these releases on the roadmap.
  • When a plan is auto-scheduled, a release that's off track will also display by how much time it's off track. Make sure to check the details of off track releases so you can fix this accordingly.
  • When you're filtering the issues in your plan using releases, the release icons in your plan will also be filtered. See Filtering issues for more details.

You can also use the releases view to monitor all the releases in your plan.

  • In the improved interface, Coordinated Universal Time (UTC) is always used when handling the dates of issues. This is different from Portfolio for Jira live plans, which use system-enabled dates.
  • Depending on how dates are configured in Jira, the dates may sometimes vary across Portfolio for Jira and Jira. This means that an issue's dates in Portfolio for Jira may be different from its dates in Jira.
  • 子課題のスケジュール時に、これらの課題の開始日と終了日はその親課題の日付にロールアップされます。実質的には、これは次のことを意味します。
    • 親課題の開始日は、すべてのその子課題の最も早い開始日になります。
    • 終了日はすべての子課題の最も遅い終了日になります。
  • It's important to note that the change in ranking behavior can produce different scheduling results between live plans (any version from 2.0 to 2.27) and plans with the improved interface (version 3.0 and later). For example, even if issues are placed in the same order across both types of plans, the resulting scheduling results between these types of plans will be different.

    See Prioritizing issues to know more.

Rescheduling issues

To reschedule issues, do one of the following actions:

  • Drag and drop the schedule bar of an issue to its new schedule.
  • Edit the duration of an issue by dragging one of the sides of the schedule bar accordingly.
  • Change the target dates of an issue in the fields section.

スプリントに従った課題のスケジュール

Before you begin, note that this only applies to issues sourced from Scrum boards and when issues are assigned to Scrum teams.

When a team and a sprint are set for an issue, the target start and end dates of that issue are automatically derived from the assigned sprint.

Sample plan, with target dates of issue aligning with sprint dates

  • You can still change the target dates of an issue if needed, even if the target dates are automatically derived from the assigned sprint.
  • If you reschedule an issue and its target dates no longer match the dates of the assigned sprint, this will not change the sprint assignment.

Caveats when scheduling issues according to sprints

There may be times when sprint data can't be loaded, either accurately or completely, into a plan, and this can be due to several factors:

1The issue sources being used by the plan are not boards

If a plan has multiple issue source types, sprint data will only be displayed for the issues that are sourced from boards. Issues sourced from projects or filters will not display any sprint data in the roadmap.

There's no workaround for this. The only way to display sprint data is to use the corresponding boards as issue sources for the plan.

2課題がプランに存在しないスプリントに割り当てられている可能性がある
  • If this is the case, then the sprint value for the issue in the plan will be assigned to sprint not in plan.
  • This issue may be included the plan because the project that it belongs to is one of the issue sources configured for the plan.
  • Ideally, the issue source should be the Scrum board in which that external sprint was created. This way, sprint data can be reflected accurately in the plan.
3同じスプリントが 2 つ以上のスクラム ボードに表示されている可能性がある

Depending on the number of sprints on each board, the common sprint could have different dates on the timeline. This only happens for future sprints, since sprints are not given any dates until they become active.

For example, we have 2 boards, Board 1 and Board A, and we have Common sprint appearing on both boards. Both boards have Scrum teams associated with them, and these teams work on 2-week iterations. Both teams also have an active sprint.

どちらのボードにも、次の将来のスプリントがあります。

  • Board 1: Sprint 2, Sprint 3, Common sprint, and Sprint 4
  • Board A: Sprint B, Common sprint, Sprint C, and Sprint D

With the above conditions, when you group issues by team and show capacity on the timeline, Common sprint will be occurring at different times in each team swimlane:

  • ボード 1 の場合、アクティブなスプリントが完了した 4 週間後 (その前に 2 つのスプリントがあったため)
  • ボード 2 の場合、アクティブなスプリントが完了した 2 週間後 (その前にスプリントが 1 つのみあったため)

This inconsistency will just happen while Common sprint is a future sprint. Once it becomes an active sprint, the dates will resolve themselves across the team groupings on the timeline.

詳細を確認...
  • Jira では、将来のスプリントの日付を設定することはできません。将来のスプリントは、それが開始されたときにのみ、その日付を取得します。つまり、本質的には、これらはアクティブなスプリントになるまで、スプリントは任意の日付を取得しません。
  • 制御できるのは、将来のスプリントの順序、つまり Jira ボードに将来のスプリントを並べる順序だけです。
  • Portfolio for Jira will try to infer when future sprints will start in the timeline, based on the configured iteration lengths of each team, and the list of sprints for that team's board. Because of this, Common sprint will appear with different dates on the timeline, for both boards.
4Two (2) teams share the same sprints, but the teams have different iteration lengths configured

This is related to caveat #2 — the only difference is that it's the iteration length configured for the teams that is inconsistent.

For example, you have 2 teams, Team 1 and Team 2, and they're both working on Common sprint in their respective Jira boards, and both boards also have an active sprint.

チームは、次の条件で作業します。

  • Team 1 works in 2-week sprints in this sequence: Sprint 2, Common sprint, Sprint 3
  • Team 2 works in 4-week sprints in this sequence: Sprint A, Common sprint, Sprint B

Even if Common sprint is the 2nd sprint in the sequence for both team boards...

  • For team 1, Common sprint will be given a 2-week length
  • For team 2, Common sprint will be given a 4-week length
最終更新日: 2019 年 12 月 30 日

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

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