Regardless of whether your organization uses the Scaled Agile Framework®, prioritizing Features with WSJF can help you avoid “gold-plating” products with extra features — and can create a dynamo that enhances profitability by avoiding costs rather than cutting them. 

 

Introducing SAFe Features

The Feature construct helps to break a behavior that often manifests early in an organization’s adoption of Agile thinking. Very early on, if not almost immediately, some variation of the concern “the user story wasn’t specific enough… we need more detail” starts to coalesce during demos and retrospectives. 

Just like the fruit flies that seem to appear out of nowhere when you have left some bananas on the counter for too long, the “we need better requirements” refrain seems to spontaneously appear. And just like those fruit flies, the best answer isn’t to buy more bananas, but to only buy the bananas you are likely to eat. 

This is where the Feature construct comes in.

While most of us are likely familiar with the idea of a feature in the general sense, a Feature in SAFe has a very specific purpose and format. In SAFe, the purpose of a Feature is to convey an idea of what benefit can be expected by implementing an enhancement to a product or service. SAFe recommends a lightweight format like a “Features and Benefits (FAB) Matrix”  and not the popular “user story voice” format in order to minimize confusion.  The FAB format is elegant in its simplicity and provides answers to common problems that arise in the product development lifecycle. 

SAFe Features and Benefits Matrix

Features and Benefits (FAB) Matrix © Scaled Agile, Inc. Used with permission.

 

The Benefits of SAFe Features

First, this deliberately simple format helps to avoid wasteful work by discouraging premature specificity. When we are building products and talking to customers and other stakeholders, the most important thing we can convey is the “what’s in it for me” angle: that is our benefit hypothesis. Customers don’t care about our acceptance criteria, or our non-functional requirements per se, they just want something that provides a benefit at a level of quality they will pay for.  

Second, the “benefit hypothesis” element helps to ensure that the “why” of the work does not get lost. Unlike the user story voice (“As a X, I want Y, so that Z) format, the FAB format helps to communicate the benefit to wider — and conceivably unintended — audiences. Our stakeholders will always want more detail, of course, but a FAB table provides a solid anchor for a conversation on specifics.

Third, this format nicely supports important Agile, Lean and SAFe principles. “Maximize the amount of work not done” from the Agile Manifesto immediately springs to mind, as well as SAFe Principle #10: Organize around Value. By not having a lengthy template to complete, we allow ourselves to postpone work to the last responsible minute when we are more confident the feature can be adopted and subsequently delivered.

 

What Features Are NOT

It’s equally important to understand what a Feature is not:

  • A feature is not an Epic. Within SAFe an Epic has a completely different purpose and a completely different format to match. Features must be sized to fit within a Program Increment: an Epic will normally span multiple Program Increments.
  • A feature is not lengthy. Even when fleshed out to the maximum responsible level, a feature should be easily represented on a slide with a decently large font size. The FAB Matrix alone is sufficient for a surprising amount of product management conversations. 
  • A feature is not a requirement. In SAFe, the feature is an expression of a desired benefit, which the derived implementation may or may not generate. Requirements specify “The System Shall”; a Feature in SAFe never lets us forget “The System Why.”
  • A Feature is not “development-ready.”  It represents an idea that can be easily socialized with stakeholders who may not be very familiar with the day to day workings of the ART but still have an interest in how outcomes are reached. As such, it is not going to be specific enough to use for development: it must be further refined into smaller encapsulations of (hopefully) independent units of value normally expressed as user stories.

Now that you are as in love with Features as I am, I’m sure you are forwarding this article to all of your colleagues using a lot of exclamation points, right?!!? Nothing stands between your newfound love of Features and operational excellence!!!!!!!!!!

If only it were so easy. 

One of the most powerful — and completely inaccurate — myths in the modern corporate world is the insistence that “tools are just tools.” When we run our business using software, we create powerful incentives to use the software as implemented. If your tooling doesn’t support a Feature entity, or it doesn’t use the “SAFe template,” then your enthusiasm will remain forever dampened because the construct will never be a part of your business processes until the tool is changed to match. 

