Lean-Agile
Coaching and Training
Other
-
- Also some Useful Tools
Note that we have some Incomplete Pages That Require Work on this site:-)
Note that we have some Incomplete Pages That Require Work on this site:-)
There seems to be a lot of question the use of “business value” with PI Objectives, around the process of setting the value of PI Objectives, and how they are worked during the Program Increment. Let's look into this in more detail.
When people start with SAFe there is a lot of confusion around the need to assign a Business Value to the PI Objective. The thinking goes “we already understand the business value because we have the features - why not just use that?” In many ways this is the same kind of thinking process as “why do we establish sprint goals when we have users stories?” The problem with this type of thinking is that if you are not careful features and stories become a way of specifying fixed scope, do not allow learning as we go along, and set us up for blame game when things don't quite work out as expected (Business: “But the features says it has to do this!”; Team: “We thought it meant that and this is how we got there.”) To rectify this, we treat the features or story as a “wish” and the PI Objectives (and sprint goals) become a feedback loop to that the team provides to ensure there is common understanding. (See What is the Purpose of Sprint or Iteration Goals? for more information)
Having established the PI Objectives, we need to close the loop on communication, and we do this by having the business owner review the PI Objective, discuss their understanding of the PI Objective with the team, and assign a Business Value to that PI Objective based on that understanding. This process creates a “handshake” between the business and the team, with the PI Objectives in the team’s own words and the Business Value is the agreement from the business that the Plan makes sense to them.
In addition to closing this loop, there are two other primary uses of the Business Value that is assigned to the PI Objectives:
In summary, “Why do we assign a Business Value?” To enable local decision making and to understand whether we are making and meeting commitments.
The general literature calls for the Business Owner to go from team to team during a PI Planning event, and assign values in the range of 10 (high value) to 1 (low value) on all the team's PI Objectives on a relative scale.
Sounds easy, doesn't it? But there seems to be a lot of different approaches to assigning Business Value to PI Objectives, the process seems to cause a lot of confusion, not to mention misunderstanding, and it often leads to people abandoning the process all together. Some problems I have seen, based on a particular approach to generating the Business Value include:
How do we make the process smoother and more useful? One thing to note in the above “why” discussion is that the Business Value associated with a PI Objective is a team level discussion. The purpose is:
What does this mean? It means we don’t really have to try to establish a Train / Program concept of Business Value but simply use a team-by-team approach. The approach I've found to work well is:
This process allows us to have the discussions we need, while reducing the “arbitrariness” of the process, at the same time providing the data to use in the Program Increment:
Probably the biggest problem with the assignment of Business Value is when the PI Objectives do not clearly articulate the value, or is written in such a way that the business is not able to understand what is being done. It is therefore important that PI Objectives are “good” - see references below for more information.
Another problem that we sometimes see is when people confuse what they are providing. For example some people start to think “if I have PI Objective 1 as a 10, and PI Objective 2 as an 8, then this means that the 10 item will be worked first.” Business Value is a value, not a priority. It might be used to make prioritization decisions but it is not showing the priority of the work.
Note that as a side benefit, the train / program level metric for predictability percentage calculated by comparing the sum of the Business Values planned by the teams on the train in comparison to the sum of the Business Values actually delivered by the teams on the train. At both the team and program level the metric is presented as “are we making and meeting commitments to deliver value?”
In summary, “How do we assign Business Value?” Team by Team, where every Team has at least one PI Objective with Business Value of 10, and Business Values are relative to that for the team.
At the end of the PI Planning event we have a set of business values. And and the end of this PI we would like to have a set of values that are updated to reflect the value of what was actually delivered so we can improve on our ability to deliver value. In other words the updated values are used to calculate the predictability metric and so is an input into the Inspect and Adapt).
One mistake a lot of Release Train Engineers make is to wait until the end of the Program Increment to gather up the values. The thinking is that we don’t want to waste a person's time (especially these senior Business Owner types) on updating these values so we should wait for the next big event.
As said, this is a mistake:
A better approach is to have the business owner update the values as they are delivered. Typically as a result of a System Demonstration the business owner (or their proxies) will have seen the value provided. The team(s) are responsible for providing the link between the feature, the objectives and the work (stories) they have completed so there is a clear understanding of the value being provided.
If the Business Owner attends the System Demonstration, we could get an updated value by saying to the Business Owner “ … at PI Planning you said this was an 8. Now that you have seen it what do you think the value is?”
It is OK for the Business Owner to say “this is now valued a 7 (i.e. lower value) than we original thought.” Sometimes this is because the business situation changed. Or it might be that after having seen the capability it’s just not as useful as it was. Whatever the case, we need this data to figure out how we can improve. Is there something we could have done to improve our communication? Is there something we could have done to understand the change in business environment? The key thing to understand is that there is no blame assignment here; the Team did not somehow fail. It is just data and we might be able to learn something from it. Metrics like the Predictability will fluctuate based changes in the Team’s ability to deliver and the changing business environment. We use this data in the Inspect and Adapt to help drive improvements.
Sometimes we find that Business Owners say they do not have the time to attend a System Demo or that they need to wait on something else before providing the value. My feeling is that the RTE should set up a working agreement with the Business Owner where in the event that the Business Owner is unable to provide a value, the RTE will simply assign the value that was originally given. Like most working agreements of this time, the other side of the agreement will be that the RTE will work hard to show the value to the Business Owner so they can provide feedback. In general this is a bit of an anti-pattern (we want Business Owners involved as much as possible), but especially as you are establishing Trains in a new organization, it something that you will often see.
In summary, “How do we update the Business Value?” Incrementally, as the PI Objective is completed.