Scheduling issues
You can schedule issues by setting the duration of issues directly in your timeline, or by setting start and end dates for the issues. By default, target start and target end dates are used when scheduling and auto-scheduling issues in a plan. You can choose to use due dates and other custom dates (date picker type) to schedule issues, which helps you align your plan with how your teams work.
For a custom date to be available, make sure the custom date field is added to the schemes of all the projects associated with the issue sources of the plan. Once selected, the custom dates will be displayed with the date lozenge (
).
- Schedule bar of an issue, which you can use to schedule duration of work
- Empty target dates of an issue, which you can set to schedule duration of work
Setting the duration of an issue
- In the timeline section, find the row of the issue you're setting the duration for.
- Hover on the row until the + icon and duration for the issue appears.
- Click the row to add the default duration (for example, 7 days) to the issue.
- Optional: Click and drag either end of the newly added schedule bar to change the default duration.
- Save the changes by doing the following:
- Click Review changes. The 'Review changes' dialog will display, with all changes selected by default.
- Click Save selected changes in Jira.
The default duration applied to schedule bars is determined by the timeframe settings you have applied to the timeline. It's a suggestion only, and can be changed to any duration you like.
Setting dates for an issue
- In the scope section, find the issue that you're setting dates for.
- Set the start date and end date for the issue. This will create a schedule bar for the issue in the timeline section.
- Save the changes by doing the following:
- Click Review changes. The 'Review changes' dialog will display, with all changes selected by default.
- Click Save selected changes in Jira.
To quickly remove a date for an issue, click the x icon next to the date.
Scheduling child issues
When scheduling child issues, the start and end dates of these issues have an impact on the dates of their parent issues. Effectively, this means:
- the start date of a parent issue would be the earliest start date of all its child issues,
- and the end date would be the latest end date of all its child issues.
If you've enabled roll-up dates as an early access feature, the behavior of parent issue dates in a plan may change. See Rolling up values to parent issues to know more.
Scheduling issues according to sprints
Before you begin, note that this only applies to issues sourced from Scrum boards and when issues are assigned to Scrum teams.
Scrum teams work in sprints (or iterations), and they release incremental features of their product at the end of each sprint. When a team and a sprint are set for an issue, you can configure a plan to use sprint dates for issues that don't have any dates set yet.
Sample plan with target dates of issues aligning with sprint dates
- Even if an issue is showing its sprint dates, you can still change its dates if needed. Note that if the dates no longer match the sprint dates, this will not change the sprint assignment of the issue.
- Sprint dates will also be used when monitoring the status of releases and keeping track of issue dependencies.
When using projects or filters as issue sources
If a plan is using projects or filters as issue sources, sprint data will still be displayed for the corresponding issues.
However, since sprint data can only be directly associated with boards, then the sprints will be displaying the 
lozenge right next to them. The lozenge is used to indicate that these are external sprints, and are not directly associated with the project and filter issue sources.
Sample plan with issues assigned to external sprints
Note the following details about the sample plan:
- This plan was created with the project issue source iOS App.
- In Jira, the iOS App project has the Scrum board IOS App. The board has several sprints, including Dingo and Box Jellyfish.
When you create a plan using the project iOS App as its issue source, the following will happen:
- Portfolio for Jira is not readily able to associate any sprint data to the issues that will be included in the plan. The issues to be included in the plan will come from the iOS App project.
- Since Portfolio is not able to associate any sprint data, it will create a plan-specific team known as iOS App (IOS) Team. This means that this team is only local to the created plan. This is precisely why you'll see the issues being assigned to an
externalteam as well, the IOS app Team. - Portfolio will also display the sprints as external, with the lozenge displayed.
- In the plan, you can update the sprint values of the issues assigned to external sprints. However, any external sprint will not be available as an option when choosing sprint values.
Because of this, we highly recommend that you use boards as issue sources for your plan. This will allow Portfolio for Jira to associate any sprint data to the issues in the plan, and the sprints will no longer be displayed as external ones.
Sample plan with issues no longer assigned to external sprints
However, Portfolio for Jira will still go ahead and create the plan-specific team known as iOS App (IOS) Team, which is why the issues in the sample plan above are still assigned to the external team, IOS app Team.
You can consider the following options:
Option 1: Add the external IOS app Team to your plan
You can do this by adding the team as a shared team. Note that the external team must already be defined as a shared team in Portfolio for Jira.
IOS app Team has been added to the plan as a shared team
You'll also need to associate the newly added shared team to the corresponding issue source, so the sprint and capacity data will display in the timeline.
Option 2: Assign the issues to the plan-specific team iOS App (IOS) Team
You can assign the corresponding issues in bulk, to the plan-specific team iOS App (IOS) Team. By doing this, the issues will be assigned to a plan-specific team, and no longer an external one.
Issues reassigned in bulk to the plan-specific team iOS App (IOS) Team
You'll also need to associate the plan-specific team to the corresponding issue source, so the sprint and capacity data will display in the timeline.
Troubleshooting
There may be times when sprint data can't be accurately or completely loaded into a plan, and this can be due to several factors.
Jump to:
- The issue may be assigned to a sprint that's not in the plan
- The same sprint may be appearing in more than one Scrum board
Two teams share the same sprints, but the teams have different iteration lengths configured
The issue may be assigned to a sprint that's not in the plan
The issue may be included in the plan because the project that it belongs to is one of the project issue sources of the plan. If this is the case, then the sprint value for the issue in the plan will be assigned to sprint not in 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.
The same sprint may be appearing in more than one Scrum board
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.
Both boards have the following future sprints:
- 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:
- For Board 1, 4 weeks after the active sprint is completed, since there are 2 sprints before it
- For Board 2, 2 weeks after the active sprint is completed, since there's only 1 sprint before it
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.
Two teams share the same sprints, but the teams have different iteration lengths configured
This is related to having the same sprint appear in more than one Scrum board. The only difference is that the iteration length configured for the teams 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.
The teams work in the following conditions:
- 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.
Additional notes
How target dates work
Both target start and target end dates are handled consistently across Jira and Portfolio for Jira, and the date values are independent from local timezone settings. This means Alana from Australia and Will from the USA would see 1st October 2019 as the target end date for TIS-123 in both Jira and Portfolio for Jira.
How due dates and custom dates work
Due dates and custom dates are based on the local timezone settings of the Portfolio user. Due to their corresponding timezone settings, Alana from Australia may see 1st October 2019 as the due date for TIS-123, while Will from the USA may see this as 30th September 2019. However, Alana will see the same date value in both Jira and Portfolio for Jira, and the same applies to Will.
However, if you're using due dates and custom dates as the start and end dates in the plan, Will and Alana will see the same dates in Portfolio for Jira, and potentially different dates in Jira. The date values may be off by a day for both of them. This is because of their timezone settings, and because Jira and Portfolio for Jira handle dates differently.