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.