SAFe Backlogs 1.3

Introduction 

Thanks for sticking with us through this three part series on SAFe backlogs! We've finally arrived at the final portion, where we'll be talking about the actual work items themselves. To date we've gotten a good look at the "lay of the land" and seen where all of the SAFe backlogs exist, as well as taken a deeper look at how they feed each other and help shape an organization's approach to work. Along the way we've talked about the work items in broad terms, but now we are going to dive into all of them.

The Iron Triangle 

Everyone knows the Iron Triangle. It's that beautiful, and at the same time awful, method of looking at projects that highlights the three constraints: resources, schedule, and features. I don't want to review the triangle, or even use it as it is intended here. However, it does make a great lens through which we can view the various SAFe backlog items.

When talking about the work items I like to use the three sides of the triangle to set the scope of that work item. As you move up or down the hierarchy of items you'll find that all three constraints (functionality, resources and time) will scale appropriately. This view should help you keep track of which work item covers what scope across those three factors.

Let's start at the bottom and build our way up.

Stories 

Description:

Stories are the lingua franca of development teams and describe the actual work needed to implement the intended system. Every other work item on this list describes the system intent, but stories describe the actual work to be done to realize that intent. The story should have a description that talks about

1. an intended customer interaction
2. a beneficial outcome
3. a system behavior or function

In all three cases the story description talks about the destination, it does not describe the path to get there; and all three are concerned with the nuts and bolts implementation of the strategic theme or the value stream that governs this train. In other words, your stories should tell your team what to build but not how to build it.

A common hazard with stories, especially in organizations new to any type of agile is that they become containers for requirements. I see this in companies who are having a hard time trusting the story to get the job done. Instead of a long list of requirements, the story's acceptance criteria and definition of done should be used to help decide what is and is not acceptable work.

With that in mind, a good story will have three pieces of content:

1. Story description
2. Acceptance criteria
3. Definition of done

None of these should be long, extended laundry lists; instead they should all be brief and to the point. This brevity is critical to striking the perfect balance between management being proscriptive and the development team over-developing the work. Being out of balance in either direction can be disaster. The local context will have a huge impact on what that perfect balance looks like, and can be a maturing factor in how the team's stories are crafted.

At the end of each iteration, every team must demonstrate its stories in concert with every other team on that train. All work should be shown in a fully integrated environment, fully functional and playing nice with all other code written by other teams on the same train. This integration is critical because it is the primary method that SAFe uses to mitigate the risk of cross-team dependencies. Catching collisions between team's work is usually quite a bit less painful at the iteration boundary than catching them as part of a larger deployment push; say, every quarter or so. Less code to integrate means fewer issues, and at every level of SAFe, this framework pushes for smaller, tighter work items.

Resources:

All stories should be scoped so that a single development team can get them to done, with all testing and integration! While the team's Product Owner is the single person responsible for this scoping, the entire team must be involved in the crafting of these stories. Remember that the story itself is not valuable to the organization; the shared vision of what is needed is where the real value lies. That shared vision cannot be built when the PO writes her stories in a vacuum, and then only shares that vision at the team's Iteration Planning event. The entire team should be talking, crafting and writing stories throughout every iteration.

TimeBox:

Each story should fit within a single iteration of the team's effort. For most SAFe implementation, this is a two-week timebox. Since the story is scoped on a team-by-team basis, not every team's stories will be of the same size. But keep in mind that each story should be able to get completely to done within this two-week timebox. Yes, architecting your teams so that they can achieve this can be a pain, but this single statement is about as fundamental of a step towards true agility as you will ever take. If your teams are truly cross-functional, then you have built the foundation that all of the rest of your agile wins will be built upon.

Enabler Stories:

Enabler stories have all of the same aspects as a user story with two exceptions.

1. They are not written in a user voice, because…
2. They do not focus on the user.

The user voice is the standard form of writing a story description that goes, "As an X, I want Y, so that Z." Since the target audience of all enablers is the development team themselves, it is acceptable to write their description in language the team can understand. Enabler stories talk about things that need to be done in order to 'enable' the delivery of the actual user stories. As such they are the fundamental input to the architectural runway and their development work will need to precede the consuming story's work by at least a sprint or more. So where a user story will deliver a piece of functionality to the user, an enabler story will deliver a piece of exploration, architecture, infrastructure or compliance back to the development team. Outside of that change, they will still have descriptions, acceptance criteria and definition of done. They will still be sized and demo'ed and they will still fit within one iteration and are deliverable by one team.

Features 

Description:

