Slicing Features - Patterns for Slicing

In a recent Webinar on Writing Better Features I briefly mentioned slicing Features to create smaller Features, but didn’t have the time to do a deep dive on the topic of slicing Features. Whilst we at Ivar Jacobson Intl. have blogged about Preparing Features For PI Planning, which again mentions Feature Slicing it doesn’t go deep. As for the Framework, it leaves the preparation of Features open to interpretation without ever really explaining what makes a good feature and why.

So, this pair of blogs is a deep dive on Slicing Features. This blog will look at the Feature Slicing Patterns, the next blog will look at Slicing Patterns In Practice.

Qualities Of A Good Feature

Before jumping to how to slice Features, a quick recap on the qualities of a Good Feature. This is important as the results of slicing a Feature are new, smaller, more manageable Features.

What makes a good Feature was discussed in the Webinar of Writing Better Features, to summarize here:

Figure 1: Qualities Of Good Features

• A releasable piece of value
• Fulfils a customer need
• Fits with the product strategy
• Developed collaboratively to include all perspectives
• Posed as a challenge rather than a solution

Although they might follow broadly similar patterns slicing a Feature is different from creating a set of Stories to realise a Feature because the results of slicing a Feature are more Features. Therefore, the resulting slices need to conform to the qualities of a good Feature shown above, not the qualities of Stories. This means that there are a couple of warnings…

• Don’t defer non-functional requirements
• Don’t slice too early
• Don’t over-slice
• Don’t slice by component
• Don’t forget the Feature testing

The warnings were also covered in the Webinar on Writing Better Features.

Dream Big, Start Small

People dream big; most Features start as big the dreams of customers and stakeholders. Capture them, stick them on the backlog, don’t loose them. These big Features are placeholders for future work, a reminder that there is potential work out there, but they are too big to drive the day-to-day work. Any large block of work will contain a mix of valuable things and not-so-valuable things. The big dream needs to be broken down into more manageable pieces that can be worked with day-to-day.

And yet, what we don’t want to do is break the big dream into lots of little bits, that will pollute the backlog. Whilst it will allow us to sort out the valuable parts from the not-so-valuable parts, it will take a lot of effort to process and prioritise. For the not-so-valuable things that get deprioritised, and possibly never done, the effort to split them out and elaborate them becomes wasted effort.

One option is to treat the big dream like a stick of salami. Slice a few valuable pieces off of the end, prepare them and get them onto the pizza into the backlog ready for the next planning interval. The remains of the big dream go back onto the backlog as a place holder as a reminder that there is still more to do to build the big dream in future PIs. One additional advantage of this approach is that it supports SAFe Principle #3 : Assume Variability, Preserve Options; because the Features are sliced off as they are needed for the next Planning Interval, feedback from delivering and releasing earlier Features can inform what slices to shave off next. Some of the early slices might not be building functionality but building knowledge to support future functionality.

Feature Slicing Patterns

Over the years a number of patterns have been developed for splitting Features. We’ve collected them together into a set of cards. At Ivar Jacobson Intl. we like the cards because, when physically printed, the cards allow individuals and teams to interact with the cards which stimulates thought and engagement.

Games can be played to help choose the most appropriate pattern from the available set. When faced with a choice of patterns the patterns are dealt out amongst the members of the team. For each pattern, the pattern description is read out and the team discusses its applicability in this situation. As a visual aid the patterns can be laid out in order of least to most applicable. The team can then select a pattern, typically, but not always, this is the most applicable pattern.
	Find A Story Group – 80/20 rule Does 80% of the value come from 20% of the Stories? Could you find the set of most value Stories and develop and release them as their own Feature? Most functionality has a nugget of value at the centre, the reason for the functionality existing, and then around the edges lies stuff that complements the nugget of value but isn’t intrinsic to the nugget of value. If stories have already been created can you find a set of stories that represent the nugget of value at the centre, enough to create a first releasable piece of value? This pattern is particularly handy when reverse engineering an existing Work Breakdown Structure inherited from an old-school project into Features.
