Originally published on the SharpQuest blog, written by Piyush Bhatt.
Key takeaways
- A user story, or product backlog item (PBI), describes what a user or the system should be able to do and why, not how it will be built.
- Write it as "As a [user], I want [capability], so that [benefit]", and add acceptance criteria so everyone agrees when it’s done.
- A story isn’t a task (how the work gets done), a feature or epic (a group of stories), or always one developer’s work. Developers add their own tasks and estimates under it.
- Some backlog items are system requirements users never see, such as purging history older than three months. They still belong in the backlog.
- A bug is undesired behavior, but it can be planned and tracked the same way as a story.
- AI assistants can draft stories and acceptance criteria from meeting notes, but the product owner still has to check them.
A user story describes something a user should be able to do, and why it matters to them. It says what the software should do, not how the team will build it. One of the most common Agile mistakes is mixing the two: developers write implementation tasks and call them user stories, and product owners write feature requests so broad that nobody can estimate them. Knowing the difference helps teams plan, estimate, prioritize and deliver better.
This is worth thinking about if you’re a:
- software development manager
- product owner or product manager
- project manager or Scrum Master
- business analyst
- quality analyst
and especially when you manage a team that includes some or all of these roles.
Why user stories matter
If you’re a founder, an operations manager or an IT director paying for software, user stories aren’t just Agile vocabulary. Well-written stories reduce misunderstandings, make estimates more reliable, and keep the team focused on business value rather than technical detail. A project that starts with clear stories and acceptance criteria leaves less room for change requests, budget surprises and missed expectations than one that starts with a loose list of features.
This is why discovery and requirements workshops are a standard part of our process for larger software projects. Investing time in defining workflows, user stories, and acceptance criteria before development begins helps teams align expectations and identify gaps before they become expensive changes later in the project.
When we started out as a software development firm, there was no distinction between the tasks developers wanted to do and the things clients were asking for. It was all one pool, spread across Excel files, Google Sheets and emails. That doesn’t mean we weren’t efficient: a small team on a small project can be very efficient that way. But when the projects and teams get bigger, you need the right tools and a better process, and that’s when you start asking what is not a user story.
In Azure DevOps and Jira, user stories are commonly managed as product backlog items (PBIs). Before Agile tools, the same thing was usually called a requirement, or a user requirement.
The user story format
Most teams write the story in three parts:
As a [type of user], I want [some capability], so that [some benefit].
For example:
As an administrator, I want to search users by email, so that I can quickly find a customer’s account.
In our own backlogs, the PBI title is a short version a non-technical reader can follow, and the "As a" sentence goes in the description:
- Title: Website visitor should be able to submit the feedback form
- Description: As a website visitor, I want to submit feedback, so that the site owners can consider my opinion in future updates.
The "so that" part is the one teams skip most often, and it’s the most useful. It tells the developer why the story exists, which helps them make the small decisions the story doesn’t spell out.
User story vs task, feature, epic and bug
| Item | What it describes | Example |
|---|---|---|
| Epic | A large body of work, usually several features, delivered over many sprints | Customer self-service portal |
| Feature | A group of related stories | User account management |
| User story / PBI | What one user (or the system) should be able to do, and why | User should be able to reset their password |
| Task | How the team gets part of a story done; hours, not days | Create the password reset API endpoint |
| Bug | Behavior that’s wrong and needs correcting | Password reset email isn’t sent |
What a user story is not
- A user story is not a task. If you’re a developer, or have a strong technical background, this is the one to remember. The work we do as developers, such as creating database tables, taking backups, adding a login form, securing an API or validating an email address, is not a user story. Developers naturally think in terms of the tasks they’ll perform, and it’s easy to enter those in Azure DevOps or Jira as stories. They’re tasks.
- A user story is not how. A backlog item shouldn’t describe how a feature will be implemented. Whether you add a drop-down, a new button or a new API is a detail of how you’ll do it.
- A user story is not a feature. A story doesn’t need to be as small as a task, but it shouldn’t be as broad as a whole feature either. "Search" is a feature. "User should be able to search products by keyword" is a story.
- A user story is not always one programmer’s work. In a small team, especially one with a developer who can do a bit of everything, you can assign a story to one person. In a larger team with specialists, one story may need a front-end developer, a database developer and an API developer. Then the story stays with one owner who’s accountable for it (see below), and each developer owns their tasks.
- The BA or manager doesn’t create the tasks. Tasks describe how a story will be built, and that’s the development team’s job. The developers working on the story add their tasks and estimates under it.
What a user story is
-
A user story is what, not how. When you read it, it should sound like what the user needs, not how it will be built. Examples:
- User should be able to log in with email and password.
- Admin user should be able to see a list of all application users.
- Admin user should be able to define roles from a set of predefined permissions.
- Most user stories start with the user. Notice that each example starts with a user, and that means the end user. What the user should be able to do is the focus, not what the developer should do. Some backlog items, though, are system requirements that matter to the business even though users never see them directly.
-
A product backlog item can also be a system requirement. For example:
- System should purge user history records older than three months, so that the database doesn’t grow without limit.
- System should keep a log of user logins for the past three months, so that administrators can audit access.
- System should archive invoices older than seven years, so that regulatory and retention requirements are met.
These are the client’s requirements, even though end users care little about them. That’s why many teams call backlog items PBIs rather than user stories: "PBI" covers both.
- A story has one accountable owner. Depending on the team, that may be the product owner, a business analyst, the Scrum Master, a tech lead or a developer. In small teams without a full-time BA or lead, it’s normal for the developer doing the work to own the story. What matters is that one person is accountable for clarifying the requirement and for delivering it to the stakeholders.
- Developers create their tasks for each story. The developers add tasks for each story, with an estimate for each. In our teams a task is typically 1-4 hours and has to finish inside the sprint. It’s fine to start with a single analysis task for the effort and split it further once the work is better understood.
User stories need acceptance criteria
A story says what the user wants. Acceptance criteria say how everyone will know it’s done. Without them, the developer, the tester and the product owner can each have a different picture of "finished".
Many teams write acceptance criteria in a Given/When/Then form. Here’s the feedback-form story from above:
Given I’m a guest or signed-in user
When I open the Feedback page
Then the system shows the Submit Feedback form with required Email, Name and Comment fields
When I fill in all three fields with valid values and click Submit Feedback
Then the system saves my feedback, shows "You’ve successfully submitted your feedback", and clears the form
A simple checklist works too. For "User should be able to reset their password":
- The reset link is emailed to the registered address.
- The link expires after 24 hours.
- The user can set a new password that meets the password rules.
- The user sees a confirmation message, and can sign in with the new password.
In our process, the product owner adds acceptance criteria before the backlog refinement meeting, the development team checks they’re clear before committing to the story, and the developer verifies every criterion before opening a pull request.
What makes a good user story?
A common checklist is INVEST, from the Agile Alliance. A good story is:
- Independent: it can be built and released without waiting for another story.
- Negotiable: it states the need, and leaves room to agree on the details.
- Valuable: a user or the business gets something from it.
- Estimable: the team understands it well enough to estimate it.
- Small: it fits comfortably in one sprint.
- Testable: it has acceptance criteria someone can check.
Common user story mistakes
| Mistake | Weak story | Better approach |
|---|---|---|
| Writing technical tasks as stories | Create the users table | Focus on the user outcome: "Admin user should be able to add a new application user" |
| Describing how instead of what | Add a drop-down for country | State the need: "User should be able to choose their country when registering, so that prices show in their currency" |
| Stories too large for one sprint | User management | Split into smaller stories: "Admin user should be able to deactivate a user, so that former staff can’t sign in" |
| No user benefit | User should be able to export reports | Add the "so that": "…so that the finance team can reconcile invoices in Excel" |
| Missing or untestable acceptance criteria | Make the search faster | Define when it’s done: "Product search returns results within two seconds for the full catalog" |
An example: from feature to tasks
Here’s how the levels fit together on a typical custom software project, such as a customer service portal:
- Epic: Customer service portal
- Feature: Customer search
- User story: As a customer service representative, I want to search customers by name or email, so that I can find their account while they’re on the phone.
- Acceptance criteria: partial names match; results show name, email and account number; an email search returns an exact match first.
-
Developer tasks:
- Add a full-text index on the customer name and email columns
- Build the search API endpoint
- Build the search screen
- Write automated tests for the endpoint and the screen
The product owner wrote one story. The developers turned it into four tasks, estimated each, and owned them. Nobody had to write "build the search API" as a user story.
We run every project this way, with stories, acceptance criteria and sprints; see how we work. The daily stand-up is where the team tracks those tasks day to day.
Story and bug
A story is a desired behavior that a system or application should have. It brings some benefit to the user or the system.
A bug is an undesired behavior the system has and that needs correcting. It gets in the way of the benefit a story brings.
The two are different, but you can manage a bug in your project tool the same way as a story: it has an owner, it may need several team members, and it can have tasks done by different people.
Frequently asked questions
What is the difference between a user story and a task?
A user story describes what a user needs and why. A task describes a piece of work the team does to deliver that story, such as building an API endpoint or writing tests. A story is written by or for the product owner; tasks are written by the developers.
Is a product backlog item the same as a user story?
Mostly. In Azure DevOps and Jira, "product backlog item" is the general name for an item in the backlog. It covers user stories and also system requirements that no user sees directly, such as purging old records.
Who writes user stories?
Usually the product owner or a business analyst, often with the client. Developers and testers help refine them, but they shouldn’t turn their own tasks into stories.
How big should a user story be?
Small enough to finish in one sprint, and big enough that a user gets something from it. If a story needs more than one sprint, split it; if it only describes one technical step, it’s a task.
What are acceptance criteria?
The conditions a story must meet to be accepted as done. They’re often written as Given/When/Then scenarios or a short checklist, and the developer and tester check them before the story is closed.
Should technical work be written as a user story?
Technical work that delivers something the client needs, such as audit logging or data retention, can be a backlog item written as "System should … so that …". Technical steps that only serve a story, such as creating a table, are tasks under that story.
Is a bug a user story?
No. A story adds behavior the system should have; a bug corrects behavior it shouldn’t have. You can still track and plan a bug the same way as a story.
Can AI write user stories?
AI assistants can turn meeting notes or a requirements document into draft stories and acceptance criteria quickly, and they’re good at spotting missing edge cases. But they don’t know your users or your business rules. Tools such as Microsoft Copilot, ChatGPT, Claude and Gemini are useful for drafting backlog items, but treat them as writing assistants, not product owners: the product owner still has to review every story before it goes into a sprint.
User stories focus on the value a user or the system gets, while tasks describe how developers deliver that value. Teams that keep stories separate from implementation details have clearer backlogs, better estimates, and better communication between business stakeholders and developers. At SharpQuest, we write user stories and acceptance criteria during discovery and refine them throughout development, so clients know what’s being built, why, and how completion will be measured.
SharpQuest builds custom web, mobile and AI software for businesses across the US. More on how we run projects in how we work.
Top comments (0)