How would you break down an epic into user stories?
Tests your ability to turn business goals into independent engineering tasks. A great answer maps user journeys, breaks work into vertical slices, defines acceptance criteria, and prioritizes by value.
What's really being asked
This question tests your ability to translate a large, ambiguous business requirement into small, independent, and valuable user stories that a team can execute within a sprint. The interviewer is assessing your product-minded engineering approach. They want to see if you can deconstruct a goal like 'Implement a shopping cart' into a series of concrete, testable, and shippable increments, not just a technical to-do list.
The full answer
A strong answer outlines a structured, user-centric process. First, clarify the business goal and identify the user personas and their high-level journey. Second, decompose the epic into vertical slices, where each story represents a complete, end-to-end piece of user-facing functionality. Third, define specific, measurable acceptance criteria for each story, often using a 'Given-When-Then' format. Fourth, discuss prioritization based on business value (e.g., using MoSCoW) and ensuring stories are small enough to complete in a sprint, typically 2-3 days of work for one engineer.
The mistakes people make
The most common red flag is breaking down work by horizontal, technical layers. For example: 'Story 1: Create the database table. Story 2: Build the API endpoints. Story 3: Implement the UI.' This is a waterfall plan. No single story delivers value to the user, they can't be tested independently, and it creates cross-sprint dependencies. Another mistake is creating stories that are actually tasks ('Change button color') or are too large to be completed in a single sprint ('Build the entire checkout flow').
What usually comes next
Prepare for questions like: 'How do you handle dependencies between stories?' or 'What if a story is too big to fit in a sprint?' For dependencies, the goal is to create independent stories, but when unavoidable, you sequence them. For stories that are too big (often called 'epics' themselves), you apply the same breakdown process again to split them into smaller, valuable chunks. For example, 'View Cart' could be split into 'View items in cart' and 'Update quantities in cart'. Non-functional requirements (NFRs) like performance can be their own stories ('Cart page loads in <500ms') or added as acceptance criteria to functional stories.
A concrete example
For the epic 'Implement a Shopping Cart':
A good vertical breakdown would be: Story 1 (Must-have): As a user, I can add a product to my cart from a product page so I can start shopping. AC: When I click 'Add to Cart', the cart icon's item count increments by one. Story 2 (Must-have): As a user, I can view my cart's contents on a dedicated page so I can review my selections. Story 3 (Should-have): As a user, I can remove an item from my cart so I can change my order. Story 4 (Could-have): As a logged-in user, my cart is saved between sessions so I can finish my purchase later.
Interview question
For a 'new search feature' epic, which option is a poor, horizontal breakdown where no single story delivers value to the user?
- a.Story 1: Implement the entire search and filtering system. Story 2: Add a 'did you mean?' suggestion.
- b.Story 1: Search page loads in under 1 second. Story 2: A user can see their recent searches.
- c.Story 1: A user can search by keyword to see product names. Story 2: A user can filter results by category.
- d.Story 1: Create the search index. Story 2: Build the search API. Story 3: Implement the search UI.Correct
Why? this is the answer
This is a horizontal breakdown by technical layer; no single story provides end-to-end value to the user. A better approach is a vertical slice, like option C, where each story is a complete, shippable feature.
Just read this? Test yourself on what you have been reading.
Read the original → community.atlassian.com
- #agile
- #scrum
- #product sense
- #execution
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles