SAFe® Business Value (BV) reflection

Aside Posted on Updated on

I encourage all readers to check out the SAFe® guidance article on the subject before
reading this article. SAFe® and Scaled Agile Framework® are registered trademarks of 
Scaled Agile Inc.

An aside about Business Value reflection

Some SAFe® acronyms defined:
Epic Owner (EO), Business Owner (BO), Product Owner (PO), Product Manager(PM), Lean Portfolio Management (LPfM), Scrum master (SM), Release/Solution Train Engineer (RTE/STE), Solution Management (SMg), Business Value (BV), Story Points (SP)

In a given SAFe® portfolio implementation, a long-lived ART should come to a state where Business Value (BV) is reflective, but not necessarily equal to in any way, of normalized story points at the team level. In Tuckman’s stages of group development, this indicates the team of teams is normalized or high performing. In other words, the objective measure is verifiable through attribution to the value delivery and related to a predictable and accurate, but not specific, estimating function/process.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” – the Agile Manifesto principle #3.

Why is this principle insufficient (in one way)? Working software does not automatically equate to valuable software. As in the expected value (intent) the customer wanted to receive. Since we work with customer proxies in Lean-Agile we need to have a way to objectively measure value (even if we work with the actual customer too, but that’s nearly impossible as we’ll explore in another article). The measure must also be validated. We can’t assume that the SAFe method of objective measure with BV is valid as implemented in each unique situation.

Business Value Reflection


This is a critical notion because the Business Owner (BO) and product owner/management (POPM) (and Epic Owner [EO]; Lean Portfolio Management [LPM]) functions should be constantly working together with the ART(s) to improve the predictability of product development, quality, and delivery (release on demand). There needs to be a mechanism in place between the ART and the LPfM/BO/POPM functions to objectively measure the outcomes of the team of teams during a Program Increment (PI). This helps focus management and executives on successful outcomes and value rather than how many features or story points teams completed. Or worse, how many hours were spent on tasks or wishful thinking dates from the planning fallacy.

We should be organizationally focused on value delivery and successful outcomes as priorities over other traditional ways of measuring performance.


Portfolio Management

In consideration of portfolio management as a critical function of any enterprise product and/or service provider. Executives, EO‘s, LPM‘s, System Architects, BO, POPM, RTE/STE, SMg, and Teams of teams (traditional portfolio management, requirements analysts, program/project management, business office functions) need to be able to estimate quickly and accurately during the intake processing of new work (business office/sales/contracts/business/epics/new features, etc.). Estimates by definition are not specific but must have controls in place to be predictable, or accurate.

Hey, over here! We do the work. You know, the “teams”

Teams should always be involved in estimation, but may not have the capacity to do so in every case for all quotes and ROMs. In many organizations, the teams that do the work are never involved in the first pass of estimating. To the detriment of the organization.

Developing an accurate estimating mechanism (a tool with a process plus people; ITSM and a service catalog?) for ROM’s/quotes is paramount to successful LPfM in the SAFe. Look for an article in the future about how we tackled that problem with one of my clients. In my observation of many organizations this process is broken, and/or extremely laborious, and usually very inaccurate even though it was specific.

How many times have you seen the goal posts moved on a “project” to make the organization/company look good/better/as less bad as possible? How many times have you seen a “project plan” copied and pasted with a few labels changed? Out of touch PM’s or managers performing the planning fallacy to forecast cost/schedule/scope?


Scaled Agile Framework on Business Value:

During PI planning, teams set team PI objectives, which provide many benefits:

  • Provide a common language for communication between business and technology
  • Align teams to each other and to a common mission
  • Create the near-term vision, which teams can rally around and develop during the PI
  • Provide an important Metric, the Program Predictability Measure, that the team and Agile Release Train can use to improve performance
  • Communicate with management and highlight each team’s contribution to business value
  • Expose dependencies between teams that must be addressed for system success

Read more at:
Copyright © 2010-2017 Scaled Agile, Inc.

Normalization of estimating (in story points and business value) on long-lived teams (Epic Owners, Lean Portfolio Management, BO,  POPM, & ARTs) should occur over time. A pattern should develop that is useful for capacity planning and management of outcomes across ARTs. This is where the Program Predictability Measure (PPM) is used as an objective measure of outcomes for an ART and the teams that are the train. It [PPM] is the measure of alignment between the ART and the other roles playing a part in product development.

Think of BV and normalized story points as checks and balances for each other between BO, POPM, and Teams on an ART. Teams using relative estimating techniques like planning poker, white elephant or fast story estimating in story points…should have a mean (velocity) that develops over time, on long-lived teams. Likewise for long-lived BO’s working on assessing planned and achieved BV for an ARTs PI Objectives. This way, deviations can be more easily identified and root-caused for problem-solving. Metrics should be created to measure standard deviation (SD) and a team rule identified to document what is done when the SD for BV is exceeded (aka, out of the 80 – 100% target in control band).

Using this built-in mechanism in the SAFe is critical for the organization to tie together portfolio management to the production machine. Without it, there is no woman in the middle communicating and managing the inputs and outcomes to determine whether success was achieved. Often, the simplicity of the process itself identifies numerous unknown dependencies. Also, I have observed executives and management becoming much (significantly) more aware of the inner workings of the organization when collaborating with teams in this way of working.