KISS (Keep It Simple) Does the Feature have a simple core that provides most of the benefit and/or learning? This is often the happy path with some basic error handling. Could you slice the feature to do that simple core first and build on it later with further Features? Agile Principle #7: Working Software Is The Primary Measure Of Progress and SAFe Principle #5: Base Milestones On Objective Evaluation Of Working Software, are both trying to get encourage us to get to a working system that can be demonstrated as rapidly as possible. What’s the simplest that can be build in order to demonstrate the end-to-end for this piece of functionality, the thinnest thread through the system? Can that be sliced off and built first? The simple Feature doesn’t have to be released be released externally to the end-users in it’s own right, but internally the release is a significant risk reduction because the demonstration shows that the functionality works and it provides a “walking skeleton” that enables more teams to start incrementally building on that functionality and adding depth and richness to the overall functionality. Example: Flexible search across a website. The simplest that can be done is “exact character matching” against the text of the website that returns a “raw list of links”. This can be layered up with future features that use a search algorithm that handles misspellings and/or predicts search terms as the user types. The formatting of the results can be improved with future features.
	Defer Optional Behaviors Does the Feature include lots of optional behavior (for example different ways to achieve the same goal)? Could you make the optional behaviors separate Features to be done once the core functionality/most popular option is in place? Lots of optional behaviors are candidates for becoming their own Feature. This arises any time that there is a choice, do you do A, B or C, etc… Look for the most valuable, often most used, behaviors to slice off first. The remaining choices can either be stubbed, or simply not presented until they’re developed. Large pieces of functionality often contains edge cases, error handling, different routes through the functionality that are adjacnet to the normal path. These are candidates for handling separately in their own features. In practice the slice being create should be the default, the normal behavior, scoped to exclude all of the optional behaviors. Do note the optional behaviors that are being defered on the placeholder Feature that’s going back onto the backlog so that there are prompts whens it comes to break them out into their own Features. If the normal behavior is already in place, then slice off different optional behaviors, prioritised those that are most valuable or most used. Example: Users can pay directly or be invoiced and pay by bank transfer. The two behaviors are sufficiently different that they could be developed separately as their own Features.
Separate Business Variations Does the Feature lend itself to being realised incrementally to different areas of the business? Could you deliver it one business at a time? Could you start with the simplest business variant to generate quick wins and fast feedback? Many organisations release common functionality across the business, but different areas of the business require slight customisations or adjustments. Rather than doing these as a giant block, could each part of the business be dealt with separately? Approaching the challenge incrementally allows some value to be realised early, therefore target the areas of the business that are most valuable, where the need to have the functionality is most pressing. If the First feature, which will have to bear the burden of developing the common functionality is still too big then use the Break Out Common Enablers pattern to separate out the common functionality. A bank is rolling out a new accounting package across all of it’s departments. The accountancy package needs to interface with each departments local systems and each deparment’s systems are unique. There could be Features for each department building the interfaces to the local systems.
	Separate Different Channels Does the Feature need to be delivered over different channels, different mediums, or different routes to the customer? Could you deliver it one technology / one channel at a time? Could you start with the channel of most value to the business and add the other channels over time? If there is functionality common to all of the channels and the implementation is not unique to each channel then consider using the Break Out Common Enablers pattern to separate out the common functionality. Example: A bank requires functionality to be present on it’s website and both Apple and Android installed phone apps. Each could be their own Feature to make the functionality present. Is there functionality common to all of them, if can it become a Feature that uses the Break Out Common Enablers pattern.
Address Different User Groups Individually Does the Feature involve different user groups with different goals? Does the Feature involve different user groups that want different sets of stories? Could you give each User Group their own Feature? This can help you to better understand the benefits to each group. See also Break Out Common Enablers. Common Functionality is often used by many different user groups but each user group has either a different way of getting to the common functionality or does something different after the common functionality. Those differences can be sliced off by user group and dealt with separately. If the First feature, which will have to bear the burden of developing the common functionality is still too big then use the Break Out Common Enablers pattern to separate out the common functionality. Example: Customers want to search a database of products so that they can purchase the products, Shop-Staff want to search a database of products so that they can the manage stock levels of the products. Features could be created for each of the two groups describing what they need to do. The Features have common functionality, Search a Database, which could be dealt with separately using the Break Out Common Enablers pattern.
	Consider Incrementally Sourcing Data Does the Feature involve lots of data from many sources? Could you deliver benefit with a sub-set of the data? Could the data be consumed incrementally or sourced from existing secondary sources? If the data comes from many sources and there is still some value in having a subset of data then break sources off into separate Features. Look for sources that provide the most value or the most risk-reduction. Data may come from human sources as well as systems/solutions. A User Interface that contains many input fields could be broken down into separate Features and built up incrementally, with the fields that haven’t been developed reverting to defaults, or left blank, until it’s their turn to be developed. Example: A factory monitoring system is pulling in data from the production machinery around the factory and providing real-time visualisation. There could be features for each machine that make the connection, get the data and visualise it.
