In our previous article, we explained what a user story is, the most common mistakes made when writing them, and how artificial intelligence can help you create and improve them automatically. Today, we want to go a step further — we want you to learn how to write them well.
And you might think, “Why bother, if I already have an AI that generates them automatically?” But we all know that AI requires human oversight, and only by truly understanding how to write them correctly can you validate the result of that automatic generation, refine it, and achieve the best possible version for your project. That, without a doubt, is what separates teams that deliver tasks from those that deliver value. Which team do you want to be part of?
If you want to be among those who deliver value, keep reading because we’ll cover:
- The benefits of writing good user stories
- Examples of poorly written stories and how to improve them
- Examples of well-written user stories
- How Quanter helps you improve your user stories
Benefits of writing good User Stories
When a user story is well written, the team notices it right away. And if the team notices, so does your project. Why? Because good user stories help you achieve all of this:
- Understand exactly what is expected.
- Estimate with greater accuracy.
- Define solid acceptance criteria that help validate the story once it’s completed.
- Reduce the risk of mistakes and misunderstandings. Fewer mistakes mean fewer corrections.
- Move faster without neglecting quality.
Moreover, a well-written story is much more than just a task. It’s a way to connect business and IT, a conversation between teams where we need to clearly communicate the purpose. If we get that right, we can align the whole team around a shared objective.
As you can see, writing good stories isn’t just a nice-to-have: it’s a practice that will save you time and help avoid conflicts and errors.
Poorly written stories: common mistakes (and how to fix them)
Let’s move on to practice by looking at some real examples of common issues we find in poorly written user stories. And we won’t just look at the problems — we’ll also analyse why they’re problematic and offer improved versions of the stories that solve the issues.
Problem 1: Vague story
Example of a vague story: “As a user, I want to see my data.”
- Problems: Which data? What for? In what context?
- Improved story: “As a registered customer, I want to access my personal data (name, address, email) from my profile so that I can review and update it if needed.”
Problem 2: No clear benefit
Example of a story without a clear benefit: “As an administrator, I want a button to generate reports.”
- Problems: What kind of reports? What’s the goal?
- Improved story: “As a sales administrator, I want to generate monthly billing reports by region in PDF format so I can present them in results meetings.”
Problem 3: Technical task disguised as a story
Example of a technical task disguised as a story: “Upgrade to Java 17.”
- Problems: Not a functional story, no explicit business value.
- Improved story: “As a maintenance lead, I want to upgrade the environment to Java 17 in order to benefit from performance improvements and long-term support.”
Problem 4: Story too big for a sprint
Example of a story too big for a sprint: “As a customer, I want to complete the whole purchase process.”
- Problems: Unmanageable. Needs to be split.
- Improved stories:
- “As a customer, I want to add products to the basket so I can review my order before paying.”
- “As a customer, I want to pay by card so I can complete my purchase securely.”
Problem 5: Technical language with no user focus
Example of overly technical language: “As a user, I want to access the endpoint /api/v1/user to retrieve my data.”
- Problems: No real user would say this.
- Improved story: “As an authenticated user, I want to view my personal data after logging in so I can ensure it is up to date.”
Problem 6: Untestable story
Example of an untestable story: “As a manager, I want a tool that’s easy to use.”
- Problems: “Easy” is not an objective or verifiable condition.
- Improved story: “As a project manager, I want the main dashboard to display a visual summary (progress charts, active tasks, upcoming deadlines) so I can access key information at a glance.”
What lies behind a well-written User Story. Examples
Once we’re clear on the problems we face, let’s take a look at some examples of user stories that are well-crafted from the outset.
- Customer Portal: “As a registered customer, I want to change my postal address from my profile to ensure I receive physical notifications correctly.”
- Ordering App: “As an app user, I want to see the estimated delivery time before confirming my order so I can make more informed decisions.”
- System Administration: “As a system administrator, I want to generate a monthly user activity report in PDF format so I can send it to the area managers.”
- User Experience: “As a frequent user, I want the system to remember my recent searches to save time when browsing similar products.”
What do these user stories have in common? They meet the main characteristics of good user stories we explored in our previous article:
- They are clear and specific, written in natural language.
- They include a defined role, a specific action, and a tangible benefit.
- They can be estimated, tested, and delivered without ambiguity.
- They allow for objective acceptance criteria to be defined.
In short, they help the team understand what needs to be built, why it matters, and how to validate that it’s been done right. Exactly what every user story should aim to achieve.
With Quanter, you can write better User Stories
At Quanter, we know a lot about software project estimation. That’s why we understand that to produce a good estimate, you first need a solid requirement or user story. Thanks to the AI integrated in Quanter, we don’t just calculate the functional effort of each story: we also help you review and improve them right from the start.
How does it work?
- It automatically analyses your stories and detects ambiguities, technical jargon, or common mistakes like the ones we reviewed earlier.
- It suggests improvements based on industry best practices or on rules defined by you or your organisation.
- It checks the structure and consistency of each story: role, action, and purpose.
- And once the story is well written, it automatically calculates the estimated effort linked to it.
And the best part: you can export the improved stories to Jira, Azure DevOps or download them in your preferred format, so your team can start working with a high-quality backlog without disrupting the workflow. And there’s more: it can even adapt to different teams, departments, and levels of agile maturity.
There’s no longer any excuse for poorly written User Stories
Well-written user stories are one of the most powerful components of well-applied agility. And writing them properly is no longer optional, but now, thanks to Quanter, it’s also easier than ever.
Quanter helps you go beyond what’s “just acceptable” to craft stories that truly guide your team in delivering consistent and valuable outcomes: better planned and building more useful products. At Quanter, we’re certain of one thing: when you write better user stories, you build better. Would you like to start writing better user stories too?
About the author
Agile | Agility | artificial intelligence | software development | User stories
