3/8 - Theme, Epic, Feature, Story
3/8 - Theme, Epic, Feature, Story
The user stories are the requirements told from an end-user perspective to capture the description of a product feature.
What is a Theme?
A scrum theme is the highest level of the story hierarchy. It describes a view of a tangible product or an abstract goal. A product owner further breaks down a theme into one or more epics.
Let's treat these as strategic business objectives in the form of items. They provide business context for decision-making and help you navigate the course of your organization. They also affect the work items you are going to load in the different value streams.
What are Epics?
In Agile project management, epics are larger bodies of work, which can be the building blocks of the upper mentioned initiatives/themes. They should be more specific and measurable so that you can see their contribution to the primary goal.
These Agile epic examples will consist of several tasks, work items, or user stories that need to be completed over a more extended period.
Depending on their size, they can also turn into bigger projects. Regardless of how you choose to name them, the important thing here is to ensure that those epics/projects are related to the main theme/initiative and support the high-level goal of penetrating the project management software market.
Creating an epic
When creating a new epic consider other planning and organization tools your team may already have in place. Creating epics around a team’s quarterly goals or OKRs is a great start. When creating an epic, consider the following:
Reporting — Create epics for the projects that managers and executives will want to keep an eye on.
Storytelling — Use epics, and the stories that roll up into them, as a mechanism to tell the story of how you arrived at the current state of a feature or product.
Culture — Let organizational culture dictate the size and granularity of an epic.
Time — Most development teams rely on estimation frameworks instead of time, but it’s a worthwhile gut check to make sure your epics will take a couple of weeks to complete. Not too long and not too short.
Break down an epic
Breaking down an epic into more practical stories helps in understanding a project and maintaining momentum, but it can be a daunting task for the uninitiated. There is no one-size-fits all solution for creating stories from an epic, but there are a lot of good options to consider:
User role or persona — Create a unique story for each user persona. “Quicker login for new visitors,” “quicker login for return customers,” etc.
Ordered steps — Break down the process and create a story for each step.
Culture — Let team norms dictate if a story is a quick task or a week-long project.
Time — Barring another agreed-upon convention, design stories that can be completed in one print or less.
There is no universal definition that draws a line between a big story and an epic. In general, any scope of work that the team estimates at “weeks” (or longer) to complete, rather than “hours” or “days” should be considered an epic and broken down into smaller stories.
What is a feature?
A feature is a consistent function or service of the product.
Features represent parts of the product that bring significant value to its users. Features are usually too big to big worked on directly so they are broken down into smaller business units: stories. As far as planning is concerned, producing a feature is expected to last several sprints. Features help materialize the vision and share it to the agile team and the stakeholders.
“A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria.”
Ideal feature criteria
It should provide business value.
It should be estimable - it must have enough definition for the development team to provide an estimate of the work involved in implementing it.
It should be small enough to fit within one or two iterations - therefore, if it is too big, it should be broken down further.
It should be testable - you should understand what automated or manual test a feature should pass in order to be acceptable to the customer.
Managing feature requests
Firstly, it’s worth highlighting that not all feature requests are the same. They can be broken out into three different types:
Unresolved problems with an existing feature e.g. the customer has experienced a technical issue and is unsure how to make progress.
Feature improvements e.g. the customer is not sure on how to achieve a certain result with your product.
A brand new feature request e.g. the customer is asking for something that’s not yet supported in your product.
How to prioritize feature requests
Once you’ve gathered feature request data from customers, along with their relative importance, you need to find a way to prioritize the suggestions.
Potential factors you’ll want to include are:
Customer lifecycle. You might want to respond to customers who contact you in the first days after sign-up, as they are at the highest risk of churning.
High-value users. As they are the customers paying you the most money, you’ll want to pay particular attention to their feedback. Especially if this group plays a crucial role in your long-term growth.
The difficulty of implementing the proposed improvement. Some feature improvements might be relatively straightforward to implement and provide 10x value to customers. On the flip side, some improvements look simple but require months of complex engineering.
The volume of feedback. Logging the number of times each individual product improvement has been suggested can help you make a case for bringing a particular feature request to the product team.
What are user stories?
A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.
A user story is an informal, general explanation of a software feature written from the perspective of the end-user or customer.
The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team.
User stories are a few sentences in simple language that outline the desired outcome. They don't go into detail. Requirements are added later, once agreed upon by the team.
Stories fit neatly into agile frameworks like scrum and kanban. In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.
User stories are also the building blocks of larger agile frameworks like epics and initiatives. Epics are large work items broken down into a set of stories, and multiple epics comprise an initiative. These larger structures ensure that the day-to-day work of the development team (on stores) contributes to the organizational goals built into epics and initiatives.
Why create user stories?
For development teams new to agile, user stories sometimes seem like an added step. Why not just break the big project (the epic) into a series of steps and get on with it? But stories give the team important context and associate tasks with the value those tasks bring.
User stories serve a number of key benefits:
Stories keep the focus on the user. A To-Do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.
Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve an end goal.
Stories create momentum. With each passing story, the development team enjoys a small challenge and a small win, driving momentum.
How to write user stories
Consider the following when writing user stories:
Definition of “Done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
User personas — For Whom? If there are multiple end-users, consider making multiple stories.
Ordered Steps — Write a story for each step in a larger process.
Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
Once the user stories are clearly defined, make sure they are visible for the entire team.
You might also like :
User Stories Playbook (Pre-Order @50% off)
User Stories and backlog management guide
User Stories and Backlog Management Playbook
Module 1 – Agile Manifesto and Principles
Module 2 – Agile Methodology
Module 3 – User Stories
Module 4 – Epic, Theme and Story evolution
Module 5 – Agile User Stores
Module 6 – The 3-C’s of User Stories
Module 7 – INVEST Criteria for User Stories
Module 8 – User Story Estimation Methods
Module 9 – Exercises and Case Study
This is for you if:
You are a new product manager
You don't know how or where to start
You've started working on the product role but still feel lost about writing stories
You're none of the above but you know someone who is. Gift them!
Thank you for your support, Product Mindset Team.