Isolate Special Variations Does the Feature include special variations? Could you focus on the most popular / highest volume cases first and treat the more specialized corner cases as separate Features? You may find that their value / cost ratio is very small and they are never needed. In many systems if certain conditions are met then the system needs to behave is a slightly different fashion from the normal path through the system. The goal is to separate the normal path from the special variations so that the normal path can be developed quickly to prove that the system works. Slice the normal path off and scope it so that it doesn’t include the special variations, leave notes in the placeholder Feature to remind you of what the special variations are so that once the normal path has been delivered they can be sliced off of the placeholder Feature. Example: Banks need to run checks on new customers to ensure that the customers are not involved in money laundering or other fraudulent activities. Most customers are from the country that the bank is based in, but occasionally there are customers from other countries and they require additional checks that can be harder to perform because the information is not as accessible. Separate out the special variations for foreign nationals compared to local customers.
	Break Out Common Enablers Do many Features rely on the same underlying system behaviors (often making the first of them selected to be very large and complex)? Could you break out the common enablers into their own ‘architectural’ Enabler Feature? Delivering the enablers can significantly de-risk, simplify and reduce the estimates for the other, related Features. Be careful when breaking out common enablers, the enablers must go into an earlier Planning Interval and be delivered within that Planning Interval. Breaking Out A Common Enabler violates the Independent criteria of INVEST, it sets up a dependency between the originating Features and the Enabler. Do capture the relationship between the Enabler and the originating Features, this doesn’t require fancy tooling, some notes scrawled on the bottom of the Feature is enough to remind everyone of the relationship. There’s no point breaking out an enabler if both the enabler and the originating Features are going to end up within the same Planning Interval, the common functionality might as well just be contained within the originating Features. Whichever Feature goes first bears the burden of developing the common functionality, but once it’s been done the rest can utilise that functionality. Do add notes to originating Features that identify which Features share the common functionality, any team grabbing that Feature to work on can then check to see if any of the other Features have been done and therefore the common functionality has been create so they don’t have to do it, if they have to create the common functionality then they can inform the teams working on the other Features that it has been done. Example: There is a Feature to allow Customers want to search a database of products so that they can purchase the products, another Feature allows Shop-Staff want to search a database of products so that they can the manage stock levels of the products. Both Features have common functionality, Search a Database, which could be dealt with separately.
Notes On Features Notes on Features are a good way of communicating intent and advice to the teams, without breaking the autonomy and self-organisation that we desire. The notes provide extra information to support the team’s planning and conversations. e.g. “This Feature shares common code with Feature Y” will prompt the team to investigate Feature Y. The notes arise because as the Features are being elaborated the PM/PO and System Architect group have spotted, at a very high level, that there is overlap between Features or that one Feature supports another Feature. The notes are prompts, they do not dictate to the teams what they should do, they empower them to think for themselves.
Break Out A Spike Are you still baffled about how to slice the Feature? Can you define the 1 to 3 questions most holding you back? Write a Spike / Knowledge Gathering Enabler Feature with those questions in mind. Do the minimum to answer the questions then return to slice the Feature. If you have no idea which pattern to pick then create a feature to allow time to gather knowledge and inform how to break the feature down. These investigative activities tend to be tightly timeboxed: “you have X days to gain the knowledge”, to stop them extending into the future forever. The output of the investigations would be candidate features ready for future elaboration that have been sliced off of the placeholder feature.

Download the feature cards below

Challenges

Slicing Features is not without it’s challenges. The technique might not be familiar to all, and progressive elaboration, deferring the detail until later, can be scary if those involved don’t trust that the organisation is sensible enough to make good decisions now that won’t destroy the ability to deliver the deferred functionality later.

Most engineers are actually quite good at taking a large problem and breaking it down into more manageable pieces, what they’re less good at is explaining how they’re doing the breakdown and getting it into writing so that others can understand what needs to be done. Do not underestimate the coaching required to extract that insight and capture it. Be aware of the psychology of the situation, the work is being captured not to hold the to it absolutely and punish them if it were wrong, but to make the steps visible to track progress, to ensure that the route they’re choosing aligns with the destination. If the route, the steps, change part way through then as long as they’re still heading towards the destination does it matter.

Some people will be worried that they won’t get everything they were hoping for if it’s built incrementally. The way to handle the situation is not to revert back to trying to define everything up front, but to set a clear goal and actively participate in the elaboration of the detail, steering the elaboration of the features, seeing the increments as they are developed and using that feedback to drive what happens next.

There will be concerns that without a full Work Breakdown structure it won’t be possible to determine how long it will take. Estimating problem solving (which is what Feature development is) is notoriously difficult, there are just too many uncertainties with problems to get precise estimates. It is better to chase value, get that thinnest thread working to start managing the risk and then iterate towards the Minimum Marketable Release, and be ruthless about what is essential for the Minimum Marketable Release. Once the release is out it should be generating value, ideally true business value, at worst the value is knowledge and insight to steer future development. Releasing further increments builds upon the initial value.

Conclusions

The patterns are not exhaustive, there may be other ways for creating a set of smaller Features from a large Feature.

Many of the patterns are overlapping, if you interpret a pattern one way it starts to look like another pattern. This isn’t a bad thing, the patterns are there to provide potential perspectives for looking at the challenge of slicing Features and the perspectives are there to trigger discussions.

Ultimately the goal is not slicing for slicing’s sake, but to break the work down into manageable chunks that conform to the criteria for a good Feature, in that they represent a A releasable piece of value that fulfils a customer need, even if it is just a small part of a big dream.

---

In the next blog we’ll look at a real world example of how the patterns were used to take a massive endeavour and break it down into successively smaller pieces to enable an organisation to get to value quicker that they had previously.

Acknowledgements

Whilst I’ve written this up, the feature slicing patterns themselves were drawn up by Ian Spence as part of his blog series on Preparing For PI Planning. Ian was influenced by his earlier work on Use-Cases, and by the work of Richard Lawrence about splitting User Stories.