And “What is the Purpose of PI Objectives?”

Program Increment (PI) Objectives are an output of the PI Planning event. PI Objectives summarize in business terms what each Team intends to deliver in the upcoming PI. They are therefore used to:

• Validate understanding of intent: PI Objectives provides a quick validation of both the Business Owner’s ability to articulate desired outcomes and the Teams’ grasp of those desired outcomes. In short, we give the teams the following challenge:

Can you deliver the essence of the value sought by implementing this set of features?

• Focus on outcomes rather than the process: PI Objectives help the Team shift focus off the Feature language and onto the desired business outcomes. Is our goal to complete the listed Features, or is our goal to provide the outcomes desired by those Features? In other words, if we could provide the same value with half the amount of work, and without building all of the Features, would this be acceptable?
• Summarize data into steerable information: We expect teams will fully and transparently share the Features they intend to complete, and their progress against them. However given that no large group will reliably read every item in a list if that list exceeds 3-7 items it is also valuable to summarize the 3-7 key Objectives per Team (and the ART) and report on progress against those.

The following is a checklist for creating good PI Objectives:

• Is there clear alignment between Team Features and PI Objectives? Note that to aid, we should annotate the PI Objectives with Feature number.
• Is there clear alignment between Teams where Teams have related or shared PI Objectives?
• Are the between 3 and 7 PI Objectives for the Team? In particular, more than 7 is too long a list to keep in your head.
• Do PI Objectives have with verbs which helps to clearly articulate what’s being done?
• Are there PI Objectives related to base, production support, or other work that is remedial rather than adding new value? Most of the time we want PI Objectives aimed at items that new value.
• Are there PI Objectives related to the architectural runway, or to reduce technical debt? Again, in most cases these will help in delivering better faster, and cheaper, which is of interest to the business.
• Are the objectives SMART?
  • Specific: The PI Objective should be clear about the outcome.
  • Measurable: how do we know whether the PI Objective as done or not done. The PI Objective should
  • Achievable (if much is outside of the team’s control, make it a stretch objective)
  • Realistic (avoid only thinking about the happy path)
  • Time-based (will be done within the PI)
• Related to SMART, are the objectives effective?
  • Action: PI Objective defines an action the solution will take. This typically means including a verb in the PI Objective such as enable, improve, create, modify, etc.
  • What: PI Objective describes what we are delivering. This typically means including a noun into the PI Objective representing things like the Website, Mobile app, the Portal, etc.
  • Who: PI Objective describes who will get the solution. Examples include a customer, mobile users, etc.
  • User value: PI Objective indicates the value being provided. For example provisioning a new capability, improved experience, etc.
  • Business value: PI Objective describes the benefit we expect to get out of this work such as reduced call volume, improved average sale, etc.

A note on this last one, the basic things of interest to executives include:

• Improved revenue
• Reduced cost
• Reduce risk

If you can figure out how to tie your work to things like this you will find improved acceptance of your PI Objectives.

Rather than having a general statement like “Deliver improved performance” with the implied “by the end of the PI” you could look to something like “Deliver improve performance of user interface for XYZ app to have sub-second response time for ABC workflows so that NPS for the App improve by X% by the end of the PI”. Here we have made something more specific, we understand what we are watching right now (response time) and what we expect will happen longer term (NPS), all from the perspective of business.

• Remember Your Audience: The audience for PI Objectives is the Business Owners of the ART in the first instance and then all other stakeholders the the ART. This means we cannot assume that the audience will understand the technology or technical jargon. PI Objective are written in the language of the business. In particular, be clear about intent; what will the usable outcome be? What will the organization will be able to do (or not do) as a result of the work within the PI?
• Relationship to Features:There is no a 1:1 relationship between Features and PI Objectives although often teams will write Objectives so they are reflected as a Feature. A single PI Objective could refer to a single Feature, or multiple Features. Some Features may not be covered by a PI Objective at all (e.g. KTLO type Features). And some PI Objectives may not be the result of a Feature (e.g. a really significant improvement item identified as a result of the retrospective.). See What is the Mapping Between Features and PI Objectives?

To help teams develop great PI Objectives it sometimes is useful to use a template to think through the parts:

BY <the timeframe, e.g. the end of PI 5>
WE WILL <do something, start the statement with a verb (“enable”, etc.)>
SO THAT <something good happens, provides business benefit>
AS MEASURED BY <how we will know>

• SAFe's View of PI Objectives
• What is the Mapping Between Features and PI Objectives?
• How Do We Assign Business Value to PI Objectives?