Photo by Green Chameleon

As a developer, I want this user story template to stop... Michał Piotrkowski

As a role
I want feature
So that benefit

I suspect that many of you use this user story template. Let me tell you a secret. Developers hate this kind of boilerplate. I will shortly describe why.


Before we get to the problems with this template, let’s understand why it is so popular in the first place. User Stories have been popularized together with the Extreme Programming movement. From the very beginning the “As a … I want … so that …” template has been widely adopted. It was consequently described and advertised in many books including famous User Stories Applied by Mike Cohn.

Comparing to the formal, rigid and boring Functional Requirement Documents (FRDs), that were de facto standard at that time, user stories with their memorable, novel and very lightweight structure were a true revolution.

Requirements finally began to highlight for whom and, most importantly, why the feature should be developed in the first place, instead of only focusing on what (or how) should be done. Moreover, user stories were supposed to be short descriptions - they should fit 3x5 inch card. They were meant to be just a placeholder for (instead of a replacement of) conversation. This led to a closer collaboration within the team effectively inviting the whole team to provide additional insight: Maybe we can achieve the same (or similar) goals with an alternative faster / cheaper / simpler approach?

User stories fit nicely to the XP and Agile mindset.


If it is so good, why is it so bad then?


For starters, they became a victim of its own success. Everybody likes ice cream, right? Then, imagine eating icecreams for breakfast, lunch, and dinner. Every day. You would probably start hating them very quickly.

The same rule applies to user stories. Once you have seen dozens of them in the same repetitive format. They are no longer novel, original nor fun. When you see yet another story you subconsciously start to skip everything before “I want” and after “so that”. You are tired of not seeing the story essence at first glance. The stories start to blend. Shortly after, you start wondering why not to unwrap them from this whole boilerplate whatsoever.

Actually, there is an interesting version of the aforementioned template that reads: “In order to … I want … so that …“. Personally, I like it better as it puts (usually) the most important part (“why”) in the beginning.


When you hold a hammer everything looks like a nail. Once the template is used to describe every story, it decreases your imagination. You no longer think what the best way to describe the story is. You focus only on how to fill the slots. This effectively prevents you from experimenting with alternatives.

Sometimes the story will simply not fit the template. Period. Other times you will know the problem but not the solution, which allows you to effectively populate the “why” part but not the “what” part. Finally, there can be simply better ways to express the problem behind the story.

Regardless of whether it is caused by too eager standardization or by lack of imagination, sticking to the one true template results in sub-optimal stories that do not utilize the full potential of expressive means.


This is not connected to the template itself, but it is somehow amplified by it. If you are lazy writing your stories using the template you will be probably lazy without them. The most common types of laziness are:

  • using generic role in the “As a” part
  • repeating yourself in “I want” and “So that” parts

Consider a story like this:

As a user
I want to be able to generate a monthly sales report
So that I see sales data from a given month

As a developer, I find this kind of tautological, generic story almost disrespectful. Why would you expect me to write a meaningful code if you cannot provide a meaningful user story?


OK, so what we can do to address these problems with the user story template?

  1. Don’t use it by default for every single story you write. Consider alternatives including diagrams, drawings, screenshots.
  2. Make the user stories visually appealing. Help your brain by emphasizing differences and de-emphasizing boilerplate parts. For example, have a look at how it can be done in
  3. Write meaningful and engaging stories and don’t take shortcuts. If you don’t know or you are not sure of any of the “who” / “what” / “why” parts, don’t force yourself to write something just to fit the template. Instead, use your description to ask for feedback and ideas.

De-emphasized user story template boilerplate

Wish you all productive user storytelling!

If you liked this article you might be interested in following me @mpidev or @storyhub_io on Twitter, so that you will be notified when a new article like this is published.

About the author

Michał is the founder of Simple backlog & agile project management tool. He has over 7 years of experience with agile project development and works at Pragmatists, an agile software house.