SAFe PI Objectives – Bridge the Understanding and Commitment with Stakeholders

What is the purpose of Program Increment (PI) Objectives in the Scaled Agile Framework?

They are a shortcut for Stakeholder clarity and engagement.   They are NOT a shortcut for Solution Teams who must do the hard work – bringing Transparency and Clarity to Epics, Features and Stories that correspond with those Quarterly PI commitments.

Far too many of my past clients try to shortcut the PI Planning event by investing more energy into the writing of Objectives and less on the traceability of the Objective into the Agile artifacts (Epics->Features->Stories).

We overcommit and fail to manage Stakeholder expectations, by asking only for Solution Team PI Sprint Objectives, without clearly defining the Features and Stories that ensure a Team commitment which will actually deliver upon the commitment sought by Stakeholders.    Let’s clarify the purpose of Quarterly Objectives and why we write them…

How to engage Stakeholders

The Stakeholder “asks” for Teams to focus on certain outcomes, through the PI Objective – expressed in concise Business Language.   The Teams affirm understanding and clearly commit, through similar “concise business language” via their Team’s Iteration (aka Sprint) objectives.

This simple and clear business language is a crucial bridge of understanding.   The Objectives “wrap around” the more detailed understanding of Value sought by Customers, which is contained in the Agile artifacts (Epics->Features->Stories).

The Stakeholders do not have the time to review the details in the Program Team’s Agile artifacts.  The use of Objectives encourages a “letting go” by Stakeholders and Management, which results in a more natural empowerment of the Teams within the organization.

Planned Objectives [for the current Quarter] must be met

Scaled Agile expects Transparency and drives for practical Inclusion of all talent in the Portfolio.

Solid commitments lead to Aligned execution and eased Inspection of outcomes – crucial for closing the Feedback Loop, continuous learning and intentional, thoughtful re planning (based on current shared reality).

Whatever we express as a PI Objective, MUST be delivered upon.   Why?

We are trying to repair the Trust between business Stakeholders and Solution Programs (aka ARTs).   The organization is desperately seeking an understanding of its Capacity to deliver (on all customer demand) and is trying to become more reliable on the commitments made to customers.

Please review this post for How to Pick Delivery Dates, the Agile Way…

I continue to plead with my clients, “Please …   just follow the prescribed process from SAFe, reinforced by experienced SAFe SPC coaches!”

How should it work?

1. Strategic Objectives are offered to Product Management first, who derive the corresponding Epics (constrained business goals) for upcoming Program Increments (called Release “Targeting”).
2. Product Managers proactively work with Product Owners to derive the Features from each Epic.   Features are the logical deliverables that affect real users/customers/consumers.
   • Steps 1 and 2 occur BEFORE the PI planning event.
3. Solution Teams derive Stories from those features.
   • During our first PI attempt, it is quite common to do step 3 DURING the PI event.
   • As ARTs mature (beginning with PI2), we coach the entire Planning System to offer -2 weeks to -4 weeks advanced view of “committed” Features, so that Solution Teams can Draft as many stories as possible, prior to the planning event.
   • PI events are best reserved for refining clarity of the requested work, not for seeing it for the first time, which rushes analysis and leads to severe overcommitment and unmitigated Risk.
   • We must establish an on-ramp for Refining our Backlog of work, inbound to PI events.   Ask DFC how this is best achieved.

Key Point

Objectives come FROM business stakeholders to START the conversation.   Solution Teams recapture Feature->Story plans as Sprint [iteration] Objectives, to Bridge the linguistic gap with Stakeholders in a way that eases understanding, encourages engagement and trust.  We must ensure that nothing was lost in translation from the initial “ask” by Stakeholders and the official “commit” by Teams.  Anything that could not be accommodated must be CLEARLY conveyed to those Stakeholders.   Stakeholder awareness and buy-in to the plan are CRUCIAL.   Any difference between their “Ask” and what the Program is officially “committing to” must be divulged clearly.

Summary

SAFe helps Management realize a true Leadership platform.   Two way transparency AND commitment is the key to realizing decentralized empowerment of teams.

Without inclusion in planning, there will be no true commitment.   Without commitment, there will be no Accountability.

The key output of a SAFe PI Planning event is a plan that we intend to execute on, with clear lines of Decision-making authority in the context of quarterly commitments.

Now, how do we compel ever more Leadership interaction at these planning events?

Please review my post on Value attribution and Gap Resolution...

Question

What have you experienced with Program Increment Planning events?

Have you seen some of these problematic behaviors and related problems in managing Stakeholder expectaions?