This section may seem like its coming out of order; shouldn't we cover the specifics of each work item before we talk about their organizational structure? Maybe, but I'm coming at the topic in this sequence because I believe that where these work items sit in the Big Picture is such a huge part of understanding what they are. With that said, let's dive into the meta-structure.
Understand these two points about SAFe:
Each configuration is a collection of levels and work items designed to implement SAFe for specific situations. These items kind of line up, but not exactly. Here's a handy table for comparison.
A quick review of this table reveals a few critical bits of learning.
Hopefully this chart makes some of the relationships between configurations and levels a bit more apparent. When I'm coaching teams I always make sure to emphasize the specific verbiage being used so that everyone is clear about which levels and work items we're talking about, and how those all play together. Configurations don't change that often, so there's less concern for confusion there. If you are helping your org implement SAFe, then do yourself a favor and hold a lunch-and-learn or some other training offering so that they can reach that same level of common understanding.
Since configurations are made up of levels, let's deep dive into each level separately. As we go through them, we'll be also looking at how the work items there are handled; how they are prioritized and evaluated. Some of this is overlap with deeper looks at the work items, but we'll be saving those for the final installment in this series. Let's start at the lowest level and work our way upwards.
The Team level is where your agile teams live and this is the easiest one to define, because it is literally the same knowledge and learning taught by Scrumguides.org; which is the standard for how Scrum should be implemented. Work items here are basic user stories and enabler stories, tech debt, etc. These all live in the team backlog which is a wish-list of what the organization might possibly want the product to look like. If an item is part of the team backlog there is a chance that it might eventually get done; however, if it isn't here, there's zero chance for the team to work on it at all. These items usually come from decomposed features, which live at the next level up.
The agile team's Product Owner is the sole owner of the team backlog, but she must work closely with her counterparts on the Program level to ensure the right things are in the right priority within the backlog. Anyone can/may write these stories and enablers, but the PO has the sole discretion (with Program guidance) on priority. All of these Team level items live in team backlogs, one backlog per team, and are managed by the teams in accordance with core Scrum teachings.
The Program level is the first level that sets SAFe apart from small-team Scrum, because it expands upon the Team level. Remember: the Team level is just Scrum! The core learning from the Program level is that almost every single role, activity and artifact that you have in the Team level is represented somewhere in the Program level, but at a larger scale. Of course this applies to the Program level backlog and work items.
Here, instead of stories, you'll find features, which are literally collections of stories that represent fulfillment of a specific stakeholder need. As with stories and story enablers, there are both features and feature enablers which can also arise from local context. In SAFe's terms, 'local context' means that the work items don't necessarily roll up into a parent item at a higher level. It's rare that this should happen, but sometimes it makes sense to structure things that way. As always, do what's right for your teams and your org.
Prioritization at the Program level belongs to the Product Management team and comes down to a process called Weighted Shortest Job First, or WSJF. This process takes a job's value as well as it's duration or effort into consideration in order to ensure that your teams are focusing on organizational priorities with a strong eye towards which jobs can get to 'Done' first. Using WSJF means embracing the truth that any completed story is more valuable to the org than any incomplete story, so you'll prioritize based on that.
The backlog at this level starts to veer away from what is happening at the Team level, but it still holds true to all agile, Scrum and SAFe values and principles. This backlog can actually be considered as a funnel for items to pass through before landing in front of the teams as stories. Think of it like this: The work being done at the Team level is turning stories into working product. However, at the Program level the work being done is turning features into working stories… that then get turned into working product at the Team level. Make sense? Activities at the Program level feed activities at the Team level.
At the Program level all teams are rolled into an entity called an Agile Release Train. This train is defined by a single Program backlog that holds all items that might possibly be worked on by the teams who make up that train. Obviously, this higher-level grooming work has to precede the Team's work, and this case it precedes it by a single PI.
Ah, the Large Solution, how do I love thee? I don't. The Large Solution mucks up so much about SAFe, but if you need this level… well, you just need it. If your solution is so big that a single Agile Release Train can't handle it, then you'll be using this level. So, here we go.
My personal whining aside, this isn't really all that complicated, think of it like a larger Program level. It will be comprised of those multiple ART's, and like the Program level, has a single backlog called the Solution backlog, that feeds into the various backlogs below it. Work items here are capabilities, instead of features. You'll see capabilities and enabler capabilities, and yes, they can also arise from local context. Just like the Program backlog, the Solution backlog relies on WSJF for prioritization, which is the duty of the Solution Management team, instead of the Product Management team.
We'll be covering configurations next, but let me state again that the only reason for deploying any configuration with the Large Solution level is because your product requires that you have multiple ART's to build it. That wasn't so hard, was it?
Welcome to the Portfolio level, where team rosters include hundreds of people, work items are huge and timelines can be measured in years. This, the highest level defined by SAFe, is where the C-suite lives and makes the larger directional decisions that can define the fate of the entire org. But don't let that preamble scare you, they are still using very similar processes to the backlogs elsewhere.
At the heart of the Portfolio level is the Portfolio backlog. This backlog holds the epics and enabler epics that define how the organization will build its value streams and deliver that value to the customer. This backlog is managed by the Lean Portfolio Management (LPM) team. Unlike the Solution and Program backlogs, which are prioritized by WSJF, the Portfolio backlog has its own process. At the left hand side of the backlog is blue-sky territory where any idea might possibly be entertained. As the epics move through the backlog, to the right, each one undergoes scrutiny in order to winnow out the lesser ideas and help the company choose the right work items to commit resources to. These steps are important, so let's look at each one.
This is where new business ideas can be expressed. Potentially anything can go in here, and the organization will start to review it for suitability.
The epic, or epic enabler, will be given a hypothesis statement, the WSJF numbers will be calculated and WIP limits will be applied.
Here is where the business owners, epic owners and product management team will start to estimate costs for the epic, refine the WSJF numbers, identify the MVP and apply a Lean Business case.
This is the WIP-limited column where approved, and ready to be worked on epics wait for an ART to have the resources to take them up. WSJF is regularly applied here to ensure the proper prioritization.
As ARTs have the capacity, epics are pulled from the Portfolio Backlog and then decomposed into the appropriate Solution or Program backlog as either capabilities or features.
AS the epic is being built it is always being evaluated for suitability. When the work is good for the customer and the organization, then more capabilities and features will be built and fed into the appropriate backlogs. When the epic is no longer beneficial to the company, then it will be completed and/or another approach to the problem (another epic) brought into play.
Now that we've reviewed each of the four levels, let's dive into how the four configurations arranges them to achieve specific needs.
Consisting of only the Team and Program levels, Essential SAFe is the core that everything else is built upon. In this configuration you have two levels of backlogs:
Essential SAFe is designed to be utilized as the starting point for most SAFe implementations. With the Program level and features being the top of the food chain, this configuration is best suited for medium-sized companies where the executive branch is closer to the actual work. It also works well in larger organizations that are just starting their SAFe journey and want to 'kick the tires' before committing to a full-scale implementation. Additional levels can be added on top after SAFe has proven its value to the organization, or as needed.
Backlog management is pretty straightforward with the Product Management group managing requirement intake, feature curation and assisting PO's and teams with feature breakdown and iteration planning via PI timeboxes. At each PI planning session, teams will commit to delivering stories that have been decomposed from features in order to deliver business goals to the organization.
The next configuration takes Essential SAFe and adds the Portfolio level to the top of it. This level adds in epics as the top-level work item and a new method of curating those epics, the funnel we described above. The Lean Portfolio Management team is in charge of this backlog and uses the funnel to ensure that the company's value streams are being delivered to the customer. As stated before, epics continue to be elaborated until they fail the "pivot or persevere" decision that is part of the LPM team's duties.
Portfolio SAFe is the logical next step after an organization has experienced initial success with Essential SAFe. Alternatively, many companies simply start here and can immediately start to see full-stack benefits of large-scale work management.
For all those times when your solution is just too big for a single ART! The Large Solution SAFe will be implementing Essential SAFe, but with a Large Solution level put in over the top of the Program level. In most every respect this level operates as a larger Program level, but with multiple Program backlogs rolling up into the Solution backlog. The work items, capabilities, are still timeboxed to a single PI, but now may decompose into features sitting in different ART's.
Why would you need multiple ART's? Well, obviously to service extremely large solutions, but also when your solution has hardware, software and/or firmware aspects. These various pieces of the product have intricate interdependencies, but the skills required to produce them are varying. In such cases, many organizations will organize a software ART, a hardware ART and maybe even a firmware ART. The Large Solution level is where cross-train dependencies are tracked and mitigated and where cross-domain planning occurs.
The whole enchilada, as it were. Full SAFe brings all four levels to bear on an organization's challenges. You'll have four backlogs:
This level is definitely the big-leagues of agility at scale. Successful implementation requires the full, consistent and sustained attention of the entire organization. From PI to PI the company should see substantial progress towards epic completion with strong feedback into the critical "pivot or persevere" decision. Bi-weekly demos of working systems should serve as a real-world progress report of the uber-team's effectiveness.
This installment has been a big one. We've reviewed the distinctions between levels and configurations. We've also dove deeper into each level and then into each configuration. Along the way, we've reviewed how the backlogs feed into each other and how the work items support the organization in its efforts to satisfy customer needs.
I want to close this section with one of the most important points about this entire structure. At every level of SAFe the theories, values and principles defined in agile, Scrum, and even SAFe itself are all honored and practiced.
The work items and backlogs are the mechanical representation of these theories, values and principles, but can never be successful without them.