User Story Template for Agile Teams for Startups

Detailed enough that QA can write a test from them without asking the PM clarifying questions. A good rule of thumb: 3-6 acceptance criteria per story. Fewer than 3 means you probably missed edge cases. More than 8 means the story is too large and should be split. Use the Given/When/Then format to keep criteria structured and testable. For broader guidance on writing requirements, see the [Product Requirements Checklist](/templates/product-requirements-checklist).

A user story describes a capability from the user's perspective ("As a team member, I want to toggle notifications"). A task describes implementation work ("Add a notifications_preferences table to the database"). Stories are what you put in the backlog and prioritize with stakeholders. Tasks are what the engineering team creates during [sprint planning](/guides/how-to-run-sprint-planning) to break a story into buildable units. One story typically produces 2-5 tasks.

Most teams use story points on a Fibonacci scale (1, 2, 3, 5, 8, 13). A 1-point story is trivial and well-understood. A 13-point story is complex and uncertain. If a story is estimated at 13 or higher, split it. Planning Poker (each team member privately selects a point value, then everyone reveals simultaneously) reduces anchoring bias. The absolute numbers do not matter. What matters is relative consistency: a 5-point story should take roughly 2-3x the effort of a 2-point story.

Not necessarily. Simple stories (toggle a setting, display a value) often do not need a mockup. Complex stories (new page layouts, multi-step workflows, novel interactions) benefit from at least a wireframe. The test is whether the engineering team can build the story without design ambiguity. If the acceptance criteria fully specify the behavior, a mockup is optional. If the criteria leave room for interpretation on how something looks or flows, include a mockup.

Use a spike when the team cannot estimate a story because the technical approach is unknown. A spike is a time-boxed research task (usually 1-2 days) that produces information, not shippable code. The output of a spike is a recommendation: "We should use WebSockets for real-time sync because polling would add 3 seconds of latency." After the spike, write the actual user story with the technical approach known. ---