Jen's Agile Cliff Notes - SAFe PI Objectives and Iteration Goals
- Jen C
- Nov 10
- 4 min read
Updated: 7 days ago
In a previous column, I discussed how to write SMART Goals. The following column dives in a bit deeper as to how we can use the SMART Goal format when writing PI Objectives and Iteration Goals.
Every Program Increment (specifically at PI Planning), we craft and discuss our PI Objectives. What about Iteration Goals? Let’s dive into each a bit more.
What is a SAFe PI Objective?
It’s a summary of the business and technical goals, written in a common language for business and technology stakeholders, yet the exercise is often misunderstood by teams. (I’ll offer some insight in a bit!)
So Jen…what things are a PI Objective, um, not…?
They should not be confused with a set of fixed, inflexible, long-term deliverables. While they should relate to a feature, they are not a feature. PI Objectives are not one-to-one with a feature. (They can be a group of stories. A feature can have multiple PI Objectives too!)
What are the benefits of solid PI Objectives?
Well, they align the ART with a shared mission. They communicate and highlight each team’s contribution to the overall business value for the PI (and yes, we do assign a business value to each PI Objective, too).
How do we build out a PI Objective?
During PI Planning, each team should review the program vision and top 10 features. Write in SMART format (Specific, Measurable, Achievable, Realistic, and Time-Bound). Writing a solid PI Objective requires reasonable estimating and planning, velocity, analysis of features, and defined stories. The output is a summary of information in simple business terms.
Are we married to our PI Objectives?
Yes! Each team commits to doing everything in its power to meet the agreed-upon objectives. What do we do if our PI Objective is at risk for completion during the PI? Escalate Immediately!
Now, what happens after PI Planning? Each team begins to plan its iterations.
What is an Iteration Goal?
It’s a high-level summary of the business and technical goals that the Agile Team agrees to accomplish in an Iteration. It’s a statement, typically a sentence or two, stating the business objectives of the iteration.
Are we also married to our Iteration Goals?
Yes! It’s a commitment by the team to the work needed to achieve the goals. Iteration Goals are mandatory in SAFe and Scrum, but honestly, they are helpful to know where the team is headed and when you reach the finish line…for that iteration, of course.
“Simply, committing to complete a set of stories in an iteration is insufficient; the team must be constantly looking at the business value of each iteration and be able to communicate that value in business terms to the Business Owners, management, and other stakeholders.”
What are the benefits of solid Iteration Goals?
They align the dev team members and the Product Owner to the same mission. They align the team to the Planning Interval (PI) Objectives. They provide context for understanding and addressing cross-team dependencies.
Iteration goals often reflect the following:
Features, feature slices, or feature aspects, such as research and necessary infrastructure
Business or technical Milestones
Architectural, infrastructure, exploration, and compliance activities
Routine jobs and other things, such as maintenance and documentation
Iteration goals are achieved by completing backlog items, even though it may not be necessary to finish every story to meet the goals. In other words, the goals for the iteration override any particular story. Iteration goals also help in understanding and maintaining a broader view of what the team intends to accomplish in each iteration, as well as what to present in the upcoming System Demo.
How do we build out an Iteration Goal?
The team should create one or more iteration goals that are based on the team and program PI Objectives. Iteration goals should differ from your user stories as follows. Once the iteration backlog is understood, the team turns its attention to synthesizing one or more iteration goals that are based on the team and program PI Objectives from the PI Planning session and the iteration backlog. The closer this iteration is to the PI Planning session, the more likely it is that the Program Objectives will remain unchanged.
The goal explains why it is a good idea to carry out the sprint and implement the stories. The user stories enable you to reach the goal. It’s a common mistake to confuse the two.
Here are a few examples:
Get feature X ready for release (hereby, the Goal is to deliver a feature)
Check if the architecture enables the desired performance (hereby, the Goal is addressing a risk)
Test if users are willing to register before using the product features (hereby, the Goal is to test an assumption)
Now back to being married to our Iteration Goals…
When the capacity has been reached in terms of committed stories during iteration planning, no more stories should be pulled from the team backlog. At this point, the Product Owner and Dev team agree on the final list of stories that will be selected, and they revisit and restate the iteration goals. The entire team then commits to the iteration goals, and the scope of the work remains FIXED for the duration of the iteration.
Comments