I’m not trying to be Donnie Downer here — just be aware that it’s not as easy as a consultant might make it out to be in a blog post. If you only ever implemented SAFe-style Features in your company, you would be a giant step ahead of everyone else on your journey to mature your Agile practices. Your backlogs would be more orderly than the gallery at Wimbledon, your teams happier than the winner of Wimbledon, and your desk adorned with awards to dwarf the trophy from Wimbledon. You would have the respect and admiration of your peers, your dog would bring you your slippers … okay you get the point: Features are nifty.

Now what if I told you that there was a way to use Features to to not just deliver value to your customers, but to drive change in your organization by reframing the relative value of the work within the scope of potentially the entire product portfolio? You can have all of this and more, thanks to Weighted Shortest Job First (WSJF). 

 

The Power of Features + WSJF

WSJF (or “wiz-jiff” if you are feeling spicy) is a multi-variable algorithm that can be used to quickly rank different features by value using four different dimensions. WSJF was developed by Don Reinertsen based on principles of Lean flow and popularized in his book The Principles of Product Development. In the Scaled Agile Framework, WSJF is the default practice to prioritize Features and Epics because it helps address multiple deficiencies that commonly exist in most organizations today:

  • WSJF favors “fast” over “perfect” prioritization. This is essential for true business agility because we want to create frequent conversations about priority and value between business and IT so that we maximize our readiness to seize opportunities and mitigate issues as they arise. A relative estimation technique helps us avoid getting bogged down in creating fictional ROI calculations that we can use to retroactively justify the funding approval we actually got over coffee last Tuesday.
  • WSJF can help to prioritize seemingly unlike things. It is very common to think of priority only in just one dimension: urgency, risk, or whatever the boss wants.  The “weighted” part of WSJF allows for these different dimensions of priority to be identified and discussed more readily than in a standard requirement JAD session that is driven by an arbitrary release date. This has a side effect of giving stakeholders with seemingly different agendas another opportunity to reconcile those agendas. I might not get excited about 2FA, but if the CISO gives it a 20 out of 20 possible score for risk mitigation, I’m at least a little curious about why.
  • WSJF provides a credible answer to the question “Why is this at the top of the list?” The sort order that comes out of WSJF isn’t binding: it only represents a context-restricted but still nuanced view of the opportunities available. The backlog could and should be adjusted to reflect implementation dependencies (and even the whims of a particularly noisy stakeholder if it comes down to it), but the initial sort provides a defensible prioritization that helps product managers fight the impossible fight of trying to keep everyone happy.  
  • WSJF doesn’t require consensus to work. The best use of the WSJF process is to foster the conversations among stakeholders that can lead to better alignment, but it doesn’t require agreement to get started. Your VP of Marketing may not get that Content Management System they want next PI, but they will know why.

In short, WSJF is a really effective tool to figure out which, of the possible set of things that could be worked on next, would deliver the most bang for the least buck. The process is flexible enough that it can be used in non-software (I once used it on my to-do list of house projects) and non-agile contexts very successfully, and it doesn’t require any math more complicated than division. In practice, it is useful to restrict the voting on “job size” to only those who have sufficient expertise to make an educated guess. This doesn’t have to mean every member of the ART, but a few well-respected experienced technical leaders must be a part of the scoring process and subsequent conversations.

SAFe - WSJF

Dividing the Cost of Delay by the Job Size produces a WSJF score that promotes economic thinking and Lean flow through the product development process. © Scaled Agile, Inc. Used with permission.

 

If it’s not clear by now, both Features and WSJF are independently useful and valuable practices. Both are worth trying out and experimenting with in order to help your organization build a fluency in the new language of Agile product development. After a few backlog sessions, try combining them. Here’s why.

FEATURES + WSJF = ELLINGTON + FITZGERALD

I have a very good friend who likes to use Jazz as a metaphor for Agile delivery. I love this because:

  • Jazz requires a high amount of skill from the musicians. They have to be competent enough in their own craft that they can listen to each other and react not just quickly, but beautifully.
  • Jazz is highly disciplined. While the improvisational nature of Jazz is supported by a shared language of riffs, patterns, and conventions that create a structure.

“Duke” Ellington, one of the early Jazz greats, laid the foundations for not just Big Band jazz, but countless musicians and interpretations after him. Ella Fitzgerald, the Queen of Jazz, used “scat singing” to convert her voice into an instrument that could improvise with the band through the use of sounds rather than words. When the Duke and the Queen got together to perform “It Don’t Mean a Thing (If It Ain’t Got That Swing)” they took an already thirty year old classic and elevated it to the status of Legendary. If you haven’t guessed by now, combining Features and the WSJF process will elevate your backlogs and make them sing. Here’s how to get started. 

