When I am working with a client who is new to the Scaled Agile framework, or I'm delivering a training course for soon-to-be agilists, there's always a large number of questions about how the SAFe backlogs and work items relate to each other. These questions are understandable when you look over the Big Picture and see all of the different elements that are on it! Read on, folks! Let's see if we can't see both the forest and the tress, shall we?
Starting today I will be presenting a three-part blog series that is aimed at de-mystifying the SAFe backlogs. We'll talk in-depth about each backlog (Did you know that there are four of them? Yup, one for each level of SAFe.) We'll talk about the work items and how to manage them; and we'll talk about how the entire process works together to keep your teams building the right thing. No matter which SAFe configuration you are implementing, we'll be talking about how you can use these backlogs to help your organization to take ideas from concept to cash.
"You are only as good as your backlog."Me. To anyone, at any time, in any place.
(Seriously, it's that important.)
In the first installment of this series, we'll be focusing on the four backlogs themselves; and for context, we'll be talking about a SAFe 4.6 Full configuration. If you haven't already taken a look at the new aspects of SAFe 4.6, this might be a good time to do so, because several of the new pieces are going to play a large part of this article. The Full configuration allows us to see all four of the backlogs, in their proper place with respect to each other. I've faded out the remainder of the Big Picture, in order that the backlogs are easier to see. Additionally, I've left four of the new SAFe 4.6 Core Competencies unfaded so that you can see which competency aligns with which layer.
(Quick note: Throughout these articles I am using several images and pieces of images from the Scaled Agile Framework website. These images are copyright Scaled Agile Incorporated.)
While that image helps you get the lay of the land, let's also take a look at this much more abstracted version. Here, I've cleared away everything that isn't backlog, work item or competency. This image shows which backlogs and elements relate to each other, and will frame a large portion of the following conversation.
"Big fleas have little fleas upon their backs to bite 'em,Siphonaptera by Augustus de Morgan
And little fleas have lesser fleas, and so, ad infinitum."
In order, each backlog is referred to by which level of the SAFe Big Picture it sits on, and has a specific work item that lives within it. At the Portfolio Backlog level are the Epics; these are huge pieces of work that take up a substantial portion of the organization's efforts over large pieces of the calendar. Epics are not limited to teams, trains or even Planning Increments, but only by the "Pivot or Persevere" decision wherein the leadership determines if the results of the Epic meet its intention. "Hey, we built this thing. Is it good for our customers? Is it good for the organization?"
Below that, in the Solution Backlog are the Capabilities. These pieces of work are bound by Planning Increments, but are not bound by Agile Release Trains. In other words, Capabilities can span multiple ARTs, but not a PI. Outside of this distinction, Capabilities look and act the same as Features but are only implemented where the Large Solution Layer is involved in your deployment. We'll cover the various SAFe configurations in an upcoming installment.
Features sit in the Program Backlog and are the primary means of tracking progress towards the organization's goal. They need to be sized correctly so that they fit within individual Planning Increments, but can span multiple teams on the same ART.
In almost every case a lower-level work item will roll up into a single work item at the level above it in a many-to-one relationship. Therefore multiple Stories will roll up to a single Feature; several Features will roll up to a Capability and several Capabilities will roll up to a single Epic. We will talk about exceptions in a few more paragraphs.
"I have no idols. I admire work, dedication and competence."by Ayerton Senna
The last part of the abstracted image is the Competencies. These are new in 4.6 and are excellent ways to focus on what the organization should be doing at that level of operations. If you have implemented any configuration other than Full, then you will not need the competencies, backlogs or work items from the levels that you don't have. Since they are new to the Big Picture, let's take a better look at each one.
Lean Portfolio Management - LPM is a broad set of skills that are aimed at giving your organization the tools needed to choose the right work. Utilized by the highest level planners in the company, this competency provides the means for organizational leaders to carefully select the right things to work on, build in the proper metrics to track the work's progress, and then regularly review the work to ensure it is what the org needs. Further reading on LMP will teach you more about how to manage these huge work items and keep your organization on track.
If your organization needs formal training in LPM then the Leading SAFe certification course is a good place to start. Take a look at our upcoming Leading SAFe classes here.
Business Solutions and Lean Systems - This competency sits in the Large Solution layer and is the set of skills that lead an organization away from stage-gated approaches to solution delivery and towards flow-based delivery of large solutions. Solutions at this layer are large and complex enough to require more than a single ART to deliver; often the solution will have software, hardware and even firmware components, each with their own team of teams.
Work items within this layer, Capabilities, are prioritized via a method known as "Weighted Shortest Job First," or WSJF, which teaches practitioners to prioritize based on the amount of work required to get a work item to done as well as business importance.
DevOps and Release on Demand - At the Program layer, the backlog is managed via DevOps practices. Here at Allison Agile, we are huge believers in solid DevOps practices and culture. The competency is practiced throughout the enterprise, but it really lives and breathes in the Features that are managed within the Program layer of SAFe; and the Architectural Runway that is expressed at this same layer. DevOps are great, no doubt, but building your organization up so that it can release on demand is a complete game-changer. Using the Features and the Runway plus this Competency will completely revolutionize how you do business.
Like Capabilities, Features are prioritized primarily via WSJF.
SAFe has a new certification entirely focused on DevOps, called the SAFe DevOps Practitioner (SDP); here is a link to our upcoming SDP classes.
Team and Technical Agility - SAFe maintains that "Nothing beats an agile team. Except a team of agile teams," and it's true. But it also follows that your team of teams will only be as good as the teams that make it up! The Team level of SAFe fully embraces ScrumGuides.org and other best-in-field team agile practices. Using this Competency is the leading indicator of team-level success for any team.
Stories at the Team level are prioritized by the Product Owner with input from the Product Manager and Dev Team.
"A good teacher must know the rules; a good pupil the exceptions."by Martin H. Fischer
A couple of points up above don't always apply, let's cover those here.
Configurations Other Than 'Full' - In instances where you are implementing Essential, Program or Large Solution level SAFe you obviously will not have all of the backlogs, work items or competencies in play. We'll cover various configurations later, but know that generally you will implement the pieces needed, roll up work items to whatever is the highest level item you DO have and keep on trucking.
Work Item Roll Ups - Every work item should roll up to the item above it... but it doesn't have to. SAFe allows that any and all work items other than Epics can exist as part of local context that doesn't require a spot in the hierarchy. In my experience these are the exception rather than the rule, but know that it can happen. Just make sure to account for these floating work items in your reporting.
Enablers - We'll cover these in full in our next installment, but the thing you need to know now is that there are Epic Enablers, Capability Enablers, Feature Enablers and Story Enablers. They look, feel and act just like their customer-focused counterparts but are aimed at technical things the teams and organization needs in order to win. Generally I will not be including Enablers in my graphics in order to keep the graphics clear and readable.
So far we've taken a close look at each of the backlogs, their place on the Big Picture, the competencies needed to manage that backlog and the work items living within them. Not too bad for a start, I think.
Our next installment will take a closer look at each level and configuration, as well as how they play together. We'll see you then! Also, if you live or work in the Austin area, I'll be delivering this content at the Agile at Scale SIG (part of Austin Agile) on Friday Nov 16th. Please come on down and say Hi!