Now that you've created your plan and added some issues for your team, it's time to start thinking about how best to schedule these issues for your team.
Issues are typically scheduled by the scheduling algorithm of Portfolio for Jira. The algorithm considers several issue details, to automatically create a sensible timeline of the work that's relevant to you. With the algorithm, it's easier to spot bottlenecks — this gives you a chance to handle these potential problems even before they happen. As handy as the algorithm can be, you don't really see how it works out your schedule. Ultimately, you're only given the resulting schedule.
With experience and product knowledge, let's say that you know that an issue should be scheduled earlier than what has been plotted by the algorithm. To get the algorithm to schedule the issue the way it should be scheduled, you'd need to experiment around by changing some issue details.
In the new experience, you can now quickly drag and drop the position of an issue in the timeline, to schedule work your way. You’ll no longer have to guess what you should do, to get issue NPE-3 scheduled on 6 November 2018.
When scheduling work for your team, you may need to do any of the following at a given time:
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.
Set the duration of work for an issue
|2||Set the target dates of an issue|
Note that if you set dates for issues that conflict with the dates of their corresponding parent or child issues, you'll explicitly get a warning message for it. This makes it easy for you to quickly fix any dates that may have been mistakenly updated.
Sample warning, when a child issue starts before its parent
|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
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.
To reschedule issues, do one of the following actions:
- Drag and drop the schedule block of an issue to its new schedule.
- Edit the duration of an issue by dragging one of the sides of the schedule block accordingly.
- Change the target dates of an issue in the fields section.
To prioritize work for your teams, you can move an issue to a higher or lower row in the scope section. This moves the position of the issue in both the scope and timeline sections.
For instance, in the sample plan below, you can move TIS-126 from issue row #6 to issue row #3. This way, the top 3 issues in the scope section will all have the same target start date of 30 June 2018.
Prioritizing issues in the new planning experience
- In the scope section, when you move an issue that has child issues, the child issues will move with the parent issue. However, moving an individual child issue will only move that child issue.
- The ranking of child issues is independent of the ranking of their parent issues. If you rank a parent epic higher, the ranking of its child issues in Jira will stay as is. This is helpful, especially if your teams have ranked their issues in their Jira boards — the child issues will retain their ranking as is.
Optimizing work for your team
In the new planning experience, to schedule work for your teams, you can choose to:
- manually schedule work, by dragging and dropping schedule blocks in the timeline
- automatically schedule work, by letting Portfolio for Jira optimize your work based on known issue details
Note that when you're planning work in the new experience, you can do both manual planning and optimized planning — it's not meant to be one method or the other. For example, during the early, high-level planning stages, you can start by manually creating and scheduling issues in your timeline. Later on, when your teams start adding more accurate dates and estimates to their work in Jira, you can then optimize your plan, to see if your high-level dates make sense.
Optimizing a plan
When optimizing a plan, Portfolio for Jira goes through the following scheduling factors, to create a schedule for your team:
- Sprints assigned to the issues
- Releases assigned to the issues
- Target start and target end dates of the issues
- Estimates provided for the issues
- Any dependencies that the issues may have
- The ranking of work items in the scope table
- Team schedules, e.g. working in either sprint iterations, or in a continuous flow of daily tasks
Sample plan, with issues not optimized yet
To optimize a plan:
Above the timeline section of your plan, click Optimize. This will display a preview of the optimized changes that Portfolio for Jira is suggesting for your plan.
Sample plan, with optimized changes
Note that in the timeline section, the schedule blocks of the optimized 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.
- Review the optimized 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, two (2) values will be optimized, the target start date and target end date. If you accept the optimized changes, the new values will be updated in your plan.
- Perform one of the following actions:
- To save the optimized 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 optimized changes, click Cancel. The optimized changes will not be saved in the plan, nor saved in Jira.