One of the most often misunderstood (and often skipped) parts of the PI process is that of Objectives writing.

The bit people get wrong is knowing the difference between objectives and features. At best, teams resort to paraphrasing their features into business language.

Having driven scaled agility across several organisations, the importance of PI objectives cannot be understated. In our experience their proper use does three key things:

1. Validates Understanding2. Focuses on Outcomes3. Summarises Data

1. Validates Understanding

An inherent challenge in software development has been ensuring that the stakeholder articulates their requirements and these requirements are effectively passed to the development team who in turn interpret them as intended.

The use of PI Objectives helps create an immediate feedback loop from the teams back to stakeholders and provides the opportunity to quickly validate the team’s understanding of the desired outcomes. The challenge for the teams when writing their objectives is: ‘Can you convey concisely in easy to understand language, the value sought by implementing these features?’

By summarising the intent and outcomes that the business wants to achieve the loop of understanding is closed and any misunderstandings are exposed through conversation before any development work has started. The understanding between the team and business creates alignment and gives confidence that the money invested over the course of the next 10-12 weeks is money well spent.

2. Focuses on Outcomes

Features and their acceptance criteria help teams to capture, understand and collaborate on the actual development work. But frequently this is a focus on the work itself without an understanding of the overall outcome. This leads to missed opportunities, with teams overlooking potentially valid, architecturally sound solutions because they already have a preconceived notion of how that value should be delivered.

Is the goal to complete the list of features, or is it to provide the outcomes desired by those features? If the same (or more) value could be achieved with half the amount of work, without completing all the features, is that acceptable?

By understanding the business intent and through direct conversations with stakeholders teams have the opportunity to offer new perspectives and apply their expert knowledge most effectively.

3. Summarises Data

Despite our objections, we have seen large trains consistently take on more than 40 features per PI. This in itself presents its own problems, but it is clear that with so much ‘stuff’ being planned that nobody except the Product Manager has read every Feature carefully, and certainly nobody outside of the train has read them all. In this regard, PI Objectives provide a summary of intent and are a useful way to provide clear evidence of progress to those within, and outside of the train. Their use can augment quantitative reporting and provide a compact way to convey the same information as a feature completeness report.

In conclusion, PI Objectives should not simply be viewed as ‘part of the process’. If they are used in the proper way, they can improve alignment between business and development, help the organisation become more nimble through decentralised decision making and provide valuable insight into true progress.