Portfolio – iceScrum

Documentación Esta documentación se aplica solo a iceScrum v7.
Para el antiguo iceScrum R6, lea la documentación o migrate.

Contents


Manage the definition and development of large products through project portfolios.

Principles

A portfolio is a new iceScrum workspace that will help you manage the development of a big product with several teams. In particular, it is relevant when the product cannot be divided into valuable sub-products that could be managed independently.

This part of iceScrum is suited for teams using SAFe, LeSS or similar approaches.

Portfolio teams must be «feature teams» that are able to complete features independently. Each feature team is associated to its own iceScrum project and the projects are aggregated under the portfolio.

If you have any doubt about the relevance of the portfolio in your context or the meaning of the words used in the previous sentence, please refer to the dedicated documentation.

All the portfolio features are packaged into a single App that is enabled by default if you have a Business Cloud subscription or an Enterprise / Corporate On-Premise license. Business and Enterprise plans are limited to 1 portfolio / server, while the Corporate license gives access to unlimited portfolios.

Portfolio framework

When creating a portfolio, you can choose the framework:

  • Generic (LeSS…)
  • SAFe

At the moment, the only impact is in the terminology used in the views. The Generic mode is aligned with most large scale practices while the SAFe mode will use the specific SAFe terminology.

Projects


You can create a portfolio from scratch, in which case you will be offered to create the associated projects and teams in the portfolio wizard.

You can also add existing projects to a portfolio. To do so, you must be either Product Owner of the Project, or Owner of the team the project belongs to.

A project can only belong to zero or one portfolio. A portfolio can’t have more than 20 projects for its functionalities to be usable under proper conditions.

Roles

Portfolios are always private: they can only be seen and updated by their explicit members.

Members of a portfolio can have on of these two roles:

  • Business owner: full permissions on the portfolio.
  • Stakeholder: read-only access on the portfolio.

The portfolio roles grant permissions on all the projects of the portfolio:

  • Business owner: get Product Owner permissions on all the projects.
  • Stakeholder: get Stakeholder permissions on all the projects.

To learn about the details of these permissions, read the dedicated documentation. If the portfolio members already have explicit roles on the projects and their teams, these roles are not changed. The permissions of their team / project roles will be merged with the ones granted from their role at the portfolio level.

The main business item manipulated at the portfolio level is the feature. In a regular iceScrum projects, features are ordered by the Product Owner according to the current business priorities. However, when the project is part of a portfolio, such decisions are taken at the portfolio level. That is why a regular Product Owner cannot update the order of the features in a project that belongs to a portfolio. They need to be Business Owner of the portfolio to do so.

Dashboard & KPIS

The Portfolio dashboard allows adding custom widgets in the same fashion as your user home. Thus, you can include all the charts / KPIs from the portfolio projects.

The Portfolio dashboard also provides exclusive widgets such as the Feature KPIs that help you inspect how features flow.

Cycle time (Features)

The Cycle Time is the average time taken for a feature from the moment a team starts working on it until it is completed. It is often used in Lean / Kanban, but it can be a great addition to Scrum as well as it encourages improving the flow of features and reducing bottlenecks and stocks.

The moment a team starts working on a Feature is deduced from its stories: it is the moment its first story is marked as «In progress». The completion date is the moment a feature is marked as «Done».

Data is gathered on done features, for a period of 3 months before the last feature has been marked as «Done».

This indicator is meaningful only if the team splits stories into features and update them on a regular basis.

Ideally, you want the Cycle Time to last only a few sprints, which means that features are delivered at a regular pace and that the team does not suffer from the «tunnel effect».

Lead time (Features)

In iceScrum, the Lead Time is the average time taken for a feature from the moment it is created until it is completed. It is often used in Lean / Kanban, but it can be a great addition to Scrum as well as it encourages improving the flow of features and reducing bottlenecks and stocks.

The completion date is the moment a feature is marked as «Done».

Data is gathered on done features, for a period of 3 months before the last feature has been marked as «Done».

Ideally, you want the Lead Time to be as short as possible, as it represents the time taken to answer a need that has been expressed.

Throughput (Features)

In iceScrum, the Throughput is the number of features completed per rolling month. It is often used in Lean / Kanban, but it can be a great addition to Scrum as well as it encourages improving the flow of features and reducing bottlenecks and stocks.

It is averaged up to a 3 months range if data is available in the current release.

For this indicator to be meaningful, it requires that features are completed on a regular basis.

Ideally, you want the Throughput to be high, which means that there is a great flow of completed features and little tunnel effect.

Feature backlog / Program backlog

The «Feature backlog» (or SAFe «Program backlog») view of the portfolio is where upcoming Features are created and refined.

Such features have the state «Draft» as they are likely to change until a team actually takes ownership over it.

Draft features are very similar to regular project features. Like regular features, they can be either:

  • Functional,
  • Enabler.

Unlike project features, draft features cannot have stories attached to them as stories is part of a collaboration with a specific team.

Once a feature is ready (or during the PI Planning), it can be sent to one of the portfolio Feature teams. Batch selection allows moving several features at once. Be careful, sending a feature to a team cannot be reversed!

Feature teams / ART

The «features teams» (or SAFe «ART») view of the portfolio shows all the features of each project, each project being associated with its own feature team.

Portfolio members can thus get a good overview of the distribution of features across the feature teams. Business owners can create feature inside projects and reorder features inside each project in order to adjust their vision.

The feature details give access to the stories of each feature. Thus, you can good as deep as needed in the business item trees.

Inter-project story dependencies

Under a project that belongs to a portfolio, the «Depends on» story field allows defining a dependency to a story from any project of the portfolio, while it is otherwise limited to the stories of the same project.

More functionalities

The Portfolio workspace is currently being improved, here is what you can expect in the near future:

  • Synchronized sprints and releases across the projects of a portfolio.
  • Release / PI objectives.
  • Shared Definition of Done across the projects of a portfolio.
  • Multi-project roadmap
  • …

We would be glad to here any feedback about the current portfolio features, the ones in our backlog or maybe some we did not think about! Please write to our support email address.

Previous << Epic stories
Next Roadmap del proyecto >>

Pruébalo gratis ahora
Todo lo que necesita para gestionar sus proyectos ágiles