Agile Zone is brought to you in partnership with:

Artem is originally from Ukraine, but since 2001 he has been living in Finland, where he ended up working for Nokia first as a Senior and Chief Engineer and lately as a Product Manager. Having over a decade of software development under the belt Artem was working for a number of Ukrainian and Finnish companies, experienced various methodologies, processes and leadership styles. He got acquainted with Agile in 2005, liked the ideas and immediately started applying them in his projects within Nokia. Artem’s main interests are Scrum in general and the ways of establishing productive communication between the customer and development sides in particular. Artem pursues both practice and theory. He was a practicing Scrum Master, now he is a Scrum Product Owner. He is doing his PhD studies on Agile Project Management and from time to time consults and coaches various organizations on the topics of effective software development. Artem also maintains and regularly writes to the AgileSoftwareDevelopment.com web site. Artem is a DZone MVB and is not an employee of DZone and has posted 3 posts at DZone. View Full User Profile

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

03.20.2009
| 3365 views |
  • submit to reddit
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.

References
Published at DZone with permission of Artem Marchenko, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)