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…”.

Purpose

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.

Usefulness

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.