Right-Sizing Features for SAFe Program Increments

By Ian Spence, SPCT, Chief Scientist at Ivar Jacobson International

One of the key activities that will help make your SAFe program a success is the careful preparation of your Features prior to Program Increment (PI) planning. And one important aspect of this preparation is to slice up any of the targeted features that are too large to be easily delivered within a PI.

In this guidance article, we will share some of our experiences in slicing features into smaller ones. 

Aren’t Features Just Big Stories?

It’s very tempting for Product Managers and Product Owners to treat features as if they are just giant user stories, and in doing so, apply the same techniques for splitting user stories to slicing features. We have also learned that applying ‘user story voice’ to features is also not a good practice. So, what’s good for user stories, is not always good for features.

In SAFe, a clear distinction is made between the purpose, structure and content of features, and that of stories (including enablers), for example:

• Features are visible ‘units’ of business intent that the customer recognizes, and it’s at this level of detail that the customer is able to prioritize their needs.
• Features may span multiple user roles, stories and use cases.
• Multiple teams may work on the same feature, swarming together to deliver them quickly.
• Although features may take multiple iterations to develop, they should be easily completed within a PI. Remember features are to the PI, as stories are to an iteration.
• Stories are used to incrementally implement new features and deliver new functionality. Stories help the team (and their stakeholders) examine, discuss, agree and sequence the work they believe is needed to deliver a feature.
• Stories should be sized to fit within a single two-week iteration.
• Stories can exist without parent features, allowing teams to make local decisions.

There are a number of ways to split stories, two of our favorites being those published by Richard Lawrence (including his popular story splitting poster) and Dean Leffingwell (see the story article on this website). These techniques significantly help teams in the identification, splitting, and sequencing of the stories needed to implement a feature, however, they are not as helpful when it comes to slicing features.

For example, we would never recommend deferring the performance requirements related to a feature into a later feature—although we may only implement these ‘performance stories’ towards the end of development of that feature. The same logic applies to handling error flows, CRUD [1] and data variations. We may delay stories which implement these important feature attributes toward the end of its development, but we should not defer this work into a separate feature.

When slicing features, it is always important to remember that its implementation should always provide a robust, usable solution to the end-users. Features will be built story by story, but a complete usable solution means ‘no bits missing,’ rather than that all possible stories have been implemented.

Splitting Stories vs. Slicing Features

There is another important difference between splitting stories and slicing features. When we split a story, it usually results in a set of similarly sized new stories that completely replace the original story. when slicing features, we usually just find the most important slices and leave the rest to be addressed later.

Good Feature Slicing

So, let us imagine that a team has just sized a feature (typically in story points) and has discovered that it’s too big to easily fit within a PI. To slice this feature, they will need to use a slicing method that lets them de-prioritize or defer some of the less critical functionality. Once the feature has been sliced, teams will implement the parts that deliver the majority of customer value early.

What slicing strategies can you use? We have identified the following ten useful patterns for slicing:

