Epics and User Stories

The canonical User Story format is: "As a [user type], I want [goal], so that [reason/benefit]." For example: "As a Customer Success Manager, I want to filter the account health dashboard by CSM, so that I can review only the accounts I am responsible for without cognitive overhead from the full portfolio view." This format forces the author to specify the user, their immediate goal, and the underlying motivation — preventing the common failure of writing stories from the product team's internal perspective ("Build a filter on the CS dashboard") rather than the user's perspective. Well-written stories contain acceptance criteria (the testable conditions for done), a relative effort estimate (story points), and a link to the parent Epic.

Definition of Ready (DoR) is a shared team agreement on the criteria a User Story must meet before it can be selected into a sprint. A typical DoR includes: story written in proper format with user, goal, and motivation; acceptance criteria written and validated by PM; design mockup (if UI-facing) reviewed and approved; dependencies identified and resolved or explicitly derisked; effort estimated by Engineering; test scenarios outlined by QA. Stories that don't meet DoR should be sent back by the team in sprint planning — selecting unready stories is the primary cause of sprint scope creep and missed sprint goals. Product Ops defines and maintains the DoR, trains new product team members on it, and audits backlog health by measuring the ratio of DoR-compliant stories.

The most common story-splitting failure is splitting by component (frontend story, backend story, database story) — this produces stories that cannot be independently tested or demonstrated and creates dangerous coupling between parallel development tracks. Better splitting patterns: by user type (power user story vs. read-only user story), by happy path vs. edge cases (minimal error handling in story 1, comprehensive error handling in story 2), by workflow step (story 1 covers creation, story 2 covers editing, story 3 covers deletion), by data volume (story 1 works for up to 100 items, story 2 adds pagination for 100+), or by progressive enhancement (story 1 covers the core feature, story 2 adds the performance optimization). Each resulting story should independently deliver user value and be demonstrable in a sprint review.