Features are, as indicated, larger than stories. Ideally, most of a team's stories will roll up into an ART's features. In some aspects, features have their own scoping, but by and large, the feature is done when all of the stories assigned to it are done. If you have implemented a modern toolset for your development teams to track their work, then that tool will provide you with roll-up reporting on the completion percentage of your features.

Features provide delivery of a stakeholder need, some semi-major piece of functionality that your stakeholders are or will be excited about receiving. It may take several stories to complete the feature, but that is their nature. They live in the Program backlog and are managed by the Product Management team.

Each feature will have the following four parts:

1. Description - Since features can potentially serve multiple user roles, this is not the user story voice that stories are written in. Simply describe the functionality that is intended
2. Benefit hypothesis - A proposed measurable benefit to the org or customer
3. Acceptance criteria - Identical to those used for stories
4. Minimum Marketable Feature (MMF) - See below

Resources:

Since the feature lives at the Program level, it can use up the full resources of that level's resource grouping; ie the Agile Release Train. Proper scoping of stories can be challenging, but scoping features can be doubly tough. Know that the longer the train runs, the better the Product Management team will be at properly sizing the ART's work items. For your first few PI Planning sessions, have your PM team do their best and know that with repetition, they will get better.

Having said all of that, know that the goal is to slice up features so that they easily fit within PI boundaries. As with stories or any other work item there are multiple methods of properly slicing these, the internet is full of strategies and methods, so break out your Google-fu and look some up.

Timebox:

At the Program level the default timebox is the PI, or Program Increment. Depending on how your organization has implemented them, the PI's are usually 8, 10 or 12 weeks long. Whichever length you decide on, keep it consistent so that your PM team can get a feel for what proper sizing of the features should be. Just like with scoping them for teams, the PM will get better at scoping features for PI's.

The MMF:

We do need to talk about the Minimum Marketable Feature (MMF) for a few minutes. Agile practices are predicated on using feedback loops to ensure that your team is building the right thing, and building it right. For both the feature and capability, the MMF is the way to do this.

Everyone is familiar with the MVP, or Minimum Viable Product. It's the smallest slice of our product that is functional for an end-user. We build it and then put it in front of those end-users to gather feedback about our efforts. An MMF is exactly the same thing in concept, but the scope is smaller. Instead of defining a small slice of an entire product, let's just define a small slice of this feature (or capability) and build towards that first.

Have you ever had your favorite app get updated with a new feature that is only just barely there? It might have been missing some polish or was obviously incomplete despite it being functional? That was an MMF. Most likely the app designer continued to provide updates over the next few cycles until that feature was fully fleshed out and working. That was an MMF, and it most likely served to give that app designer immediate feedback on how useful the feature was.

MMF's have two other aspects that we need to pay attention to. The MMF should be used to prioritize the child work items, with an eye towards completing the MMF before completing any other 'polish' work items. This allows the product folks the opportunity to gather feedback as soon as possible without having to wait for the feature's less critical work to be completed.

Additionally, the MMF should have metrics built into it so that the Product Management team can make data-driven decisions about the validity of this work. What is the purpose of this particular feature? Generally it should be defined by the benefit hypothesis. At the earliest possible point, you should be capturing data to either prove or disprove that hypothesis.

Building a Feature

Building a proper feature involves these steps:

1. Define a simple description
2. Define the benefit hypothesis
3. Write acceptance criteria
4. Define the MMF to support the hypothesis!
5. Add metrics to the MMF to prove/disprove the hypothesis

Enabler Features:

As with enabler stories, enabler features speak to things that the org needs to get done in order to continue to deliver functionality to the user. These are identical in look, feel, and function to the regular user-focused features, but they are internally pointed. You will still define a benefit hypothesis, acceptance criteria and an MMF.

Capabilities 

Description:

Truth be told, capabilities and features are almost exactly identical. They both have the same four pieces, they both use the same grooming process, and they both have the same scoping.

Almost.

The single thing that makes capabilities and feature different is that a capability lives in the Solution Backlog, therefore it should talk about functionality that will take multiple ART's to deliver. Traditionally this might be in the form of a product that requires software, hardware and firmware to deliver; such as a cell phone or autonomous vehicle; things along those lines. In these cases, the development staff might be divided into a software ART, a hardware ART and a firmware ART, as an example.

You can easily see that those three trains would have deep cross-train dependencies on each other. So, the Large Solution Level is used to manage and clarify these dependencies. The capability is the work item that does that. If an epic breaks down into functionality that can be delivered by a single train, that goes straight to the Program Level and its features. This level only has items that are cross-train, that discipline will help keep the cross-train dependencies clearly visible and trackable.

Resources:

Any and all of the teams sitting on one or more ART's. Since individual trains are roughly estimated to be up to about 120 people, it's easy to envision solution trains of thousands of people.

