What Are Epics, Features, User Stories and Tasks in Agile Project Management?

In Agile Project Management, you often hear the terms Epic, Features, User Stories and Task. When you read the Scrum Guide, you will find none of these terms in it. How can that be and what is the difference between these terms? If you would like to understand the difference and broaden your perspective, then read on and learn more.

What the Scrum Guide Defines

I’ll say it right at the beginning: the Scrum Guide does not define the terms Epic Features, User Stories and Task. Also the term requirement you will not find in the Scrum Guide. Surprised? I was surprised when I first read the Scrum Guide. The Scrum Guide claims to be applicable to all kinds of projects, not only IT projects, and therefore intentionally avoids terms that only occur in specific areas or industries, such as features in software development. Scrum only uses the neutral terms “Work” and “Backlog Items”. Quite simple!

That’s the beauty of Scrum. The Scrum Guide claims also: “Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve your goals and create value.” Scrum is also simple in a scaled version as Scrum@Scale. Scaling Scrum is necessary as soon as you are working with several teams on large projects or in a larger company when it makes sense for the entire software development to work in an agile way.

Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve your goals and create value.

(The Scrum Guide)

Complementary Practices to Scrum

Let’s go back to Epic, Features, User Stories and Task. In Scrum, we usually use “Epic” and “Theme” instead of “Feature”. “Theme” is a collection of related user stories. Whenever a user story you estimated and cannot be completed in a single sprint, you should call it an “Epic” instead. That means you should split the Epic into smaller user stories. A theme can be done in two or more sprints. So, you must prioritize and choose user stories for a sprint as long as you have a potentially usable product increment at the end of the sprint.

Concepts like epic, feature, theme, user stories, tasks, etc. are not part of the Scrum framework, but “complementary practices”. This means you can use them as you see they fit. In the end, they are all Product Backlog Items (PBI’s), so only the rules from the Scrum framework concerning Product Backlog items apply to them.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes. Most of them can be decomposed into User Stories. The name you give them is not that important. It is just important that your governance defines which terms to use and everyone in your project knows what they mean. Key is that you decompose the Product Backlog items to be small enough to be delivered in one sprint, according to the Definition of Done and to the acceptance criteria defined.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

(The Scrum Guide)

Let’s go back to the feature. A feature is defined as a service or function of the product that delivers business value and fulfills the customer’s need. Each feature is broken down into several user stories, as it is usually too big to be worked on directly. A feature is normally delivery within an iteration (sprint). If a feature cannot be done in a single iteration, it should be broken down into smaller features.
To confuse you even more, I will bring you the term Capabilities. According to SAFe, Capabilities behave the same way as features. However, they are at a higher level of abstraction and support the definition and development of large solutions. They are sized and split into multiple features to facilitate their implementation in a single release (or Planning Increment).

In general understanding, and if you want to have it very simple, then Epics are seen as raw Stories that need to be broken down with more understanding of what is usable and inspectable quickly.

What I have not explained so far are the Nonfunctional Requirements (NFRs). The NFRs define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the backlog.

 From Features to User Stories

Now, at the end of this article, I give you a simple example for features and how to split them into user stories. Here I want to build a website that sells books. The features might be:

• Display informative Home screen
• User Registration
• User Login
• Display Products
• Display Shopping Cart
• Add products to Shopping Cart

And then, User stories would be developed off those:

Display informative Home screen:

• As a User, I want to access the home screen, so that I can enter the website
• As a user, I want to be able to see specials, so that I can see the current deals

User Registration:

• As a user, I need to be able to register as a new user, so that I can have more access to the site
• As a user, I want to be able to register with my Google account

User Login:

• As a user, I need to be able to login with my username/password, to gain access to the site
• As a user, I want to be able to login with my Google account, to gain access to the site

My general tip for you, keep the work breakdown, hierarchy, and granularity in agile product development as simple as possible and make sure that always the same terms are used in your organization and everyone knows what they mean.

Here You Can Find More Knowledge