Validating SAFe BV

It is unacceptable to assume SAFe business value measurement is functioning properly without having a mechanism in place to validate. I’ll hazard a generalization and state that in most cases Business Owners (and their LeSS/XScale/DSDM/SoS/Nexus equivalents) are almost always proxies for the actual customer. At least when performing the value measurement function. Also, in most cases, the actual customer or a proxy customer of the customer organization will not be available to perform the BO function of assessing value at PI Planning and attributing value at Inspect & Adapt.

Controls/Sensors/Measurements and governance must be created to perform validation of the ART’s business value production. We can easily create delusional BV assessments by having internal BO’s attributing value from a silo. If we consider a vanilla Scrum team in an enterprise context it is also very easy for the team to create self-fulfilling prophecies if the PO isn’t truly connected to the actual customer using the product/service.

Internal and External Measurement

Organizations using SAFe as guidance for their way of working on the path to true innovation are strongly encouraged to measure business value produced by the product development social structures known as ARTs. Internally this can be accomplished by creating recursive feedback loops that attribute feature level story point estimates (multi-source and multi-pass) AND PI Objective business value planned/actual back to the first pass estimating functions in the LPfM process. The feedback is used to accurize the estimating functions at the portfolio level. YMMV organizationally as the specifics will depend on your process and tooling. Create improvement actions (stories?) to continuously observe, orient, decide and act (or PDCA) from the feedback to correct the first pass estimating process. What the heck does that all mean? Let’s simplify.

The Business Office in an enterprise will ALWAYS need a quick way to communicate with customers on estimates. Regardless of what the Lean-Agile pseudo-thought leaders, consultant, snake oil salesman and their Lean-Agile framework nirvana predict, reality will always win. So rather than failing and flailing while grasping at straws we should acknowledge business context and create systems that are as “Lean” as possible while being Agile. Then run experiments, remove muda, and repeat. The SAFe provides a good mechanism from which to start building a lean portfolio function in your organization.

Ideally, every time a customer asks how much something costs they can get a specific and/or accurate price or estimate instantly.

Where complexity is low and certainty is very high businesses can be very specific – think about your grocery store – the actual, specific prices are labeled right there on the shelf edge or stuck to a label on the box. It’s non-negotiable. A loaf of bread isn’t priced as “EST. ~$3.50 depending on whether or not some of the slices are delivered at the register.”

Conversely, where complexity is high and/or certainty is very low businesses are less motivated to commit to specificity (even though many do at their own peril). In this case, consider automakers that are learning how to mass produce reasonably priced electric cars (none exist to date) that are self-driving (none exist to date). Complexity is high because of the power density requirements of the battery system and the fact that the infrastructure and laws to support these type of vehicles are woefully inadequate. Certainty is very low because no one really knows when governments and the culture will accept electric or self-driving electric vehicles. The automakers respond by pricing the product “accurately.” Internally, they are not really sure how much R&D will be required so they raise prices and also pay lobbyists to get the government to subsidize the cars to cover uncertainty.

This is where the Stacey Matrix and the socially inept, but intelligent, curmudgeon Dave Snowden’s Cynefin Framework are case studies on how we can make better decisions. It’s also core as to why organizations need to invest in Lean and Agile. Good decisions require quality data.

Internal measurement can be corrected by tapping into the actual business outcomes and objectively measuring through KPI’s, metrics and results. The iron triangle is still somewhat useful. Measure schedule (fixed in Agle), cost (fixed in Agile), and scope (variable in Agile). SAFe BV can be corrected recursively with internal measurement by tweaking the LPfM estimating functions. Facilitate problem-solving workshops with the LPfM, POPM, and BO role/teams to look at first pass estimates vs. actual outcomes. Create improvement stories for affected functions to correct bad behavior (not following the process), poor assumptions (I didn’t know we needed to test), system bottlenecks/flaws (systems thinking/Lean), or other causes. If this is done consistently, the business office should be able to consistently and accurately estimate work with minimal touch to the people who are doing the work. Keep in mind that the LPfM functions should *always* collaborate with the ART on estimates. ARTs should reserve capacity for this work.

External Validation

Externally the organization should also create controls and feedback loops with the actual customer, not just the proxies. The challenge in an enterprise is that most often the actual customer is thousands of people. How do you get the individual opinions and feedback from hundreds or thousands?

The opinions of the executive approving a PR are of far less value compared to the opinions and value assessment of the people actually using the product. Often, executives are not in sync with the users of products and services. So don’t fall into the trap of trusting the executive’s opinion and the fact that your invoice was paid as validation that value was delivered.

This can be done through surveys. NPS is a common tool to gauge value delivery and customer loyalty (you gain loyalty by delivering real value). Using data analytics and usage patterns to produce metrics to measure value is also another option.

Remember to tie in the complete feedback loop to the system. Internal and external metrics are completely useless if they never cause a change in the product development and delivery system.

Simply put, measure the measurements or risk creating a fictional organization.





2 thoughts on “SAFe® Business Value (BV) reflection

    […] via SAFe© Business Value (BV) reflection — […]

    SAFe VelociPacity Tool « said:
    August 4, 2017 at 3:46 PM

    […] Read: An aside about Business Value […]

Leave a Reply