A feature can be too large to build in one iteration. A user story gives the team a smaller piece to plan and discuss: something a user or stakeholder wants to achieve, stated in business language. Unlike a feature, a story need not be useful to deploy on its own. Its job is to help the team deliver the feature incrementally and get feedback sooner. section 5.2.3 section 3.3.2
Story: Providing a secure password when registering #1 In order to avoid hackers compromising member accounts #1 As the systems administrator #1 I want new members to provide a secure password when they register #1
This registration story names the business reason, the stakeholder, and the requested behavior. That structure makes the value of the work discussable; it does not settle exactly which passwords count as secure. section 5.2.3 section 6.2
Use the story to move from a broad feature toward a shared decision about what to build:
- State the goal, stakeholder, and desired capability. “In order to … As a … I want …” and “As a … I want … So that …” are useful conventions, not mandatory formats. section 3.2.3
- Split a feature into pieces small enough for an iteration. For a journey planner, direct connections and alternative routes can be separate stories, allowing earlier feedback. section 3.3.2
- Record initial acceptance criteria to expose scope and assumptions, then discuss rules and concrete examples with stakeholders. The first criteria need not be exhaustive. section 5.2.3 section 6.4.1
When a story needs a conversation
“Provide a secure password when registering” is a useful starting point, but “secure” needs testing against examples. An initial checklist might demand length, a digit, and punctuation. Comparing candidate passwords exposes whether those rules match the desired outcome: a table rejects “password1” but accepts “SeagullHedgehog.” The story prompts the discussion; examples sharpen the behavior. section 6.2
Keep the planning artifact separate from the lasting description of the product. Stories organize delivery and can be discarded once a feature is implemented. Feature descriptions, rules, and automated acceptance criteria better describe what the application does; organizing feature files one-to-one with stories can obscure that behavior as it evolves. section 5.2.4 section 7.4.5
