JIRA Portfolio, an Agile Project Portfolio Management Plugin Hands-on Review:
In this excellent JIRA series, we learned how to use JIRA effectively for managing Agile projects in our previous tutorial.
Portfolio for JIRA is the latest release of Atlassian’s Agile Project Portfolio Management plug-in for JIRA. Its purpose is to facilitate the management of a portfolio of JIRA projects.
It provides a constantly updated, real-time view of progress across multiple teams and projects within an organization, allowing managers to have an up to the minute view on whether or not work is on track to meet release dates.
=> Click Here For Complete JIRA Tutorials Series
It also provides a sandbox environment that can be used to assess the impact of change within a project on release timelines without actually making those changes to the referenced projects.
In this tutorial, I’ll take you through the background of Portfolio for JIRA and discuss, among other things, how Portfolio assigns resources, uses team availability and the four steps you need to take to create a portfolio plan.
What You Will Learn: [hide]
Portfolio for JIRA background
The first release of JIRA Portfolio, first available within the Atlassian Marketplace (Atlassian’s version of an Appstore for their applications) back in May 2014, provided users with a plan that gave visibility over a large number of projects and teams within JIRA – a “portfolio plan”. This allowed managers to plan out work across multiple projects, and allocate work so that timelines were maintained and release dates were met.
However, whilst the key concepts were in place, the synchronization between portfolio plans and the JIRA projects they were made from had to be maintained manually, which made it very difficult to keep portfolio plans up to date. This meant that very quickly portfolio plans would become out-of-sync with the projects that they represented, and the portfolio plans would no longer provide a realistic view of how projects and teams were progressing.
The latest version has been specifically designed to integrate with JIRA Software in such a way that a portfolio plan always reflects the true state of the projects that it represents. Data is gathered from a select scope of JIRA issues, which can be based, as required, on Projects, Boards or Filters.
This data is continuously fed into the portfolio plan so that it is always up to date with the latest changes to the scope. This includes data such as time estimates for JIRA issues, dependencies between issues, and when teams are available to work on particular issues.
Figure 1: The ‘Schedule’ view for a Portfolio plan, showing the timelines for multiple projects, with JIRA issues mapped against this timeline.
Portfolio assigns resources using a unique scheduling algorithm that builds in any priorities and deadlines set by the user against scope items.
Values of different properties associated with JIRA issues can be set to a defined value which will not be changed by the algorithm or set as ‘Calculate’, allowing the scheduling algorithm to change the value of the parameter in order to meet the given release timeline.
The releases themselves also have this flexibility, allowing Portfolio to calculate a release date based on when the selected scope of work is completed, as opposed to setting a strict release date that needs to be hit.
Note that if the scheduling algorithm proposes a change to a JIRA project, the change must be confirmed (“committed”) by a Portfolio user with the relevant permissions. Changes cannot be made to underlying JIRA projects in an uncontrolled way.
Figure 2: Changes are only made to the underlying JIRA projects and issues when they are committed back to JIRA, preventing changes from being made in an uncontrolled way.
Changes to Issues can also be made by the user from within the Portfolio plan, but a specific “commit” of those Portfolio-level changes is required to make them flow through to JIRA. This prevents project managers on the ground from seeing their projects being mysteriously updated without there being a clear opportunity for users at Portfolio level to keep them informed.
Further, it allows Portfolio for JIRA 2.0 to act as a sandbox environment, where changes can be made to issues at the Portfolio level and their impact on release timelines, etc. assessed before transmitting the changes on to all those working on the projects. In other words, it allows the running of “what if” scenarios.
Creating portfolio plans
Creating a portfolio plan is simple, being made up of only four steps.
Firstly, the scope is defined by selecting the projects, teams or filters to be used to gather issues from which the scope will be defined. Multiple options can be used at this point. Releases associated with those options are then selected to define which releases will be included in the plan.
Next, the teams to be included in the plan are selected, and a default team will be created for each project.
Finally, the issues relating to the selected releases are listed, allowing the user to pick out which issues they want to include in the scope of the plan. Once this is completed, Portfolio uses its scheduling algorithm to create a portfolio plan based on data relating to the selected issues.
The portfolio plan is presented with a Schedule view with three tabs that represent the data used to create it; Scope, Teams, and Releases.
The Schedule can be viewed persistently against all three tabs, or separately as a Report on its own page. Changes on any of the three tabs can be seen on the Schedule view and assessed before they are committed to JIRA.
A timeline is shown with issues placed against it over time, with a simple colour coding design used to show whether or not a release is on track; the line is green if it is on track, and is red if the release date is not going to be met.
The specific dates for the release date and completion date are shown on the timeline, allowing users to see where gaps lie and how large the gap is between completion and release. This view can be configured in a number of different ways to show a breakdown of projects, teams or users, as well as a number of other useful views.
Currently, there is no clear indication on the Schedule view where the release date based on the scope comes close to the expected release date.
As well as being able to see how work is scheduled over time within projects, Portfolio for JIRA also presents this information in a ‘Capacity’ view for the teams to which the work has been allocated.
This view shows what the available capacity of all teams included within the Portfolio plan is, highlighting the number of hours those teams have assigned to them in a particular week or sprint, depending on the Agile methodology being used, as well as showing the utilization of those teams and where available capacity and potential bottlenecks may lie.
Figure 3: The ‘Capacity’ view for a Portfolio plan shows the allocation of work to teams across the plan. Highlighting particular sprints or weeks shows the team utilization statistics, including bottlenecks and free capacity.
Portfolio for JIRA uses team availability, and the skills of members of those teams, in order to further refine the release schedule. When teams are set up users within JIRA can be added into them and allocated particular skills depending on what their role might be.
For example, a team of developers could be allocated skills based on the knowledge they possessed of different programming languages. The portfolio uses this to assign tasks not only to teams but to particular members of teams who have the skills required to complete those tasks. These skills are what Portfolio uses to define where bottlenecks may exist, and help to clarify where additional resources may be required to meet release dates, however, it is not always clear how significant the bottlenecks could be.
The Teams created within one plan can also be shared with other plans using ‘Shared Teams’. This saves time when creating plans by bringing in information relating to those teams such as the skills previously discussed.
The portfolio allows teams working on the same project to work using different methodologies, and breaks down the schedule accordingly; a team using Scrum will see tasks assigned to sprints, whilst a team using Kanban will see tasks assigned based on priority and time estimates.
The ‘Schedule’ view then allows this to be filtered in a number of different ways, using a very similar filtering tool to that used within JIRA for the Issue Navigator.
Figure 4: Teams can be created with skills set against particular team members, allowing the scheduling algorithm to assign tasks specifically to users who have the skills to complete that task.
With multiple projects displayed within a single portfolio plan view, users may define dependencies between projects, whether they be on the teams using those projects or requirements for particular activities to be completed before others can start.
Portfolio for JIRA brings in dependencies that already exist in JIRA, whilst allowing new dependencies to be added via the ‘Scope’ view. These dependencies can be clearly seen in the ‘Schedule’ view by clicking on one of the issues to which it relates, and seeing the related issues also highlighted within the Portfolio plan.
Whilst Portfolio for JIRA brings in information about releases already available within projects, new releases can also be defined from the plan view (i.e. at Portfolio level, potentially spanning more than one project), and thus cross-project releases can be created. This allows work between different projects to be scheduled such that all work is completed to a shared deadline.
Portfolio handles this by creating individual releases within each project that are linked together with a shared schedule.
A single source of truth
Portfolio managers need to be able to quickly view and analyse the progress of all of their teams and projects across an organisation, regardless of the complexity of the organisation or projects within, and Portfolio for JIRA 2.0 delivers this.
It provides a single source of truth for managers to work out the most efficient way of deploying work to teams. The biggest improvement with the latest release is the removal of the requirement for a manual synchronisation with JIRA projects, making sure that portfolio plans are always a realistic assessment of progress within projects and the likely timescales that will be met.
