Are Features a Part of Scrum?

A feature is functionality in the product that delivers significant business value and satisfies customer needs
An illustratie graphic showing snowy mountain peaks with the words stories features and epics appearing in the sky

Reviewed by Punita Dave

Features are a way to organize and describe work that can be added to your practice of scrum, although they are not a part of the scrum framework. Consider features (along with epics, capabilities, and user stories) an option that can be added or removed to your scrum team's processes.

What Is a Feature and How They May Fit Into Scrum

A feature in agile product development is defined as a part of the product—whether a service, functionality, etc.—that delivers both business value and satisfies a customer need. A feature describes a larger functionality of a product that is too big to implement in one sprint. Because of its size, it may need multiple sprints or two to three months to complete.

A team breaks features down into smaller units, which they may call user stories. These smaller units of work represent part of a feature and a general explanation written from the end user or customer’s perspective.

Epics, features, and user stories provide a structure to organize a team’s work by breaking it down into smaller pieces and aligning it with a product goal. Features are one way the teams may choose to categorize their work into small pieces of functionality, achieved piece by piece and increment by increment.

What’s the Difference Between a Feature and a User Story in Scrum?

User stories are an end goal from the product user’s perspective and articulate how a software feature will provide value. The purpose of a user story is to define how a piece of work delivers value back to the customer. 

Customers don’t have to be external end users of the product. Customers may also refer to other teams or stakeholders within the organization who depend on the team and its deliverables.

A central part of agile is putting people first, and that’s what a user story does by placing the end user as the center focus. They have the perspective of a user’s need rather than technical implementation to provide the necessary context to the developers.

For example, a simple user story may look like this:

As a customer on a local grocery delivery app, I want the ability to request to remove and refund an item if it is out of stock instead of substituting for something I don’t want.

Here's an example of a user story that a Human Resources department might create:

As an employee of the bank, I want to know when internal promotion opportunities become available to advance my career with the company.

On the other hand, a feature is a functionality of the product that satisfies a customer’s need or improves the user experience. It’s too big to finish in one sprint and breaks down into smaller pieces of functionality—user stories.

Then, using the example above, the feature is:

Give the customer the ability to request automatic refunds and control their orders better if products are out of stock. Adding this feature will require less staff to manage customer refund requests and decrease customers’ wait time to get their money back.

The feature and the user story have the same end goal but different perspectives and contexts. 

Epics vs. Features

There is another level of agile product planning that some teams may use: the epic. An epic is a large body of work delivered over multiple releases.

The organization of typical project planning is epic > feature > user story. Some teams may organize the work differently. Here is a description of each:

  • Epics are the highest-level goal of product development, providing direction and context for teams to plan out the development process effectively. They're often associated with value streams.
  • Features detail how the team will build the product, one feature at a time. 
  • User stories are statements of problems to solve from the user’s perspective.

As an explanation of these different terms, consider your product to be an 80-person retirement party. This break-down of work is from the perspective of the event organizer (you):

  • Epic: Plan a retirement party with 80 guests
  • Feature 1: Guest List Management
    • User Story 1: As the event organizer, I want to create and manage the guest list to keep track of all the attendees.
    • User Story 2: I want to import contact information from external sources to expedite guest list creation.
    • User Story 3: I want to send personalized invitations and receive RSVPs from the guests.
  • Feature 2: Venue Selection and Booking
    • User story 1: I want to research and select a suitable venue that can accommodate 80 people comfortably.
    • User Story 2: I want to check the availability of the chosen venue and book it for the party date.
    • User Story 3: I want to arrange any necessary permits or licenses for the event.

From there, you would continue breaking down features and user stories until the entire party plan is covered.

No one role is responsible for writing features, epics, or user stories. Everyone involved in the work collaborates, including the product owners, stakeholders, and developers. In scrum, only the developers on the scrum team can decide the "how" of completing their product backlog items (or user stories). No one tells them how to get to the solution and outcomes.

The purpose of epics, features, and user stories is to help teams break their work down into smaller increments, organize it, and continue to work toward their broader business goal. Some teams may only use features or user stories. Many scrum teams won't use these descriptions at all but instead some form of work processes unique to their organization. These tactics are outside of the scrum framework but can be used as complementary tools if the team chooses.

How to Create a Feature in a Scrum Team

To write impactful features on your scrum team, focus on these areas:

    1. Define the WHY (benefit hypothesis): What are the benefits users gain from the feature?
    2. What is the feature?: Define the functionality, how it works, the customer needs it’s addressing, and the work to develop it.
    3. Determine business value: Consider the frequency of use, time, and effort to develop to determine the ROI of the feature and if it’s worth it.
    4. What are the acceptance criteria? Share the acceptance criteria for what it looks like when it is complete.

Improve Product Development and Work More Effectively

A feature in scrum is a customer-focused functionality that provides business value. It helps developers clarify and organize work by defining broader user-focused functionalities that make it easier for stakeholders and the team to understand what’s being developed.

Features can help provide clarity and organization for the scrum team’s work. However, they are not required to practice scrum, and teams may organize their work using other concepts and structures. The main goal is to break down large work items into smaller pieces of work that are easy to deliver in small increments, such as a two-week sprint. When teams deliver in smaller increments, they can ensure quality work and inspect and adapt as they go.

Get More Agile Resources

Are you interested in learning more about scrum? Please subscribe to our emails to receive new articles in your inbox.

RL_500_features-scrum
Stay Connected

Get the latest resources from Scrum Alliance delivered straight to your inbox

Subscribe