How would you break a large epic into sprint-ready user stories?

WHAT THIS TESTS: The interviewer wants to see if you can navigate ambiguity and scope decomposition at a senior level. It is not about memorizing agile jargon; it is about demonstrating product thinking, risk management, and pragmatism. They care whether you can deliver incremental value to users rather than building in horizontal silos that delay feedback.

A GOOD ANSWER COVERS: First, discovery and mapping. You would gather stakeholders to clarify the user journey and business outcomes, using story mapping to visualize the epic from the user's perspective. Second, vertical slicing. You would break the epic into end-to-end user stories that each deliver a thin, complete slice of functionality, such as "As a shopper, I can add a single item to my cart so that I can review it later." Third, INVEST and acceptance criteria. Each story should be Independent, Negotiable, Valuable, Estimable, Small, and Testable, with explicit acceptance criteria to reduce ambiguity. Fourth, sequencing and dependency management. You would prioritize by business value and technical risk, shipping high-risk or high-value flows early to validate assumptions. Fifth, sprint readiness. Stories should be sized to fit within a single sprint, typically 1 to 8 story points, and reviewed in backlog refinement before sprint planning.

COMMON WRONG ANSWERS: Decomposing by technical layer is the most common red flag, for example planning a sprint for database schema, the next for REST APIs, and the last for the React frontend. This delays integration and user feedback. Another red flag is creating stories that are too large, such as "Implement the entire checkout flow," which violates the Small principle and cannot be completed in one sprint. A third red flag is ignoring acceptance criteria or business value, treating stories as mere task lists for engineers.

LIKELY FOLLOW-UPS: The interviewer may ask how you handle stories that span multiple teams or services, how you deal with discovered dependencies mid-sprint, or how you balance refactoring work against feature delivery. They might also ask for a concrete example, so be ready to whiteboard a story map for a shopping cart in real time.

ONE CONCRETE EXAMPLE: For an "Implement a shopping cart" epic, a vertically sliced breakdown could look like this. Story one: As a logged-in shopper, I can add one item to my cart from the product page so that I can continue browsing. Story two: As a shopper, I can view my cart summary with item names and prices so that I know what I am about to buy. Story three: As a shopper, I can update item quantities in my cart so that I can change my mind before checkout. Story four: As a shopper, I can remove an item from my cart so that I do not accidentally purchase it. Story five: As a shopper, I can see my cart persist across sessions on the same device so that I do not lose my selections. Each story is end-to-end, touches the UI, backend, and data layer, and can be demonstrated to stakeholders independently.

Source: Atlassian Community