How do you break down an epic into user stories?
Tests translating business needs into incremental work. A great answer uses story mapping to define a vertical slice MVP, then creates sprint-ready stories with acceptance criteria. A red flag is just listing features without prioritizing user value.
What's really being asked
This question assesses your strategic thinking, not just your knowledge of Agile terminology. The interviewer wants to see if you can take a vague, large-scale business goal and collaboratively create a concrete, prioritized, and incremental execution plan. It tests your ability to balance user value, technical feasibility, and team capacity to deliver results quickly and iteratively. They are looking for a leader who can guide a team through ambiguity.
The full answer
A senior-level answer outlines a collaborative process with four key steps. First, initiate a story mapping session with the Product Manager, Designer, and other engineers to visualize the entire user journey and identify all potential user actions. Second, define the 'thin vertical slice' or MVP: the smallest end-to-end flow that delivers tangible value. For a shopping cart, this might be adding one item and checking out, deferring features like quantity changes or saving for later. Third, break this MVP slice into sprint-ready stories. These should be small enough (e.g., 1-3 days of work) and follow the INVEST principle (Independent, Negotiable, Valuable, Estimable, Small, Testable). Include both user-facing stories ('As a shopper, I can add an item to my cart') and necessary technical stories ('Create cart data model in the database'). Fourth, for each story, define clear, testable acceptance criteria before it's considered 'ready.'
The mistakes people make
A major red flag is simply listing features without a clear strategy. For example, 'First we'll build the add to cart button, then the quantity selector, then the remove button...' This is a feature list, not a plan for incremental delivery. Another mistake is creating stories that are too large or coupled, like 'Implement the entire cart UI,' which is not sprint-ready. Forgetting to mention collaboration with PMs and designers is also a sign of a less experienced engineer who works in a silo. Finally, failing to mention technical stories (e.g., for data models, API endpoints, or infrastructure) shows a lack of practical implementation experience.
What usually comes next
Be ready for 'How do you handle dependencies between stories?' (Answer: Identify them early, sequence work accordingly, or use feature flags to merge incomplete work safely). Another is 'What if the PM insists on a feature you believe is too complex for the MVP?' (Answer: Use data, propose a simpler alternative that meets the core need, and quantify the trade-offs in terms of engineering cost vs. user value). 'How do you estimate these stories?' is also common.
A concrete example
For the 'Implement Shopping Cart' epic, the first vertical slice might be: 'A user can add a single, specific item to a cart and see it on a dedicated cart page.' This breaks down into stories like: 1. (Backend) Create API endpoint to add an item to a session-based cart. 2. (Backend) Create API endpoint to view the cart's contents. 3. (Frontend) Modify the product page to include an 'Add to Cart' button that calls the API. 4. (Frontend) Create a basic cart page that displays items from the view-cart API. This delivers a complete, albeit minimal, user experience. Features like quantity updates, removing items, or persistence across logins would be in the next slice.
Interview question
When breaking down a large epic into user stories, which approach best ensures incremental value delivery and team collaboration?
- a.Collaboratively define a 'thin vertical slice' MVP through story mapping, then break it into small, INVEST-compliant stories with clear acceptance criteria.Correct
- b.Create large, high-level user stories covering major functionalities (e.g., 'Implement Cart UI'), and break them down further during sprint planning.
- c.Design the complete technical architecture and database schema for the epic, then create technical stories for each component to be implemented.
- d.List all features required for the epic, prioritize them by perceived user value, and then assign them to developers for implementation in order.
Why? this is the answer
The correct approach involves collaborative story mapping to define a minimal viable product (MVP) as a 'thin vertical slice' first, ensuring early value. These are then broken into small, INVEST-compliant stories with clear acceptance criteria. Option D, while mentioning user value, describes a feature list approach which lacks the iterative, collaborative breakdown and MVP focus for incremental delivery.
Just read this? Test yourself on what you have been reading.
Read the original → community.atlassian.com
- #agile
- #scrum
- #project management
- #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