Portfolio Planning
Decoding Lean Portfolio Management: The Jargon Buster
In the world of Lean Portfolio Management (LPM), one of the first barriers most newcomers face isn't a lack of enthusiasm or dedication. Instead, it's the challenge of deciphering an array of terminologies that sound more abstract than they truly are. Many concepts aren't entirely new. They're often combinations of older ideas or traditional concepts that have been tweaked, adjusted and evolved.
Our jargon buster guide seeks to distil what you really need to know to get going.
| Term | Description | Further reading |
|---|---|---|
|
ART (Agile Release Train)
|
An ART is essentially a long-lived team of teams, or in simpler terms, a delivery team that's here to stay. Think of it as a larger team made up of smaller teams. An ART typically sits together with other ARTs within a Value Stream (which might think of here as a Team of Team of Teams).
ARTs will typically plan their work in chunks, covering several sprints (or "iterations"). This planning often happens during specific events, orchestrated across ARTs (by the Value Steam). These events typically happen once per quarter, and are known as "Program Increment (PI) Planning". Sometimes, they might happen as part of a quarterly business review (QBR). |
ART (SAFe Definition) |
| Component |
While agile emphasizes structuring teams based on the value they offer, there’s still a need to grasp which parts of the technical architecture the work will affect. That's where the term 'Component' becomes valuable. It gives you a lens to view and manage specific technical segments while keeping the bigger picture in mind.
'Component' carries a a strict definitions in frameworks like SAFe, but in real-world application, organizations often adapt it more flexibly. Essentially, a Component is a technical or architectural grouping within the organization. For example, "Core Platform" or "Mobile" can be referred to as Components (though in reality, large organizations would break these examples down further as "Mobile" and "Core Platform" would not be usefully specific). Note that this concept (and particularly its juxtaposition with Feature teams) becomes particularly interesting when thinking about how best to structure your teams. See further reading for more info. |
Are feature teams or component teams right for your product?(Roman Pichler) |
| Epic |
At its simplest, an Epic is simply a large chunk of work. As a rule of thumb to keep things simple, we could say we might expect an Epic to last between 3 and 18 months (or 1-6 program increments).
An Epic is the closest thing that SAFe has to a "project". It is typically where you will record an Epic Hypothesis and a Value Forecast. These two concepts are comparable to a traditional project business case. We would typically expect an Epic to broken down into Features. |
Epic (SAFe Definition) |
|
Epic Hypothesis
|
You can think of an Epic Hypothesis as a similar concept to a traditional business case for a project - especially, the "benefits" aspect of a traditional business case. It should contain information about why the Epic will create value for your organization.
If you're in the relatively early stages of adopting agile, you might find it easiest to start by adapting your existing business case template, rather than adopting SAFe's Epic Hypthesis template wholesale. Remember, you can always iterate, evolve and upgrade in the future. Bias for simplicity. |
|
| Feature |
A Feature, like an Epic is simply a chunk of work. Try not to get too caught up in what you might historically have thought of as a Feature.
"Savings dashboard for customers" is just as much a feature as "Launch an "Employee Monthly Wellness Workshop Series.", despite the latter not necessarily sounding like an obvious example of a feature. |
|
| Iteration |
An iteration is generally used, just as another word for a Sprint. It is a consistent time frame, used for incremental development.
Most commonly, we would expect an Iteration to last two weeks. We would expect there to be 6 iterations (including a planning iteration) in a given Program Increment. Note that on this basis, 6 iterations would be equal to a quarter of a year, which might align nicely with a quarterly business review (QBR). |
Iterations(Safe Definition) |
| OKR (Objectives and Key Results) |
A strategic framework for setting goals. Objectives define what you aim to achieve, while Key Results are the measurable actions taken to realize those objectives.
You can read more about OKRs in variety of Kiplot knowledge articles. Some links are included to the right. |
|
|
Program Increment (PI)
|
A set time period, typically 12 weeks (and often 6 sprints/iterations), during which a team (and/or the ART it belongs to) executes work. The work to be executed should typically be planned out at a PI planning event, which will take place at the beginning of each PI. | Program Increment (SAFe Definition) |
|
QBR (Quarterly Business Review)
|
A regular review, typically held every quarter, to discuss, analyze, and evaluate vital business metrics and performance indicators.
This event can be aligned with the Program Increment schedule to assess the value delivered by the previous PI. It is an opportunity to assess the non-technical, business value that has been created (and compared against the forecast). This event is a good opportunity to assess the progress that Epics are making against their Epic Hypothesis and Value Forecast. |
Quarterly Business Review: How to extract benefits beyond transparency (McKinsey) |
|
Sprint
|
A sprint is a fixed period of time, typically two weeks, designed to complete a specific set of tasks (or often, set of stories).
Sprints are typically planned in advance. A scrum master or product owner is often responsible, during a sprint, to prioritize and plan the work that will take place in the next sprint. This prioritized list (or backlog) is then reviewed at the end of the previous sprint. During this event, work is "committed" to be completed in the next sprint. Sprints typically operate within program increments. The program increment should plan out the high level "shape" of the sprints. Each sprint within the program increment should look to achieve the Program Increment objectives, but operating at a lower level of planning and execution. Often where a Program Increment will concern itself with Epics and Features, sprint planning concerns itself with the Stories required to build/achieve the Features and Epics. |
Scrum sprints (Atlassian) |
|
Story Point
|
A Story Point is simply a unit for measuring the effort needed to execute a user story, accounting for complexity, effort, and unpredictability. Note that Story Points are never comparable between teams. A nominally higher story point velocity from one team to another is not an indicator of higher performance. Most experts agree that comparing story point velocity between teams as a measurement of relative performance is a management anti-pattern. |
What Are Agile Story Points? And why do we use them?(Mountain Goat Software) |
| User Story |
A User Story is commonly abbreviated to "Story". Most people picking up agile for the first time can think of a Story as akin to a Task. It is a small unit of work, that typically belongs to a Feature (which in turn belongs to an Epic).
The origin of a User Story stems from the idea that requirements should be written from the voice of the user. Specifically, what experience does the user want, or what experience are we trying to create for the user. There is extensive best practice on how to write an effective User Story. However, many people will find themselves working in teams that do not have or need "real" user stories. In this context, there is no need to get obsessed with the origin of the term. A story can simply be thought of as a very small unit of work. Stories are typically estimated in Story Points. |
User Story (SAFe Definition) |
| Value Stream |
For those just setting out on their agile journey, you can radically simplify a Value Stream by simply thinking of it as an organizational construct that groups teams and ARTs together.
Where an ART is a Team of Teams. A Value Stream is a Team of Teams of Teams. For those more interested in the detail, the definition of a Value Stream carries a significant amount of additional complexity (especially in best practice for their design). Please follow the links to the right for further reading. |
|
Component
While agile emphasizes structuring teams based on the value they offer, there’s still a need to grasp which parts of the technical architecture the work will affect. That's where the term 'Component' becomes valuable. It gives you a lens to view and manage specific technical segments while keeping the bigger picture in mind.
'Component' carries a a strict definitions in frameworks like SAFe, but in real-world application, organizations often adapt it more flexibly. Essentially, a Component is a technical or architectural grouping within the organization. For example, "Core Platform" or "Mobile" can be referred to as Components (though in reality, large organizations would break these examples down further as "Mobile" and "Core Platform" would not be usefully specific). Note that this concept (and particularly its juxtaposition with Feature teams) becomes particularly interesting when thinking about how best to structure your teams. See further reading for more info.
Further reading:
- Are feature teams or component teams right for your product? (Roman Pichler)
ART (Agile Release Train)
An ART is essentially a long-lived team of teams, or in simpler terms, a delivery team that's here to stay. Think of it as a larger team made up of smaller teams. An ART typically sits together with other ARTs within a Value Stream (which might think of here as a Team of Team of Teams).
ARTs will typically plan their work in chunks, covering several sprints (or "iterations"). This planning often happens during specific events, orchestrated across ARTs (by the Value Steam). These events typically happen once per quarter, and are known as "Program Increment (PI) Planning". Sometimes, they might happen as part of a quarterly business review (QBR).
Further reading:
Component
While agile emphasizes structuring teams based on the value they offer, there’s still a need to grasp which parts of the technical architecture the work will affect. That's where the term 'Component' becomes valuable. It gives you a lens to view and manage specific technical segments while keeping the bigger picture in mind.
'Component' carries a a strict definitions in frameworks like SAFe, but in real-world application, organizations often adapt it more flexibly. Essentially, a Component is a technical or architectural grouping within the organization. For example, "Core Platform" or "Mobile" can be referred to as Components (though in reality, large organizations would break these examples down further as "Mobile" and "Core Platform" would not be usefully specific). Note that this concept (and particularly its juxtaposition with Feature teams) becomes particularly interesting when thinking about how best to structure your teams. See further reading for more info.
Further reading:
- Are feature teams or component teams right for your product? (Roman Pichler)
Epic
At its simplest, an Epic is simply a large chunk of work. As a rule of thumb to keep things simple, we could say we might expect an Epic to last between 3 and 18 months (or 1-6 program increments).
An Epic is the closest thing that SAFe has to a "project". It is typically where you will record an Epic Hypothesis and a Value Forecast. These two concepts are comparable to a traditional project business case.
We would typically expect an Epic to broken down into Features.
Further reading:
- Epic (SAFe Definition)
Epic Hypothesis
You can think of an Epic Hypothesis as a similar concept to a traditional business case for a project - especially, the "benefits" aspect of a traditional business case. It should contain information about why the Epic will create value for your organization.
If you're in the relatively early stages of adopting agile, you might find it easiest to start by adapting your existing business case template, rather than adopting SAFe's Epic Hypthesis template wholesale.
Remember, you can always iterate, evolve and upgrade in the future. Bias for simplicity.
Further reading:
Feature
A Feature, like an Epic is simply a chunk of work. Try not to get too caught up in what you might historically have thought of as a Feature.
"Savings dashboard for customers" is just as much a feature as "Launch an "Employee Monthly Wellness Workshop Series.", despite the latter not necessarily sounding like an obvious example of a feature.
Further reading:
- Agile Estimation and Planning (Book, Amazon)
Iteration
An iteration is generally used, just as another word for a Sprint. It is a consistent time frame, used for incremental development.
Most commonly, we would expect an Iteration to last two weeks. We would expect there to be 6 iterations (including a planning iteration) in a given Program Increment.
Note that on this basis, 6 iterations would be equal to a quarter of a year, which might align nicely with a quarterly business review
Further reading:
- Iterations (SAFe Definition)
OKR (Objectives and Key Results)
A strategic framework for setting goals. Objectives define what you aim to achieve, while Key Results are the measurable actions taken to realize those objectives.
You can read more about OKRs in variety of Kiplot knowledge articles. Some links are included below
Further reading:
- Crafting Enterprise OKRs (Kiplot)
- Avoiding Common Pitfalls in Implementing OKRs (Kiplot)
Sprint
A sprint is a fixed period of time, typically two weeks, designed to complete a specific set of tasks (or often, set of stories).
Sprints are typically planned in advance. A scrum master or product owner is often responsible, during a sprint, to prioritize and plan the work that will take place in the next sprint. This prioritized list (or backlog) is then reviewed at the end of the previous sprint. During this event, work is "committed" to be completed in the next sprint.
Sprints typically operate within program increments. The program increment should plan out the high level "shape" of the sprints. Each sprint within the program increment should look to achieve the Program Increment objectives, but operating at a lower level of planning and execution.
Often where a Program Increment will concern itself with Epics and Features, sprint planning concerns itself with the Stories required to build/achieve the Features and Epics.
Further reading:
- Scrum sprints (Atlassian)
Story Point
A Story Point is simply a unit for measuring the effort needed to execute a user story, accounting for complexity, effort, and unpredictability.
Note that Story Points are never comparable between teams. A nominally higher story point velocity from one team to another is not an indicator of higher performance. Most experts agree that comparing story point velocity between teams as a measurement of relative performance is a management anti-pattern.
Further reading:
- What Are Agile Story Points? And why do we use them? (Mountain Goat Software)
User Story
A User Story is commonly abbreviated to "Story". Most people picking up agile for the first time can think of a Story as akin to a Task. It is a small unit of work, that typically belongs to a Feature (which in turn belongs to an Epic).
The origin of a User Story stems from the idea that requirements should be written from the voice of the user. Specifically, what experience does the user want, or what experience are we trying to create for the user. There is extensive best practice on how to write an effective User Story. However, many people will find themselves working in teams that do not have or need "real" user stories. In this context, there is no need to get obsessed with the origin of the term. A story can simply be thought of as a very small unit of work.
Stories are typically estimated in Story Points.
Further reading:
- User Story (SAFe Definition)
Value Stream
For those just setting out on their agile journey, you can radically simplify a Value Stream by simply thinking of it as an organizational construct that groups teams and ARTs together.
Where an ART is a Team of Teams. A Value Stream is a Team of Teams of Teams.
For those more interested in the detail, the definition of a Value Stream carries a significant amount of additional complexity (especially in best practice for their design). Please follow the links below for further reading.
Further reading:
- Value Stream Design: Start With The Work (Kiplot)
- Team of Teams: New Rules of Engagement (Book, Amazon, General Stanley McChrystal)
- Value Stream Centric Design (Kiplot)
- Development Value Streams (SAFe Definition)
ART (Agile Release Train)
An ART is essentially a long-lived team of teams, or in simpler terms, a delivery team that's here to stay. Think of it as a larger team made up of smaller teams. An ART typically sits together with other ARTs within a Value Stream (which might think of here as a Team of Team of Teams).
ARTs will typically plan their work in chunks, covering several sprints (or "iterations"). This planning often happens during specific events, orchestrated across ARTs (by the Value Steam). These events typically happen once per quarter, and are known as "Program Increment (PI) Planning". Sometimes, they might happen as part of a quarterly business review (QBR).
Further reading:
Component
While agile emphasizes structuring teams based on the value they offer, there’s still a need to grasp which parts of the technical architecture the work will affect. That's where the term 'Component' becomes valuable. It gives you a lens to view and manage specific technical segments while keeping the bigger picture in mind.
'Component' carries a a strict definitions in frameworks like SAFe, but in real-world application, organizations often adapt it more flexibly. Essentially, a Component is a technical or architectural grouping within the organization. For example, "Core Platform" or "Mobile" can be referred to as Components (though in reality, large organizations would break these examples down further as "Mobile" and "Core Platform" would not be usefully specific). Note that this concept (and particularly its juxtaposition with Feature teams) becomes particularly interesting when thinking about how best to structure your teams. See further reading for more info.
Further reading:
- Are feature teams or component teams right for your product? (Roman Pichler)
Epic
At its simplest, an Epic is simply a large chunk of work. As a rule of thumb to keep things simple, we could say we might expect an Epic to last between 3 and 18 months (or 1-6 program increments).
An Epic is the closest thing that SAFe has to a "project". It is typically where you will record an Epic Hypothesis and a Value Forecast. These two concepts are comparable to a traditional project business case.
We would typically expect an Epic to broken down into Features.
Further reading:
- Epic (SAFe Definition)
Epic Hypothesis
You can think of an Epic Hypothesis as a similar concept to a traditional business case for a project - especially, the "benefits" aspect of a traditional business case. It should contain information about why the Epic will create value for your organization.
If you're in the relatively early stages of adopting agile, you might find it easiest to start by adapting your existing business case template, rather than adopting SAFe's Epic Hypthesis template wholesale.
Remember, you can always iterate, evolve and upgrade in the future. Bias for simplicity.
Further reading:
Feature
A Feature, like an Epic is simply a chunk of work. Try not to get too caught up in what you might historically have thought of as a Feature.
"Savings dashboard for customers" is just as much a feature as "Launch an "Employee Monthly Wellness Workshop Series.", despite the latter not necessarily sounding like an obvious example of a feature.
Further reading:
- Agile Estimation and Planning (Book, Amazon)
Iteration
An iteration is generally used, just as another word for a Sprint. It is a consistent time frame, used for incremental development.
Most commonly, we would expect an Iteration to last two weeks. We would expect there to be 6 iterations (including a planning iteration) in a given Program Increment.
Note that on this basis, 6 iterations would be equal to a quarter of a year, which might align nicely with a quarterly business review
Further reading:
- Iterations (SAFe Definition)
OKR (Objectives and Key Results)
A strategic framework for setting goals. Objectives define what you aim to achieve, while Key Results are the measurable actions taken to realize those objectives.
You can read more about OKRs in variety of Kiplot knowledge articles. Some links are included below
Further reading:
- Crafting Enterprise OKRs (Kiplot)
- Avoiding Common Pitfalls in Implementing OKRs (Kiplot)
Sprint
A sprint is a fixed period of time, typically two weeks, designed to complete a specific set of tasks (or often, set of stories).
Sprints are typically planned in advance. A scrum master or product owner is often responsible, during a sprint, to prioritize and plan the work that will take place in the next sprint. This prioritized list (or backlog) is then reviewed at the end of the previous sprint. During this event, work is "committed" to be completed in the next sprint.
Sprints typically operate within program increments. The program increment should plan out the high level "shape" of the sprints. Each sprint within the program increment should look to achieve the Program Increment objectives, but operating at a lower level of planning and execution.
Often where a Program Increment will concern itself with Epics and Features, sprint planning concerns itself with the Stories required to build/achieve the Features and Epics.
Further reading:
- Scrum sprints (Atlassian)
Story Point
A Story Point is simply a unit for measuring the effort needed to execute a user story, accounting for complexity, effort, and unpredictability.
Note that Story Points are never comparable between teams. A nominally higher story point velocity from one team to another is not an indicator of higher performance. Most experts agree that comparing story point velocity between teams as a measurement of relative performance is a management anti-pattern.
Further reading:
- What Are Agile Story Points? And why do we use them? (Mountain Goat Software)
User Story
A User Story is commonly abbreviated to "Story". Most people picking up agile for the first time can think of a Story as akin to a Task. It is a small unit of work, that typically belongs to a Feature (which in turn belongs to an Epic).
The origin of a User Story stems from the idea that requirements should be written from the voice of the user. Specifically, what experience does the user want, or what experience are we trying to create for the user. There is extensive best practice on how to write an effective User Story. However, many people will find themselves working in teams that do not have or need "real" user stories. In this context, there is no need to get obsessed with the origin of the term. A story can simply be thought of as a very small unit of work.
Stories are typically estimated in Story Points.
Further reading:
- User Story (SAFe Definition)
Value Stream
For those just setting out on their agile journey, you can radically simplify a Value Stream by simply thinking of it as an organizational construct that groups teams and ARTs together.
Where an ART is a Team of Teams. A Value Stream is a Team of Teams of Teams.
For those more interested in the detail, the definition of a Value Stream carries a significant amount of additional complexity (especially in best practice for their design). Please follow the links below for further reading.
Further reading:
- Value Stream Design: Start With The Work (Kiplot)
- Team of Teams: New Rules of Engagement (Book, Amazon, General Stanley McChrystal)
- Value Stream Centric Design (Kiplot)
- Development Value Streams (SAFe Definition)
