Feature Slicing

Overview

Feature slicing is a technique for breaking features, stories or backlog items into small deliverables which form "vertical slices" that cut through architectural layers. The aim is for these slices to be thin, valuable, testable and demonstrable, with the focus on delivering value early and then validating, learning and iterating.

Who is it for?

Feature slicing is an approach that all members of the delivery or development team can use and participate in. This includes both technical and non-technical team members. The technique is usually applied during elaboration or refinement events and can lead to engaging conversations around lean thinking, understanding business value, quality and technical practices within the team.

Why should you use it?

Delivery teams can often face challenges due to large or horizontally split features.

Large features, lasting several days to weeks, make it slow to deliver value and cause risk to build up. When the delivery of a feature is split into backlog items which represent horizontal slices, often by architectural layer, several backlog items must be delivered to realise any value. With horizontal slicing, the focus is often on the work required as opposed to the value to be delivered. This can lead to delayed validation of the "end-to-end" feature (though all architectural layers) resulting in reduced responsiveness and increased risk. Each horizontal slice can also be harder, or less valuable, to test independently, causing longer feedback loops. These factors can also lead to a reduced sense of delivery performance, potentially impacting team morale and can contribute to a lack, or erosion, of trust with stakeholders.

For example, slicing a web application feature into front-end (UI), back-end (API or web services) and datastore horizontal slices could incur the following challenges. To implement each slice, assumptions will need to be made at the boundaries of each architectural layer or integration point that can only be validated end-to-end when all slices have been delivered. Significant investment can be made in implementing each layer individually. A fully featured API layer could be implemented with assumptions regarding schema, data items and methods. However, when implementing the UI slice it may be found that certain functionality is unfeasible or unintuitive and requires considerable adaption impacting the API and even other layers, or at worst is no longer required. Delivery in horizontal slices inherently delays learning and causes risk to build up which can mean that substantial rework is required. This not only results in waste but also further delay to the delivery of value.

Horizontal slicing can also reduce collaboration and encourages the anti-pattern of over-specialisation, creating skill and knowledge silos within or across teams. For example, you may end up with front-end developers, back-end developers, platform engineers, and DBAs who only work on the specific horizontal slice aligned to their specialism. This contrasts with the preferable and more adaptable T-shaped full-stack team make up.

What is vertical slicing?

A vertical slice cuts through multiple architectural layers.

The aim is for slices to be as thin as possible and to span as many layers through the stack as possible.

How does it help?

Thin vertical slices that are valuable, testable and demonstrable can bring several benefits. They facilitate delivering value early, enabling faster feedback loops, validation, and learning, resulting in a better product, sooner.

Risk is reduced. Initial vertical slices through all architectural layers de-risk and prove out technical approaches and integration points. While the resulting early and fast feedback loops de-risk and inform product development through prompt validation and learning.

The key principle of slicing is delivering value early, using a lean and simple approach. This focus on value facilitates prioritisation of the features and slices with the greatest business benefit, and the faster feedback enables more flexible planning and responsiveness to change.

All these factors combine to help build confidence in the product and delivery and trust from both stakeholders and customers.

Delivery of thin slices and a focus on value can also have a positive impact on team morale and motivation. This includes a sense of progress and achievement through delivering value early and increased engagement thanks to a greater appreciation of why the work is important via the explicit link to business value. Focusing on thin, valuable slices can also provide opportunities for meaningful discussions around limiting work in progress (WIP) and managing cognitive load for the team. This enables focus and flow to be explicitly optimised, leading to a more effective and sustainable environment.

How do you use it?

A sharp focus on business value, simplicity, and fast feedback is required for mastering this technique, supported by an evolutionary approach to technical architecture.

It is important to understand that business value comprises both customer value and learning (or knowledge) value. Earlier slices may have a greater bias towards learning value and later slices towards end-customer value. Both ultimately provide value to the business. Value from learning can be a more challenging concept to grasp than direct customer value, and it is important to be mindful that not all learning is equally valuable. The learning value derived from a feature slice should be focused on the minimum learning needed to de-risk and better inform future slices of the product, and guide decisions, actions and prioritisation.

As a starting point, it can be helpful to ask the questions: What is the simplest thing we can do that will provide the most value? Or what is the maximum validated learning we can achieve from the minimum effort? Ideally, this is a slice that cuts through all architectural layers. The thinner the better. However, it can be useful to initially aspire to slices that can be completed in no longer than a day or so.

