Updated January 13, 2020 with more patterns.

There are a few KEY practices that a team can learn to do that can make amazing differences in their ability to get work done at a high degree of quality. Refining Product Backlog Items (PBIs) is about making backlog items READY for Sprint Planning and SLICING backlog items is a KEY practice.

Backlog Slicing Benefits

By slicing a backlog item, what we’re really talking about is taking a really complex problem and paring it down into smaller problems. The one really cool thing about solving problems is that the smaller you can make the scope of the problem, the easier the problem becomes to solve. When we make problems easier to solve, we also make them easier to build. Scrum recommends slicing a backlog item down at least until it fits into a Sprint. With many types of work, that probably works ok. In software development, however, I recommend slicing backlog items until they can be each completed in no more than three days effort. Different teams will deal with this limit differently (and that’s OK).

With increased ease in building we get a lot of benefits, including:

• Improved quality
• Improved understanding of the problem
• Better solutions
• Shorter development cycles

Frankly, it’s hard to see a down side to slicing.

But there is a dark side. Slicing is NOT taught in universities, colleges, and a lot of businesses. Developers are simply required to know how to do it (or worse, not do it at all). So, in this blog post, I wanted to provide a number of simple patterns for slicing backlog items into smaller backlog items in preparation for Sprint Planning.

Backlog Slicing Patterns

Data Slicing

In data slicing, we build functionality that works with a lot of data, but we build it only a few elements at a time.

So, the original PBI:

“As a customer, I want to create a new account so that I can order products from your website.”

…slices into:

• I want to provide my name and email address;
• I want to provide preferences and interests;
• I want to provide billing information.

Functional Slicing

In functional slicing, we build functionality that has lots of different options, but we build it one option at a time.

So, the original PBI:

“As a registrar, I need to be able to look for students in a variety of different ways.”

…slices into:

• I want to search by student last name;
• I want to search by student’s last name with a wild card capability;
• I want to search by student’s zip code.

Here’s another example…

“As customer I can search for products so I can view and order them.”

There are many ways to search for a product. All these potential parameters can be considered and broken up into smaller PBI’s:

• As customer I can search for a product by its product number, so I can quickly find a product that I already know;
• As customer I can search for products in a price range, so that the search results are more relevant;
• As customer I can search for products by their color, so that the search results are more relevant;
• As customer I can search for products in a product group, so that the search results are more relevant.

Display Slicing

In display slicing (sometimes called “WORKS-PRETTY-FAST”), we build functionality that has lots of things to display on the screen, but we build it in stages. WORKS means we can see raw output, PRETTY means it’s formatted, FAST means it’s been optimized.

So, the original PBI:

“As an avid runner, I’d like to see my vital metrics displayed simply on a dashboard using charts, graphs.”

…slices into:

• I want to see the important numbers (WORKS);
• I want to see the numbers in graphs (PRETTY);
• I want the display to update every ten seconds and in less than one second per update (FAST).

Transactional Slicing

In transactional slicing, we know we have to provide support for a particular type of person or thing (like a student or a classroom) and we build that support transactionally (create, update, display, list, remove).

So, the original PBI:

“As a registrar, I need to be able to manage students in the university.”

…slices into:

• I want to create a student;
• I want to update a student;
• I want to display a student record;
• I want to list a bunch of students;
• I want to delete a student from the system.

Workflow Slicing

In workflow slicing, we simply slice the PBI based on the steps that the user might follow to complete the activity. For example, if a user wanted to purchase a product from your site, they might follow these steps:

“As a customer, I want to purchase a camera.”

…which slices into:

• I want to create an account;
• I want to logon using my account;
• I want to search for cameras;
• I want to refine my search;
• I want to select a camera to purchase.

Business Rule Slicing

In business-rule slicing, we recognize that we handle certain activities in different ways depending on specific rules.

So, the original PBI:

“As a customer, I want to open a checking account.”

…slices into:

• As a minor, I want to open a checking account;
• As someone 18 or older, I want to open a checking account.

In another example, consider booking a flight. The original PBI might say:

“As a business traveler, I want to book a flight so that I can get to my customers.”

…and the variety of ways I might book that flight opens up the door to a lot of surprises:

• I want to book a multi-city trip;
• I want to use my frequent flyer miles;
• I want to book a trip that minimizes stops;
• I want to book a trip that avoids stopping in certain airports;
• I want to book a flight using a credit from another cancelled flight;
• I want to book a flight using a voucher.

Here’s another example…

“As a customer I can purchase the goods in my shopping basket, so that I can receive my products at home.”

This PBI can slice into:

• As shop owner I can decline orders below 10 dollars, because they aren’t profitable;
• As shop owner I can decline customers from outside the US, because the shipping expenses make these orders unprofitable;
• As shop owner I can reserve ordered products from stock for 48 hours, so other customers see a realistic stock;
• As shop owner I can automatically cancel orders for which I have not received payment within 48 hours, so I can sell them again to other customers.

As you can see, things can get complicated quick. However, the good news is that slicing the original PBI allows us to more easily see all of the complexity AND it allows the Product Owner to decide which options he or she wants first, which can wait, and which don’t need to be built.

Happy Path Slicing

“As customer I can log in with my account, so that I can access secured pages.”

If we consider a regular login procedure, we can identify a happy flow and several potential unhappy flows:

• As user I can log in with my account, so that I can access secure pages (happy);
• As user I am able to reset my password when my login fails, so I can try to log in again (unhappy);
• As user I am given the option to register a new account if my login is not known, so I can gain access to secure pages (unhappy);
• As site owner I can block users that log in incorrectly three times in a row, so I can protect the site against hackers (unhappy).

Front Load Slicing

Frequently, you’ll work on PBIs where most of the work is done in the first slice and the remaining slices are relatively simple. Credit cards are a common example of this problem.

The original PBI:

“As a customer, I want to pay using VISA, MasterCard, American Express, or Discover.”

…slices into:

• As a customer, I want to pay with one of VISA, MasterCard, American Express, or Discover;
• As a customer, I want to pay with the remaining cards (VISA, MasterCard, AmEx, or Discover excluding the one already complete).

The downside of this type of slicing is that the Product Owner has to be careful to keep the first PBI higher in the Product Backlog than the second (but it’s also usually an easy problem to identify, so…)

Interface Slicing

What if you have functionality that can be accessed from multiple modalities? For example, I can use your product from my MacBook, my Windows PC, my desktop, my phone, my notepad, and from a variety of other programs that can communicate with your product.

The PBI might read:

“As a customer, I want to be able to see a list of all activity on my account.”

…and be sliced into:

• As a customer, I want to be able to see a list of all activity on my account when using my Android Phone;
  • when using Firefox;
  • when using Quickbooks Online;
  • when using Zapier;
  • and so on…

We’ll continue to add patterns when appropriate, so check back from time to time! If you have some ideas you want to add, feel free to leave a comment below.