17 Truths about PSI/Release Objectives

By Alex Yakyma.

PSI (Release) Objectives are defined in Scaled Agile Framework as a key alignment tool that teams use within the agile program. For definition and key characteristics, we refer the reader to the original article on PSI Objectives in SAFe.

PSI Objectives are actually not a trivial concept, as is, in fact, the case for anything describing complex aspects of software engineering at scale. That's why it is important that agile teams, program stakeholders, consultants and coaches understand PSI Objectives and their correct application. In this post I will try to provide simple, understandable, compact and actionable points regarding PSI/Release Objectives. Even though unordered, they are useful as they represent answers to common queries:

1. PSI Objectives are not features from the Program Backlog. They can directly correspond to features sometimes, but not necessarily always.
2. PSI Objectives are the key output of PSI/Release planning event. Every team has their objectives sheet as a result of planning.
3. Business value, assigned to each objective by business owners, should be interpreted unambiguously by both stakeholders and the team.
4. Business value has nothing to do with the effort involved. It only shows you "how much useful stuff is there" for the business.
5. PSI Objectives are kind of a "reality check". While top N Features from the Program Backlog are the idealistic plan of intent, PSI objectives reflect them in the real world: what contribution is required from different teams? What are the different aspects, such as research, infrastructure, design enablement, etc.?
6. If a team does not have Stretch Objectives, then they either honestly believe in the fixed scope game or they are made to believe in it. Either way it has nothing to do with agile development.
7. Business Owners should be able to understand all PSI Objectives and their business value; otherwise, they likely lack some members of the Business Owner team (such as system or enterprise architect, infrastructure manager etc.)
8. PSI Objectives may reflect scope that does not originate from Program Backlog – for instance, the team's technical debt, maintenance, other commitments (routine releases, patches, etc.), improvement initiatives, infrastructure and process related effort, etc.
9. PSI objectives are used by teams at every Backlog Grooming, sprint planning and sprint demo event to ensure that they are on track.
10. There's no direct correlation between feature priorities (WSJF) and the business value of the PSI objectives, which the feature spawns on different teams' objectives sheets. However, if the feature is important, then at least one of the corresponding objectives will have a relatively high business value (but not necessarily all).
11. PSI Objectives are the main communication protocol between stakeholders and teams both at PSI/Release planning, execution and Demo.
12. The same PSI Objective may create multiple business effects, all of which should be considered when assigning business value. Thinking in terms of business effects creates the foundation for alignment.
13. S.M.A.R.T. PSI Objectives are context dependent. Besides the basic requirements of S.M.A.R.T.-ness, different organizations evolve their own understanding of what the quality PSI objectives are in their own specific case. It is important to capture these context-specific characteristics as early as possible.
14. PSI Objectives are used at Scrum-of-Scrums, PO/PM meetings, and as system demos.
15. Business Value is always considered at a current moment of time. If something is only valuable in the distant future, it should get high business value in the future, but not right now.
16. Business Value does not determine the sequence in which PSI objectives are taken into development by the team. Business value only shows what to expect as a result.
17. Normally PSI Objectives may be accomplished with reduced scope. This only means that the achieved business value will be lower than the planned one, but key business expectations can still be met.    

Figure 1. PSI/Release Objectives are the primary tool for alignment within agile program

 Understanding PSI objectives is very important for business alignment. Programs and teams realize they are able to deliver value effectively, as they really come to understand what they are building and why. By having a set of clear, committed to, PSI Objectives, every team will know how to be efficient within the program. PSI Objectives enable a program to become a self-organized team of teams – a key mechanism for agility at scale.