1. KISS Design Principle. Keep it simple, stupid. Aim for the simplest possible implementation of the feature that could be released without compromising nonfunctional requirements, such as systems performance, etc. This is often the happy path, with some basic error handling. Defer adding the ‘bells and whistles’ to later features, once the basics are in place and are a providing a high quality, fit-for-purpose solution.
2. Defer Optional Behavior – Does the feature include lots of optional behaviors? Consider making the optional behaviors separate features to be implemented once the core functionality is delivered and more learning has occurred. You may find that these optional behaviors are not needed.
3. Separate Business Variations. Can the feature be released incrementally to different areas of the business? Start with the simplest business variant first to generate fast feedback. For example, could we do a simple solution for retail banking before enhancing it for investment banking, trading, and other banking areas? Also, consider geographical variations—in many industries the business rules vary by geography with different rules for the US, Europe and Asia. Perhaps the feature can be launched in one geography, before adding support for the others via additional features.
4. Separate Different Channels. Could the feature be released incrementally to support different channels, routes to market, or technologies? For example, different operating systems, or the different channels for retail banking, web, mobile app, and in-branch banking. It is logically the same feature, however, the implementation for each channel could be sliced into a different feature (and in some cases, may not be needed at all).
5. Address Different User Groups Individually – Do different groups of users want different types of functionality? For example, the feature may appeal to different demographics, however, each group may want to use the feature in a different way. In this case, slicing the feature on just a subset of functionality for each demographic may appeal to the interest of the more important groups earlier.
6. Consider Incrementally Sourcing Data. Is all the data needed before any benefit can be provided? Perhaps the data can be consumed incrementally or sourced from existing secondary sources?
7. Isolate Special Variations. First focus on the popular / high volume cases then add the more specialized corner cases as additional features. You may discover that the value of the additional corner cases is low and should not be implemented.
8. Break Out Common Enablers. Business features often rely on the same underlying system behaviors, making the implementation of the first set of features appear large and complex. Slicing them into business features and enablers can reduce the risk and size of the features.
9. Find a Story Group. Remember the Pareto rule applies to features. 80% of the business benefit is likely to come from 20% of the stories. Find these stories and treat them as their own feature. See Story Mapping for more information.
10. Break Out a Spike. Sometimes you don’t know enough to plan a feature, or to slice it into smaller pieces. In these cases, use an exploration enabler (e.g. a spike) to research what is needed.

Bad Feature Slicing

It is also important to understand the anti-patterns for slicing features and avoid practices that put your solution at risk. For example, be aware of the following anti-patterns when slicing or developing new features:

• Deferring Nonfunctional Requirements. Avoid releasing features that have the core business functionality, but have unacceptable quality and performance levels. We have seen many teams get into trouble by compromising on quality in their dash to get more and more features into the product. Build-in quality, rather than relying on inspection to add quality later.
• Creating Feature Debt. There are circumstances, of course, where a limited release of a feature to a subset of users limit the number of applicable non-functional requirements. Great care must be taken to ensure that the feature is not subsequently released to everyone, without adding the missing functionality for the larger group.
• Slicing Too Early. Only slice a feature if it’s needed in the near future and it’s too big to flow through the system quickly now. Remember, estimates change over time—what appears to be too big today, may have a much smaller estimate in the future as learning occurs.
• Over-slicing. Avoid slicing a feature into lots of smaller features all in one go. Generally, it’s better to find the first one or two key slices to be implemented, and defer the rest of the functionality until feedback has been received on the initial slices.
• Slicing by operation or workflow step. It’s often tempting to slice a feature into a series of smaller ones to satisfy a series of workflow steps or operations. However, there is little or no business value in just being able to complete a single step. Instead, focus on identifying the core behavior and creating the simplest end-to-end solution. Otherwise, you may find that 90% of the features are complete, but users still can’t achieve their business goal, nor complete the process they are trying to perform.
• Slicing by Component. We’ve found that technologists like to slice features by architectural component, sub-system or architectural layer. This is a bad habit and has similar problems to slicing features by operation or workflow step.
• Forgetting Feature-level Testing. Features often require additional testing beyond what’s needed to complete their Stories. Remember to test each feature slice, as well as the larger solution intent of the original feature. It’s easy for feature acceptance criteria to be lost after slicing a feature into smaller pieces.

About the Author

Ian Spence was one of the first European SAFe Program Consultant Trainers (SPCT). This is a reflection of not just his knowledge of SAFe but also his long experience working with Dean Leffingwell over the last 15 years, and his vast experience of successfully leading large-scale agile transformations.

Ian regularly delivers both the Implementing SAFe with SPC certification and SAFe Practitioner training, and often co-teaches SPC training with Dean when he is in London. He is also the co-author of two influential software development books, “Use Case Modeling” and “Managing Iterative Software Development Projects.”

Learn More