User Stories Aren’t One-liners

User stories… in the agile environment everybody is talking about them. And almost everybody is writing them, or at least trying to.
I’ve written hundreds, maybe thousands user stories. They weren’t all great, especially in the beginning of my career. But over time the stories became better and better, because I never stopped learning from colleagues, team members, blogposts and so on. The feedback I got from my teams made me write this post for people who want to read and learn a few tips and tricks for writing better user stories. Or if you are just starting your career as a Product Owner, Business Analyst or any other position in which you’re writing stories, this post could be helpful.

User stories are written for development teams in order to create a product.
The right product.
If you want the right product, you need the right user stories sorted by the correct priority.
I’ve seen many backlogs containing one-liner user stories. The PO let the team struggle with these stories and problems of various kind emerge very quickly. One line is just not sufficient for developers, designers and testers to start working on these items. Lacking information is in my opinion one of the biggest reason for slow progressing of projects, wrong interpretation, rework, unhappy stakeholders, etc.
You can avoid these problems by adding more information. And let me state this up front: adding more information is still agile!

So, what do I do to create good user stories? Stories that contain sufficient information for development teams to work on? Stories that reflect the correct business needs and are easy to understand by any involved person.

Let me start with the basics.
User story is just a notation for requirements. Period.
Is looks like this:

AS persona
I WANT functional wish
SO I CAN do something that has value
WHEN conditions for this story


Persona is the concerning user.
I will discuss the topic persona’s in another blogpost about UX/UI in Scrum.

The functional wish is the core of the story. I want to emphasise that it is a value adding functional wish. Not a solution!
The team will think of a solution for the functional wish or problem. If there is more than one solutions possible, you can help choose the best suitable one. The one that adds the most value in the shortest period of time, the one that has the best future proof characteristics, the one that required the minimum of dependencies, etc.

The last part of the story makes the feature applicable. When should the user be able to use this feature? After logging in? When there is an incoming call? If a certain skill is required? Don’t forget this last bit of important information.

The basics are pretty simple. What’s next?

I ask myself questions like:

  • What story type is this? Is it about a feature, which is part of an epic? Or is it a bug, or maybe part of some technical debt that needs to be solved?
  • When can I accept this feature and deliver it in production?
  • What are the requirements regarding performance, availability, responsiveness and documentation?
  • What exactly is the value we’re adding here? Business value? Yes, so what it is? What if we don’t deliver this feature? What’s the cost of delay?
  • Are there any dependencies related to this story? Do we need another team or an architectural change? Do we need an expert from the business at a certain moment?
  • What if the system goes down? How is the team alerted? Should we monitor the systems behaviour to avoid outages?
  • Any other requirements? Like time constraints, compliance or security, feature toggling, user training, handover to operations, etc?

By asking the business, yourself and the team many of these questions, the user story will be more complete over time, and in the end ready for a sprint. The user story is now to the point, small enough to be comprehended by everybody, easy to change and thus very agile.






Log In

Wachtwoord vergeten? / Gebruikersnaam vergeten?