This is the alpha version of Portfolio for Jira 3.0 — your sneak peek at the improved functionality that's just around the corner. As such, do note the following:
- Some features may not be complete just yet, as we're continuously iterating on these.
- Because it's an alpha version, the documentation will only be visible to you, our alpha users. You will not find any alpha pages in the usual page sidebar.
We've linked the table of contents below, so you can easily navigate to the alpha pages at any time.
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.
In 2.0 plans, issues are scheduled by what we call a scheduling algorithm. 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 some inside knowledge, let's say that you know that an issue should be scheduled earlier than what has been plotted by the algorithm. In 2.0 plans, you'd need to experiment by changing some issue details, to get the algorithm to schedule the issue your way.
In 3.0 plans, 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 PERF-5 scheduled on 16 August 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|
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 3.0 plans
- 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 now 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
You can now manually schedule work your way to come up with a realistic schedule for your teams. But this doesn't mean that the scheduling algorithm that we know is out of the picture. You can still get Portfolio for Jira to create a schedule for your teams, by optimizing your plan.
Note that manual planning and optimized planning are independent of each other. It's not meant to be one method or the other — you can actually do both when planning work.
During the early, high-level planning stages, you can start by manually creating and scheduling issues in your timeline. Later on, when your teams add 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
- Any dependencies that the issues may have
- Target start and target end dates of the issues
- Estimates provided for the issues
- Team schedules, e.g. working in either sprint iterations, or in a continuous flow of daily tasks
- The ranking of work items in the scope table
Sample 3.0 plan
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.
Optimized changes in 3.0 plans
Note the following details:
- In alpha, only the target dates are optimized. We'll be adding more issue details to be optimized in future releases.
- In the timeline section, the optimized schedule blocks will appear in purple stripes. Similarly, in the fields section, the corresponding target dates will appear in purple stripes.
- 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 value and new value in 3.0 plans
In the sample above, three (3) values will be optimized, namely target start date, target end date, and release. 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.