Recall that a Feature, by definition, must be sized to be completable by the ART in a Program Increment. And where there is an ART to do the work, there was an ART Launch process that culminated in a PI Planning. While to the rest of the organization it may look like the ART just “came out of nowhere,” those of us who have done this once or twice know the truth: An ART launch is a small miracle. 

Months of work and planning lead to a 2 (ish) day event called PI Planning that generates gigawatts of energy and almost invariably juices the organization to produce something of value faster than ever before. With a little luck and a lot more work, the first successful PI is followed by another, and then another after that. Soon, the rest of the organization takes notice. Stakeholders proliferate like the dandelions in my front yard. People start asking to come to PI planning “just to watch.” Everyone wants to get a little piece of this magic delivery train for themselves. Normally this would be a great moment to launch another ART and start the whole process all over again, but unfortunately most organizations that need to do this do not realize it until it’s too late. Meanwhile, new feature requests come in, or even enhancements to other products, all of which are contending for the same pool of now-magical teams. What’s a new product manager, flush with success and Wimbledon-sized trophies stacked around the place to do?

I will let you in on a secret: your people were already incredibly smart and talented. The magic you created was the power of focus. 

We really can do amazing things when we work together, it’s the great secret of our species. Letting in every cat and dog backlog request jeopardizes that focus, yet it’s ultimately the responsibility of the product manager to maintain that focus and still respond to the changing needs of the organization. This is where expertly applying WSJF and Features can help flip the script and go from an Agile Release Train wreck in the making to an opportunity to level up your business agility. 

Combining the Feature practice — which intrinsically is intended to communicate benefits — and WSJF — which recognizes that there can be multiple kinds of benefit, not just customer satisfaction — creates “persevere or pivot” moments during refinement conversations where existing investments can be weighed against new opportunities that are unlike anything done so far. The conversations around the scoring will naturally start to recognize when a given feature, capability, or product is “done enough” because the scoring by stakeholders will start to reflect a consensus belief that more opportunity lies elsewhere. Even better, this process does not rely on altruism: attempts to “game the system” still encourage desirable behaviors, such as reducing the job size enough to convince others that your pet project is actually feasible. To actually meaningfully pervert the system would require a conspiracy that would work against immediate self-interests of those who want stuff built versus those who have to build and maintain the aforementioned stuff.

With practice, this advanced backlog refinement technique creates a virtuous cycle that leads to the organization observing multiple benefits over time. Two such benefits are:

  1. Quick and cheap experiments can rise to the top of the list because of the scoring algorithm which heavily favors smaller things over larger ones. Small batches flow through the delivery lifecycle faster, which in turn feeds continuous exploration processes.
  2. Profits are maximized over the lifecycle of the product by discouraging adding new features that no one wants, decreasing investment and smoothing out the ROI curve.

Using Features with WSJF helps a product manager reinforce the message that the ART is prioritizing future benefits, benefits can be realized in a variety of ways, and that the organization values flow and consistent delivery more than stakeholder capitulation. 

 

Making Your Backlogs Sing

Features are the currency of Scaled Agile, and for a good reason: our customers ultimately care about the benefit they are going to receive from our product, and Features are tailor-made to keep focus on those benefits. 

WSJF is an elegant prioritization system that, when combined with the Feature construct and the scaling framework provided by SAFe, organically encourages natural changes in product strategy that are grounded in market realities and not political influence. Prioritizing competing interests along only one dimension can foster narrow and short-term thinking and deepen the divides between organizational silos. 

Creating productive conversations between stakeholders helps to build understanding, and eventually empathy and trust, which are goals worth pursuing even if we can’t put a price tag on them. I hope you get to experience the feeling of making good music with your friends, the feeling of being part of a high performing team working in unison to do great things. Go make your backlogs sing.

 

How to Learn More

Interested in learning more about SAFe? Check out our SAFe Certification programs To learn more about WSJF and Features, see Leading SAFe and Agile Product Management in particular.

Or read some of our recent writing on related topics:

*written by Gianpaolo Baglione