Scheduling issues
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.
| 1 | Set the duration of work for an issue |
|
| 2 | Set the target dates of an issue |
To quickly remove a date for an issue, click the x icon next to the date. |
| 3 | Monitor 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 also use the releases view to monitor all the releases in your plan. |
Note that the default duration for issues would depend on the timeframe in which you're viewing the 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.
- When scheduling child issues, the start dates and end dates of these issues roll up to 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.
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.
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.
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
Additional notes:
- 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.
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 EXTERNAL SPRINT lozenge right next to them. The lozenge is used to indicate that the sprints 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. In that board, the Koala sprint is currently active, and is running for 2 weeks, starting from 23 June 2019.
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. - Also because of #1, Portfolio will also display the Koala sprint is an
external sprintfor the corresponding issues. - In the plan, you can reassign the sprint value, even for 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 an external 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. |
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:
| 1 | The issue may be assigned to a sprint that's not in the plan |
|
| 2 | 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:
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:
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. |
| 3 | Two (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. The teams work in the following conditions:
Even if Common sprint is the 2nd sprint in the sequence for both team boards...
|