Standard plans Q & A
This page refers to Portfolio classic plans. If you're using Portfolio 2.0 and later, please check this section for frequently asked questions about Portfolio live plans.
We have collected together some of the frequently asked questions about concepts in Portfolio for Jira.
Are plans considered fiscal plans? individual projects?
A plan can be used at different levels. There is no general rule and depends on your way of working. You might make different plans for different departments, create a separate plan for the next quarter, or make plans for a particular set of projects. The only rule is that plans are logically separated, and don't share any data such as resource availability. This means whenever you need to balance resources between projects and teams, put the data into one plan. If areas of work are completely independent, use separate plans.
What is the functional purpose of an initiative versus a release? How does it relate to Jira projects?
An initiative groups epics and stories into larger chunks of work. Initiatives typically span multiple releases, with intermediate deliveries along the way. Business initiatives will typically encompass substantial scope and investment, and will thus likely represent the level of granularity approved by and reported to top management. Initiatives don't have a direct, binding relation to Jira projects. In many cases, the epics and stories grouped to an initiative live in multiple Jira projects. In other cases, all the issues for an initiative might be in one dedicated Jira project.
Will this tool enable us to scale agile utilizing the Scaled Agile Framework?
Portfolio for Jira is not a dedicated SAFe solution. It was designed in a framework-agnostic way and focuses on solving the practical, day-to-day challenges in planning at any scale. However, it is very well suited to implement SAFe with Jira. Some of the key concepts are:
- Themes which can be used to model SAFe's Value Streams
- Initiatives to plan SAFe's Business or Architectural Epics and do roll-up reporting
- Epics and stories for the program and team level to collaborate and report.
Is this tool like a dynamic Gantt-Chart? Is there some relation to Gantt-Charts?
Portfolio for Jira is not a GANTT chart solution, there are other tools that you can use with Jira for that. Portfolio for Jira does use some visuals that may look like those of GANTT charts, so some elements may look similar. However, Portfolio for Jira functions as an integrated solution, where scheduling and time-based planning is only a single part. Other parts include dynamic scheduling in the background, which helps in planning resources and forecasting realistic release dates.
How do "stages" compare to components?
Components are a generic concept in Jira, which is used in various ways for classifying, categorizing and organizing issues. Stages in Portfolio for Jira have a specific semantic, by not only classifying different types of work but also impacting the scheduling.
What are release streams?
If you run parallel programs of work, or your teams work in multiple product lines with each having their own cycle of releases, you can create release streams to represent these programs. You can define releases (versions) independently for reach stream. Think of them like separate timelines, running in parallel.
Does Portfolio for Jira support views across multiple projects?
Yes, the data in Portfolio for Jira is implicitly cross-project data, with issues originating from potentially multiple Jira projects.
Why use Portfolio for Jira instead of Confluence?
Portfolio for Jira offers dedicated capabilities for project and portfolio management, which are not available in Confluence, such as dynamic, data-driven resource scheduling and forecasting, and roll-up progress reporting. Rather, it is a complementary tool which can be used in unison with Jira and Confluence.
Can epics or stories replace Product Backlog Items?
Stories represent your Product Backlog Items (PBIs). Epics and initiatives are used to organize these backlog items into larger chunks of work.
How do I handle lean projects?
Looking at the 7 key principles of lean software development (eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people, optimize the whole), lean projects fit nicely into the concepts of Portfolio for Jira. Even in a lean project, it is sensible to have a longer term game plan, which you forecast with Portfolio in order to avoid waste, uncoordinated work and lockups between teams. Differences might be to consider the estimates as time budgets you are ready to invest in each initiative, as you might not have much detail upfront, to really estimate all backlog items. If a lean project is not running in sprints but managed in Kanban style, there is an explicit setting on the team level in Portfolio for Jira to switch to Kanban mode.
Is there a separation between dynamic planning and the commitment of those changes?
Yes, Portfolio for Jira allows you to plan in a sandbox in order to evaluate different scenarios and to make temporary changes without affecting the live instance. Going to Plan > Update linked issues to update relevant fields after the planning step.
What is a theme?
Themes represent specific, itemized business objectives. Ideally, themes focus on the key future differentiators. The reporting on themes helps to see how much time is spent for work that contributes to each of the themes, i.e., to check if the teams are focused on the actual, higher level business goals or if the effort is being spent elsewhere.
Is a theme the same thing as a Feature Group?
Feature Groups are more like initiatives in Portfolio for Jira, as an initiative really groups a bunch of epics into a large piece of work. We think of themes as a strategic/business goal, with you tagging Initiatives/Epics/Stories with this goal as they contribute to it. This way, we can report on resource allocation and show what are we doing and how much are we spending to achieve a certain goal.
How does it relate to the concept of Agile Release Trains?
Agile release trains are typically part of the scaled agile framework and defined as "a long-lived team of agile teams, typically consisting of 50-125 individuals, that serves as the program-level value delivery mechanism. Release trains are organized around the enterprise's significant value streams". Portfolio for Jira does not use the notion of release trains, but there are two ways to represent a release train in Portfolio:
- Completely separate plans - Use a separate plan for each release train, so that within the train, resources are ideally balanced and optimized for delivery. This works as long as the resources are really dedicated to the train they are assigned to, and not shared between multiple trains.
- Use release streams to categorize work within a plan to different release trains.