The Pragmatic Agile Coach’s Guide to Managing SAFe Features

As customers scale from their loose confederation of Scrum teams to the formality of the Scaled Agile Framework©, features often become a source of confusion and sometimes consternation. In this article, I will draw from my experiences to offer practical tips to make features viable as you implement and execute SAFe©.

Features are Not Just Renamed Epics

Any team members who show up to your SAFe Agile Release Train (ART) having worked as a Certified Scrum Master or Product Owner will probably have a good idea of Agile Alliance’s definition of an epic:

“An epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories.”

They will feel confident saying, “So SAFe just takes epics and renames them to features, right?” As a coach, your answer should be an emphatic no. Yes, features represent work which is larger than one increment. And yes, features can (and should) be split into smaller user stories. But in the SAFe framework, features represent something wholly different from traditional Scrum epics.

Agile Alliance continues:

“There is no standard form to represent epics. Some teams use the familiar user story formats (As …, I want…, So that…) while other teams represent the epics with a short phrase.”

SAFe provides a recommended approach for representing features. Leveraging design thinking and customer-centricity, the Features and Benefits (FAB) matrix allows the coach to emphasize the Benefit Hypothesis. Here is an example provided by Scaled Agile, Inc.:

From my experience, enterprises adopting SAFe embrace the measurable benefit aspect of the benefit hypothesis. In their mind, “if I am giving you the money to develop this feature, explain what I am going to get for my investment. Otherwise, maybe I will not give you the money to do it.”

As a coach, differentiating traditional epics from SAFe features will offer the opportunity to introduce or emphasize the concepts of Personas and Empathy Maps. In most cases, features should provide broader capabilities than a single persona. Embrace the traditional Business Analyst’s “what about …” questions as you map stories to features.

Embrace WSJF Early or Never

I have found that one of the most challenging SAFe concepts to introduce is Weighted Shortest Job First. SAFe references Don Reinertsen’s Principles of Product Development Flow: Second Generation Lean Product Development and specifies:

“Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs (eg., features, capabilities, and epics) to produce maximum economic benefit. In SAFe, WSJF is estimated as the Cost of Delay (CoD) divided by job size.”

Cost of Delay is broken into three components:

• Time criticality
• User business value
• Risk reduction-opportunity enablement

Time criticality

This is where the thrashing can begin as you introduce these concepts to both Scrum aficionados and Agile newcomers. A concept as seemingly simple as time criticality, can represent a not-so-subtle change to the organizational mindset. The Program Manager may come to the feature refinement session saying “all features should have a Fibonacci value of 5 since they all are required ASAP.” In fact, you may come to find that everything they are committing to for the Program Increment is “required ASAP.”

The “teachable moment” here is to emphasize that this thinking needs to change. If everything has the same time criticality, then it renders this aspect of WSJF meaningless. Product Managers must summon the strength to work with their Business Owners to determine if there are actual factors contributing to the time criticality of the feature. The classic example SAFe provides is the availability of a feature to demo at a trade show. Most organizations have other factors you can bring into focus if you’re creative:

• Does this feature relate to time critical regulatory compliance deadlines?
• Does the feature relate to a new product launch or “Go Live” with an established timeline? 

User business value

It’s also challenging to establish an understanding of user business value. Depending on how distant the Product Manager is from the business, they may have little to no visibility into the value the feature represents. As a coach, this is an issue you can point out. By bringing the business stakeholders closer to the process, the Product Owner can manage the horse-trading that frequently goes into prioritizing items for the business. Again, this requires the Product Manager to have the fortitude and self-assuredness to say no to individuals who may be higher on the corporate ladder.

Risk reduction-opportunity enablement

Finally, you must monitor the use of risk reduction-opportunity enablement to increase Cost of Delay value. Product Owners, business stakeholders and others can use risk reduction and opportunity enablement as a catchall for getting their feature prioritized. I have seen intellectual backflips being performed to game the system using the risk reduction-opportunity enablement value:

• The circular logic approach –  “This feature represents a significant opportunity whose value cannot be underestimated as to the potential opportunity this feature promises to provide.
• The Risk Boogeyman – “The lack of prioritization of this feature poses a significant risk to the organization whose implementation we cannot risk delaying.”
• The vague promise of realizing an amorphous opportunity – “We believe this feature represents a dynamic opportunity to advance our product and act as a catalyst to be a key market differentiator.”

This behavior related to the risk reduction-opportunity enablement offers an opportunity to emphasize the skills required to write a good feature. Items brought up during feature estimation should have been described as part of the Benefits Hypothesis. The feature estimation meeting should not be the first time someone references the seismic market-shaking opportunity this feature represents. The coach should also emphasize the measurable benefit the feature offers as it aligns to the proposed Risk reduction-opportunity enablement.

As a coach it is critical to set the expectation that estimating with WSJF is difficult, but it will get easier. By establishing these values as soon as the ART launches, they can act as a reference point. If the ART delays, defers or obfuscates on implementing WSJF, they will most likely never use this valuable tool.

Summary

The feature represents a key artifact on an organization’s journey to aligning teams of teams so they can deliver core business functionality. Their commitment to supporting Agile Coaching is a good sign that an organization is willing to embrace the level of change required to implement the Scaled Agile Framework. But it often takes time to create something great. Just as we advocate incremental change to our delivery teams, we need to drive incremental change within the Lean Agile Center of Excellence.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.