High-level planning
This page refers to Portfolio classic plans. If you are currently running Portfolio 2.0, please check this link to access the latest page version.
With Portfolio for Jira, you can quickly and realistically plan and scope releases with help of the automatic scheduling feature
When can I ship a particular feature and who is building it?
As soon as an epic or story is scheduled, you can simply click it in the graphical schedule to see exactly when it's scheduled to start and be completed.
Another good way of taking a closer look at how a simple item is scheduled is by using search to filter the view to just the single item you are interested in. From there, use the different views to get all the details you need.
Example: in case of an epic break it down into a view per team, or even per member, to see who is scheduled to work on an item.
Capacity planning - what can I still fit into a sprint or release?
If your release is still green, on track and not overbooked, the release view is the best way to figure out how much capacity you could still fit in.
In the high-level view per release, you see the total number of days / hours that are still free in the release period and the top 3 free capacity skills are shown.
If your team(s) work with iterations, choosing "Sprints" allows to drill down even further. Let's look at the sprints, and filter additionally to release 1.0.
We can see that particularly the third team has a low resource utilization at this point, whereas the other teams are mostly booked. Looking at the free capacities for these sprints reveals, that capacities for testing and mobile app development are available. However, UI/UX Design is a bottleneck, so you could add development tasks, but if they require more design, it would potentially delay the release.
Reconfiguring an overbooked releases
Let's assume you have a fixed end date, and also assigned a desired scope, which did not fully fit in until your targeted release date. In this case, the release turns red, into the "overbooked" status.
A good way to investigate and decide what to take out from the release, is filtering and checking which stories are scheduled after the targeted release date. The stories view works best for this. In the example, we see that exactly two stories "Something with cloud" and "Make it faster" are scheduled after the release date. So these would be the candidates to postpone in order to keep the release date.
However, it's also helpful do do a quick sanity check on resource utilization: In this case we see, there there are actually plenty of free capacities for The Professionals in the first two sprints (10 days in sprint 1, 14 days in sprint 2 - so capacity wise, the two stories could fit in).
The bottleneck in this case is UI/UX design: there's not sufficient design work completed to use the available resources.
In practice, there's different ways to address such a scenario. One way is to split up the stories, maybe also into parts where someone else can take over design work, or where no design is needed so that they can be implemented already in sprint one. The key is to have transparency on such bottlenecks, to make good decisions on how to address them case by case.
Addressing bottlenecks
In practice, there's different ways to address such a scenario. One way is to split up the stories, maybe also into parts where someone else can take over design work, or where no design is needed so that they can be implemented already in sprint one. The key is to have transparency on such bottlenecks, to make good decisions on how to address them case by case.