By Teresa Torres · producttalk.org · @ttorres on X · LinkedIn
Teresa Torres extends her earlier post on user stories by walking through the INVEST criteria (Independent, Negotiable, Valuable, Estimatable, Small, Testable) with concrete examples. She argues that stories should be conversation starters rather than contracts, should name a real user benefit, and should avoid prescribing UI or technical details. She shows how to handle dependencies, unknowns, and epics, including time-boxed research tasks when a story cannot yet be estimated. She also stresses writing acceptance criteria before building so teams test intended behavior. The guidance matters because well-formed stories make prioritization, estimation, and business-engineering dialogue work better.
01Key takeaways
- Ask whether a story adds value on its own; if not, remove the unnecessary dependency.
- Treat user stories as conversation starters that can be revised as new information emerges.
- Make sure every story names a concrete benefit to the user, not just a business need.
- Keep UI and technical details out of stories unless they reflect the user's perspective.
- Time-box research tasks when a story can't be estimated, instead of writing a fake user story.
- Write acceptance criteria before building so the team tests the intended functionality.
02Key sections
- Independent stories
- Stories should avoid unnecessary dependencies, since shared upfront work distorts estimates and priorities. Torres shows how adding a foundational story can separate that overhead.
- Negotiable stories
- Unlike PRD requirements treated as contracts, stories should spark ongoing conversation as engineers learn new information during development.
- Valuable stories
- Every story should name a benefit to the user or customer; stories that only serve the business, like email verification, should be reframed around a user outcome.
- Estimatable stories
- Stories that cannot be estimated usually lack information or a known technical solution. The fix is to gather information or add a time-boxed research task rather than a fake user story.
- Small and testable stories
- Epics should be split into smaller value-creating stories, and stories should be written with measurable criteria defined before implementation begins.
03From the post
“In April, I wrote User Stories Are Better Than PRDs. To date, it's been one of my most popular posts. It covers the basic format of user stories: As a user role, I'm able to do some functionality, for some explicit benefit. It looks at each component and”
04Frameworks mentioned
Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.