This is article describes a practical way on how to handle Business Objectives, PI Objectives and Business Value. Most of the information is derived from Scaled Agile, Scrum practices and personal experience.

Please be aware that there are no exact rules or techniques when working with value and there are a lot of different practices being used in Agile organizations. You should use whatever makes sense to you when it comes to understanding and learning how to achieve your business objectives. And remember, you can always improve!

Business Objectives

Business Objectives is a general term, not originating from Scaled Agile, and should be a guideline on any organizational level with business responsibility. For instance, a company's vision or Strategic Themes, on group level or business unit level, are good examples of Business Objectives.

PI Objectives

Has been invented by Scaled Agile to give each ART a unifying direction in every PI. Just as each Scrum team have a Sprint goal as their unifying direction in every sprint. We can say that the individual sprint goals all should contribute to achieve the PI Objectives.

Obviously, it is important that objectives are well understood and accepted. The best way to achieve the desired collective understanding is to engage the people, who is doing the actual work, in formulating the goals. Therefore, the teams are involved in formulating and accepting objectives during the PI Planning, as well as the sprint planning. If objectives are just communicated without dialogue they are seldom taken into the heart and sometimes misinterpreted.

PI Objectives are a summary of a team’s plan and intent for the PI. As a countermeasure, to avoid fuzzy or non-verifiable objectives teams should formulate SMART PI Objectives. In addition, to have objectives reflect real business value and relation to Business Objectives, the PI Objectives should describe outcome rather then output.

Business value

It is hard to find a clearly defined way of assessing Business Value, especially when connecting it to planning. A lot of times there is a large time gap between plan, delivery and business revenue which forces us into subjective assessments.  

The solution from Scaled Agile is to use a relative scale, 1-10, and engage Business Owners in a discussion to set the relative value. At large this is according to general agile thinking to create collaboration and mutual understanding as for example with User Stories.

PI Objectives and Relative Business Value should give enough guidance for the ART so that, if impediments should occur, quick decisions can be made on how to pivot

PI Planning

According to Scaled Agile there are two dominant ways of assigning Relative Business Value:

1 Relative within teams

• Each team starts with their most valuable PI Objective as 10
• All remaining PI Objectives are relative to that first 10
• Does not require normalization across teams (May be very complex)
• Easy way to get started
• All teams typically feel they are equally valuable, since they all have at least one 10

2 Relative across teams

• Values are comparable across teams
• Provides visibility into priorities across the ART and may facilitate tradeoffs and redistribution of work
• Contributes to shared understanding of value
• May result in some teams with mostly low values and a lesser feeling of contribution

Whatever way you choose, the process should not be complicated, and the focus should be to foster collaboration between Scrum Teams and Business Owners, including improved PI Objectives which are supporting the work towards the Business Objectives.

Follow up

After each PI both PI Objectives and Business Value should be assessed. The purpose is to find a way to be predictable in what we are trying to achieve. Since this is back to subjective judgements it may be hard to establish a repeatable and trustworthy process.

I have seen many ARTs struggling with the understanding what they accomplished, how it relates to the planned objectives and the most important, how to improve. A typical dialogue:

   “Did we achieve the goal and what Business Value did we get?”

   “Well yes, the team think they achieved 60% of the PI Objective and given the original 8 in Business Value this is probably 5 on the relative scale!”

    “Ok, let’s go for 5. Great work!”  

Have you experienced any similar dialogue? I wonder, how can Teams improve when the assessment is so subjective? Does it really matter if the team work on SMART Objectives if they always get some kind of "approval"? I have concluded that the best way is to separate assessment of PI Objectives from the assessment of Business Value.

It means that the, hopefully objective, measurement from the SMART Objective can be assessed by the Team together with whomever is doing the specified measurement. The Team can understand if they have achieved the Objective or not.

To be specific and clear I purpose a digital assessment, either you achieve the objective or not. This is in line with how teams are taught to handle Sprint Goals and Story Points. If we do not achieve the Sprint Goal the Sprint is failing. If a Story is not approved by the Product Owner, the team cannot take any Story Points into account. This fashion is meant to help teams in setting SMART Objectives and thus learn to improve and be able to show a credible result to stakeholders.

With the SMART assessment of PI Objectives Business Owners can make the same rating as during the PI Planning. In other words, focus and explain how valuable a PI Objective is from a business perspective when it is achieved. Also provide guidance for improved PI Objectives, for example how to perform measurement.

By separating assessment of SMART PI Objectives and assessment of Relative Business Value the learning process is more straightforward and promotes the collaborative discussion between Business Owners and teams to continue building a shared understanding of value. Business Objectives, PI Objectives and Sprint Goals should all be aligned with the value deliveries that the teams are doing in each Story.                                                                   

Example of PI Objectives and assessment

This example shows how Planning (output from the PI Planning) and Follow up (assessment during Inspect & Adapt) may be displayed.

The only reason a RBV will differ from original RBV, if it is not 0, is if the Business Owner values the outcome differently independently of the delivery.

Culture

We (you, me and everyone else) should not be afraid of failing. Instead we should appreciate a failure, as valuable piece of information that will help us improve. Just as Toyota says: “Our problems are our Jewels”. It might be difficult to think in this way, but it much more important to learn instead of staying in a comfortable, but mistakenly, safe zone.

Organizations tend to be internally focused, which may result in too much work on self-fulfilling needs rather than end customer needs. Agile product ownership is all about developing the business towards customer needs.