Skip to content

Why I don't use standard user story format that much

  • strict warning: Non-static method view::load() should not be called statically in /home/artemmarchenko/ on line 823.
  • strict warning: Declaration of views_plugin_display::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/ on line 1684.
  • strict warning: Declaration of views_plugin_display_page::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 457.
  • strict warning: Declaration of views_plugin_display_block::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 184.
  • strict warning: Declaration of views_handler_field_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 243.
  • strict warning: Declaration of views_handler_sort_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 82.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/artemmarchenko/ on line 584.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/artemmarchenko/ on line 584.
  • strict warning: Declaration of views_handler_filter_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/ on line 608.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/ on line 61.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/artemmarchenko/ on line 61.

March 10, 2009 by Artem Marchenko

image Agile requirements are different from the traditional ones and are usually defined as user stories that allow for slicing functionality in the shippable increments. There are recommendations for a standard user story format and the most known one is “As a <type of user>, I want <some goal> so that <some reason>” popularized by Mike Cohn. The trend for recommending the common format is so strong that there is an evolution and there exist even hacks for making it work in the situations when it doesn’t fit naturally.

I used to be in the same camp of standard format proponents, until I noticed that more and more my stories look closer to “Implement list widget support” and further from “As an application designer I want to use a list widget so that…”.


Those who recommend the standardized format strongly find its usefulness in that it makes you think about the actual user persona or sometimes about a very concrete user. In theory it helps you to make less features just for making the features and more features that will actually be wanted and used by somebody. So why don’t I find it that useful anymore? Well, I know all my user types by heart (I think) and for particular categories I may be able even to list very concrete features needed by a very concrete list of people. Then all these wording just takes space and getting rid of it allows me to focus on the actual feature to be done.

You can argue that the format is useful for starters who don’t know their users and their needs that well. Nice theory, but is a bit of an exaggeration as for me. If somebody is not interested in focusing on the end user and figuring out his real needs, no format on Earth can make him be interested. God knows how many times I was reading stories formally written in canonical format yet making no sense whatsoever and ending as useless half-a-features.


There are two situations when I find the standardized format useful:

  • When you communicate stories to somebody who isn’t in daily contact with you. For example, with external stakeholders and possibly a distributed team (though team will anyway need more detail, than just a clever title)
  • When you have similar functionality for different user categories and want to distinguish between them
In all other cases I find the format no more useful, than any other thinking tool such as modeling team behavior with the help of storming model.

Use the standard user story format if you know what you need it for or if you. I am also going to recommend thinking about its usefulness. Just remember that using standard user story format for the sake of “standardness” is senseless.

About the Author: As the Editor-in-Chief for, Artem is charged with overseeing the direction for content, advertising, and the overall management of the site. Nowadays in his day life, Artem is a product manager in a global telecommunication company where he leads the development of a product developed in extremely distributed environment. Artem has been applying Agile and researching Agile since 2005. Contact Artem


Thank you for the comments,

March 12, 2009 by Artem, 7 years 32 weeks ago
Comment id: 2356

Thank you for the comments, guys. I particularly like the haiku idea. Should be a lot of fun.. as long as we are for fun :)

Mike, I fully agree that it

March 13, 2009 by Artem, 7 years 32 weeks ago
Comment id: 2365

Mike, I fully agree that it is important to focus on what's important and if your way helps you - great. In fact I often use a similar system, just skipping (or transforming) different format parts depending on which part of the context is obvious. If I know for sure, that for particular story only users that make sense are application designers, I probably would skip the role title. If there can be nuances when font is chosen by designer or developer (e.g. imagine developer wants to quick play with fonts, while designer needs to fine tune them), then I usually specify the role.

The point is anyway in that the format is just a tool, it cannot force anybody think hard about the user. It's a good tool to play with IF you do care about the user, but e.g. find that too much unstructured info can't fit into your head.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of