How to Slice a Feature into Product Backlog Items

Breaking a large feature into smaller Product Backlog Items (PBIs) is one of the central activities of backlog refinement.

The goal is not simply to divide the implementation into smaller technical pieces. A good PBI should describe a meaningful piece of user-facing value, while technical implementation details are usually captured as Tasks underneath those PBIs.

Consider the following Feature:

Enable users to reset their password via email.

This provides a useful example for exploring how a Feature can be decomposed into PBIs and how those PBIs differ from technical Tasks.

Start with the End-to-End User Value

Before slicing the Feature, first identify the complete user outcome.

For password reset, the end-to-end flow looks roughly like this:

User requests password reset
        ↓
System sends reset email
        ↓
User follows reset link
        ↓
User chooses a new password
        ↓
Password is changed
        ↓
User can log in again

The complete Feature represents the larger capability. It describes the outcome we ultimately want to provide, but it is still too broad to be treated as a single PBI.

The next step is to identify smaller user-facing slices.

From Feature to PBI

PBI 1: Request a Password Reset

The first interaction starts when the user realizes that they can no longer access their account.

A possible User Story is:

As a user, I want to request a password reset so that I can regain access to my account.

This clearly describes user-facing behavior.

The implementation might include a password-reset action on the login page and a form for entering an email address.

However, this PBI alone does not provide the complete password-reset capability. Without an email or another mechanism for continuing the process, the user cannot actually reset the password.

So this slice has:

• User-facing value: Yes, partially
• Independently deployable as a complete solution: No

It nevertheless establishes a meaningful part of the user interaction.

PBI 2: Receive the Reset Email

The next step is providing the user with the information necessary to continue.

A corresponding User Story could be:

As a user, I want to receive a password reset email after requesting it so that I can follow a link to reset my password.

This adds another observable piece of user-facing functionality.

The system now responds to the request and provides the user with a reset link.

Again, however, the complete user goal cannot yet be achieved if that link does not lead to a functional password-reset page.

Therefore:

• User-facing value: Yes, partially
• Independently deployable as a complete solution: No

PBI 3: Access the Password Reset Page

The next slice allows the user to follow the link and reach a secure password-reset page.

The User Story could be:

As a user, I want to access a secure password reset page using the link so that I can choose a new password.

At this point, the flow is becoming substantially more complete.

Depending on the implementation strategy, this increment might even be deployable when parts of the underlying password-changing functionality are initially stubbed or mocked.

Therefore:

• User-facing value: Yes, partially
• Deployable: Maybe

The distinction is important: a PBI can describe meaningful user behavior even though additional PBIs are necessary before the complete Feature provides its intended end-to-end value.

PBI 4: Change the Password

The final major slice performs the actual password change.

For example:

As a user, I want my password to be updated securely so that I can log in again using the new one.

Once this functionality is connected to the previous slices, the entire flow becomes operational:

Request
   ↓
Email
   ↓
Reset page
   ↓
Change password
   ↓
Login with new password

This PBI completes the end-to-end capability.

It has:

• User-facing value: Yes
• Deployable: Yes, once the required UI, backend, email, and security functionality are connected

PBIs vs. Technical Tasks

Not everything necessary to implement the Feature should become a PBI.

The password-reset capability also requires technical work such as:

Implement token generation and expiration logic
Create the email template
Integrate with SMTP
Implement audit logging

These activities are essential, but they do not independently describe something the user wants to accomplish.

They are therefore better represented as Tasks underneath the relevant PBIs.

For example:

PBI: User receives a password reset email

├── Task: Implement reset token generation
├── Task: Implement token expiration
├── Task: Create password reset email template
├── Task: Integrate email delivery
└── Task: Add audit logging

This preserves an important distinction:

PBIs describe user-facing behavior; Tasks describe engineering activities required to provide that behavior.

Avoid Horizontal Technical Slicing

A tempting alternative is to divide the Feature according to the architecture:

PBI: Implement password reset database changes
PBI: Implement reset token service
PBI: Implement email service
PBI: Implement password reset REST API
PBI: Implement password reset UI

This produces relatively clean technical work packages, but they are horizontal slices.

Each item addresses one technical layer:

UI
─────────────
API
─────────────
Business Logic
─────────────
Persistence

None of them independently describes what the user can accomplish.

A vertical PBI should instead cut through the necessary technical layers:

        PBI 1       PBI 2       PBI 3
          │           │           │
UI        │           │           │
──────────│───────────│───────────│────
API       │           │           │
──────────│───────────│───────────│────
Logic     │           │           │
──────────│───────────│───────────│────
Storage   │           │           │
          │           │           │

Each slice should be organized around behavior rather than architecture.

Technical Work Can Still Be Deployable

There is an important nuance here.

A technical component can be independently deployable without being a good PBI.

For example:

Backend service generates and validates password-reset tokens.

The service might be completely implemented, tested, and deployed.

Likewise:

Email service sends password-reset instructions.

That functionality could technically be deployed independently.

But neither provides much standalone value to the user.

This illustrates why deployability and user value are different properties.

Technical deployability alone does not automatically make something a good Product Backlog Item.

The Feature Provides the Complete Capability

The resulting backlog might therefore look like this:

Feature: Enable users to reset their password via email
│
├── PBI: User can request a password reset
│   └── Tasks...
│
├── PBI: User receives a password reset email
│   └── Tasks...
│
├── PBI: User can access a secure reset page
│   └── Tasks...
│
└── PBI: User can change the password
    └── Tasks...

The Feature describes the complete capability.

The PBIs describe smaller user-facing portions of that capability.

The Tasks describe the technical work required to implement those portions.

A Practical Test for PBI Slicing

When deciding whether something should be a PBI or a Task, a useful question is:

Can I explain the value of this item from the user’s perspective without talking about our implementation architecture?

Compare:

As a user, I can request a password reset.

with:

Implement the password-reset token service.

The first describes observable product behavior. The second describes an implementation mechanism.

That does not make the technical work less important. It simply means it belongs at a different level of the backlog.

Conclusion

Slicing a Feature into PBIs should primarily follow user-facing behavior, not technical components.

For the password-reset example, a sensible decomposition is:

Feature
└── Enable password reset via email
    │
    ├── PBI: Request password reset
    ├── PBI: Receive reset email
    ├── PBI: Access reset page
    └── PBI: Change password

Technical activities such as token generation, SMTP integration, and audit logging support these PBIs and should normally be represented as Tasks rather than independent PBIs.

The key distinction is:

A Feature describes the complete capability, PBIs slice it into user-facing behavior, and Tasks describe how that behavior is technically implemented.

Not every PBI needs to provide the entire end-to-end capability by itself. But slicing around observable user behavior keeps the backlog focused on product value instead of turning it into a list of architectural components.