Skip to content

user story

A user story is a short, plain-language description of a software feature told from the perspective of the person who wants it, capturing who needs the feature, what they want to do, and why. Teams keep each story small enough to estimate in story points and finish within a single sprint, which is what separates a story from an open-ended feature request.

Most stories follow the Connextra format, a three-part template the team at Connextra shared with the Extreme Programming community in 2001. It keeps the focus on the user’s goal rather than the implementation:

Language: Text 
As a registered shopper,
I want to save items to a wishlist,
so that I can buy them on my next visit.

How It Shows Up in Practice

A Python developer meets user stories in the issue tracker, not the codebase. Jira, Linear, and GitHub Issues each model a story as a ticket with a title in the Connextra shape, a short description, and a checklist of acceptance criteria that spell out when the work counts as done. During sprint planning, the team pulls stories off the backlog, estimates each one, and commits to the set it can realistically deliver.

What turns a ticket into a real story is the conversation around it. Ron Jeffries captured this in 2001 as the three Cs:

A left-to-right chain. A teal "Card" box, a "Conversation" box, and a "Confirmation" box connected by labeled arrows, then a dotted "becomes" arrow to a yellow "Acceptance criteria" circle.
Each story moves left to right, and its Confirmation is what becomes the testable acceptance criteria.
  • Card: the one or two lines short enough to fit on an index card.
  • Conversation: the back-and-forth that fills in the details, which matters more than the words written down.
  • Confirmation: the acceptance criteria that confirm the story is finished.

Those acceptance criteria are also where a story meets behavior-driven development. A scenario in the Given, When, Then shape is a story’s confirmation rewritten so a test runner can check it, and a story isn’t truly closed until it also clears the team’s definition of done.

Anatomy of a Good Story

The common quality bar for stories is INVEST, a checklist Bill Wake introduced in 2003. A well-formed story is:

  • Independent: it can ship without waiting on another story.
  • Negotiable: it’s a starting point for discussion, not a fixed contract.
  • Valuable: it delivers something a user or the business can recognize.
  • Estimable: the team knows enough about it to size the work.
  • Small: it fits comfortably inside one sprint.
  • Testable: its acceptance criteria can clearly pass or fail.

A story that fails the small test is usually an epic, a large story that gets split into several smaller ones as the team learns more. A first release is often scoped as the thinnest stack of stories that still delivers value, the same instinct behind a minimum viable product.

When a story instead reads like a paragraph of technical specification, it has drifted from the user’s voice. The fix is to rewrite it back into the Connextra shape and let the conversation carry the rest.

Getting Started With Testing in Python

Course

Test-Driven Development With pytest

In this hands-on course, you’ll see how to create Python unit tests, execute them, and find the bugs before your users do. You’ll learn about the tools available to write and execute tests, check your application’s performance, and even look for security issues.

intermediate testing

For additional information on related topics, take a look at the following resources:

By Martin Breuss • Updated June 22, 2026
Software Engineering Glossary Share Feedback