SAFe Backlogs 1.3 - Features

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.