Overview

Functional slicing is about finding the simplest, quickest way to implement a customer capability from a functional design perspective.

You identify the steps a user would need to go through to complete their job, collaboratively identify options for how each step can be functionally achieved by them (not us), and then choose the simplest implementation option for each step. This creates a “vertical slice” through the user interface, business logic and database – i.e. an end-to-end customer interaction with your product.

At this stage you are not talking much about HOW you would implement the step (that is done in technical slicing), but rather WHAT the step is and how it would be presented to the user.

Jeff Patton’s user story mapping (and maps) are a brilliant technique and artefact to use for this purpose. Grab the user story template in Miro, use a dedicated story map tool like FeatureMap, or just use a simple white-boarding tool to build out your map.

Slicing patterns

• Simplest product/UI/UX design Just do the minimum aesthetically to start with to create a working capability, with no bells and whistles at all. Some of the best products never move much past that minimal design, whereas others will have their look-and-feel iterated on many times based on customer feedback and empirical performance measures.
• Simplest workflow steps Start with the fewest, simplest steps to get the customer from sitting down at their computer (or tapping their watch, or saying “hey Siri”) to their job being complete. Map this out (as shown above) and keep any steps which you are not prioritising on your radar for later exploration. For example, 2FA could be deferred until later rather than included in the simplest workflow. Even if we don’t think we will release to customers without 2FA, there is still value in deferring its implementation to focus first on the core working capability of paying a bill.
• Acceptance criteria/tests/scenarios So long as acceptance criteria are defined as user scenarios (e.g. in gherkin or a simpler story format), they can be pulled out of stories and made into narrower functional stories of their own. As with all forms of slicing, this then allows you to defer/reject scenarios which are not needed until later (or at all) but otherwise would have been built up front if you didn’t explicitly call them out.

• Zero/one/many If you are developing a page where the user should see a list of vehicles, you can slice the story into three: “When the list is empty, user sees 0 items”, “When there is one item, user sees 1 item”, and “When there is more than one item, the user sees all the items”. You could slice further here with pagination (“When there are 35 items on the list, user sees first 20 items and 2 page links”). You might notice here that slicing stories helps with testability too.
• Business rules When transferring money between accounts, there might be a $10k daily limit, and transfers can only be made by certain types of accounts or ones without overdrafts. Slice these rules into their own stories and prioritise the core functionality. That way, you first focus on getting a working capability for transferring money rather than delaying feedback by including business rules as part of the same story.
• Happy/unhappy path When navigating through a digital product to complete a job, things can go wrong along the way. The user has entered an invalid email or postal address. PayPal payment didn’t work. You need to explore all of these scenarios (and of course implement some of them). But you can start by deferring any error scenarios and build first for the assumption that everything goes well in the user journey (aka the “happy path”). Again, this gets you to a demonstrable core working capability sooner (“here is a customer completing a bill payment”), rather than ending up at the end of a sprint with only the first step of a process implemented (“here is a customer entering a biller code correctly and incorrectly”).
• Input options As per the example above, user input can take many forms, including manually inputting text, selecting from a dropdown list of known or past data used, selecting a radio button or a simple text link, entering a fuzzy search term and (nowadays) voice input. Start with the simplest and only get more sophisticated if that is where there is most need or value based on customer feedback and behaviour.
• 1st X, then the rest You want to update the 15 text input boxes across your product to accept rich text. Don’t have one story to update all of them, have a story do do the first one and then the others. This pattern can also be used where providing options for a user to do something, e.g. payment options. Have a story for each payment option and do the most valuable (or simplest) first, rather than keep the “payment” story as unsliced, with lots of scenarios including payment options within the story.
• Search parameters/filters The user can search for products in multiple ways (e.g. by name, description, price, trending, similarity to another product, etc.). Start with one way. Have stories representing the options of the ways you might want to enable the user to search, but again defer anything except the essential until there is a validated need.
• CRUD operations Slice create, read, update and delete operations into separate stories. Don’t have one story for “managing records”. Also consider prioritising as RCDU (because you can read a record without needing the user to create one, and deleting and creating a new record is a workaround for updating a record).