This could be something as simple as a "Hello World!" implementation, that provides learning through proving out elements of the tech stack, providing an extremely simple version of the feature that can be iterated upon, and building confidence early in the delivery. For example, if delivering a web application, this could be a very simple implementation that proves out and de-risks both serving up a static page, and build and deployment pipelines. Showing tangible progress early and providing a platform for iteration and fast feedback. For more complex features, the preference for an initial slice would be a walking skeleton that cuts through all layers of the tech stack, providing all the same value but additionally aims to de-risk key areas such as dependencies and integration points.

In some cases a full stack walking skeleton as an initial slice may not be appropriate, and more valuable learning can be achieved in a different way. For example, providing a new stubbed API endpoint in an integration environment could work well as a first slice, where the value is derived from being able to assess interest from early adopters, and gather feedback on ease of integration and quality of supporting API documentation. However, it would still usually be beneficial to quickly establish a walking skeleton in the immediately successive slices.

The key is always identifying the value that a slice delivers and remembering to validate early and often, feeding this back in to inform subsequent slices. It can be productive to encourage the team to explicitly identify and record the value of each slice, and consider how they will test and demo it before starting to implement it.

Subsequent slices should aim to be an iteration of the previous slice, incorporating feedback where appropriate. To follow the walking skeleton analogy further, they should look to add more "flesh on the bones" of a previous slice that is already feature "shaped". It can be helpful not to look too far ahead, too early, by defining many slices up front for a large feature. As the team and the business learn from earlier slices, the appropriate way to slice the feature or even the requirements of the feature itself may change and evolve.

The feature slicing technique can take some time and practice to develop and get right. Teams used to large features or backlog items may initially find the approach challenging and difficult to master. Training and coaching may be required to develop the required mindset and approach. The Elephant Carpaccio workshop developed by Alistair Cockburn can be a good training tool.

To leverage the full potential of the feature slicing technique teams need to have the technical capabilities to practice CI/CD. However, due to the often greater proportion of learning value versus customer value in earlier slices, it may not always be desirable to expose initial iterations to the customer. Feature flags or toggles can be an effective technique, complimenting CI/CD, to surface features safely and at an appropriate time. CI/CD and feature flags, in conjunction with thin feature slices, can be a powerful combination to enable and accelerate the key tenets of this approach: tight feedback loops, learning, and early delivery of value.

Check your slices

Here are some questions to ask about your candidate slices.

• Does it help us learn something or provide customer value?
• Does it deliver something which can be demoed to a stakeholder or customer?
• Could it be sliced further while still providing some learning or customer value? Remember, it is fine if a slice just moves us a small increment in the right direction; by itself, it does not need to deliver something a user might recognise as a complete feature.
  • Can we start with an empty placeholder screen, API endpoint or whatever?
  • Can we start with no authentication and add it in a future slice?
  • Can we start with no or only placeholder validation and add more validation in future slices?
  • Can we start by tackling a specific use case and add other use cases in future slices?
  • Can we tackle integrations with external systems or the addition of slivers of business logic iteratively, one per slice, prioritised by value and risk?

Common gotchas

Teams new to the feature slicing technique may initially struggle to articulate the value of a slice, or even struggle to determine what a valuable slice is. This should generally improve and become easier over time though coaching and as they gain more practice and experience. However, it is worth being mindful that that this can also be a symptom of a misunderstanding of value (business value is both learning and customer value), or perhaps an indication that the slice in question is not truly valuable and needs rethinking.

Occasionally business stakeholders familiar with teams delivering large or horizontally sliced features may initially view the frequent requests for demos and feedback enabled by feature slicing as inefficient. This can manifest itself in a reluctance to regularly engage or, in the extreme, a "just tell me when it's done" attitude. However, encouraging and persisting with engagement in the frequent demos and feedback can rapidly bring about a change of mindset, as stakeholders build a growing appreciation of the sense of progress, realisation of value and vision, reduced risk, and how providing early and frequent feedback can help build a better product sooner.

It is also worth being mindful of teams unintentionally reverting to old habits over time. This can happen when teams are under time pressure, when tackling a different or larger challenges, or if the team make up or dynamics change. It can be helpful to periodically run refreshers on the technique, especially if new members join the team, and ongoing coaching and guidance in elaboration sessions will likely be required, to a greater or lesser extent, for some time.