Timebox:

Even at the Large Solution Level the basic unit of time is still the Program Increment - 10ish weeks of work. This can throw a lot of people who are new to SAFe, but it makes sense. The point of agility is that you do NOT do all of your planning up front, you parse it out over chunks of time. Well, ten weeks seems to be a sweet spot between being able to predict and being able to deliver and being able to respond to changes. So we stick with the PI as the basic unit of time.

The MMF:

See the above entry for MMF under the Features section.

Enabler Capabilities:

Exactly the same as enabler feature and stories, but the resource scoping is for more than one ART. Otherwise the same.

Epics 

Description:

So far we've been using the iron triangle as a lens to talk about the scoping of these work items. The epic is where that paradigm breaks down. Epics represent huge pieces of effort that the org has decided to undertake. As such, they require some special handling, and all of it happens at the Portfolio Level.

Lean Startup Cycle:

The Lean Startup strategy recommends a highly iterative "build-measure-learn" cycle that fosters innovation and limits risk by reducing planning and budgeting horizons to smaller blocks of time. In it's nature, the Lean Startup embraces the core functionality of any agile practice; the "Plan-Do-Check-Adapt" of the Shewhart Cycle. In implementation, the cycle advises that you build the smallest thing that you can, get it in front of your target customers, gather their feedback and then elaborate the product from that point forward. This is directly counter to traditional project management practices that prescribe heavy up-front planning and design, with minimal feedback until late in project's life cycle.

Value Streams

Value Streams define how the user goes from initial contact with the organization to a transactional interaction; a purchase, a sign-up, etc. The Value Stream is a critical part of the life of epics because they provide directional governance on which epics the org should be pursuing in order to capture, retain and delight the customer. SAFe Program Consultants can lead you through a Value Stream Workshop to guide your group in identifying your streams. Since your ART's will strongly align with those Value Streams, you should be engaging an SPC to assist with this workshop as early as possible in your SAFe journey.

Epic Hypothesis Statement

As critical as the Benefit Hypothesis is to a feature or a capability, the Epic Hypothesis is just as critical here. The statement takes the form of:

 The epic hypothesis statement is critical to scoping what is and is not within the scope of the epic's intended functionality. It should be clear and concise enough that throughout the epic's life cycle the statement can be used as a litmus test to ensure the right capabilities, features and stories are being worked on.

Minimal VIable Product (MVP):

Each epic should be written with an MVP designed to test out the Epic Hypothesis. How you define the MVP is subject to local context, but it should provide at least enough data to allow the Portfolio Level team members to make data-driven economic decisions about continuing to deliver the epic; the "Pivot or Persevere" decision.

Note that in the context of SAFe, the MMF and MVP are very similar. They both define the least amount of functionality needed in order to answer the critical question, "Did we build the right thing?" Their major difference is the scope of that functionality. An MMF answers the question for a single feature or capability, however an MVP answers it for an entire system.

Resources and Timebox:

Instead of scoping epics in the same manner as stories, features or capabilities, epics are only scoped by the "Pivot or Persevere" decision point. If you have crafted your epic correctly then it has, as its highest-priority deliverable, an MVP that will allow the Portfolio team to look at actual user data and determine if the epic is carrying its weight. Any capability, feature or story that doesn't directly drive the implementation of the MVP will delay the data from getting collected and analyzed; this should be avoided at all costs or you risk spending effort and capitol on functionality that may not be valuable.

At the end of each PI the Portfolio team will review data collected from the epic's MVP and determine if the organization should stop building that epic or continue. They may choose to pivot for several reasons:

• The epic has delivered on its promise and is complete
• Market changes have rendered the epic moot
• Building the epic has uncovered something that we didn't know beforehand and that knowledge invalidates the epic
• We've uncovered a better method to delighting our customer
• Etc

In the event that the organization decides to persevere then that epic will be broken down into additional work items that extend its functionality or improves customer response to it. Those new work items will be fed into the funnel for development by the teams in upcoming PI's.

Regardless of the reasons, the Pivot or Persevere is the heart of the epic's lifecycle. Use this unique feature to guide the development of both the epic card and the actual product both.

Conclusion 

Throughout this series we've taken a long look at elements of the SAFe architecture that contribute to how we create and manage the work items, and how those items help our organizations create the right thing. In other words, we've walked through the framework to go from concept to cash. We've covered everything from the structure of levels and configurations down to the pieces of each work item that make them tick. In addition to a broader understanding of SAFe I hope you've also realized that none of these work items lives in a vacuum. Every part interacts with all of the other parts to create an ecosystem that we can harness to guide our product development.

Thank you for reading through this!

Additional Posts in This Series