As mentioned in our post The Difference between User Stories and Software Requirements Specification (SRS), we decided to interview some Agile experts on this topic in order to reveal some confusion that may be occurring in the industry. This will be a series of interviews, with one interview presented in each blog post.

The interviewee that we present now is Ron Jeffries, one of the 17 authors and signatories of the Agile Manifesto. He was the onsite XP coach for the original Extreme Programming project in 1996. He is the proprietor of http://ronjeffries.com and senior author of Extreme Programming Installed – the second XP book after Beck’s white book – and the author of Extreme Programming Adventures in C#.

Ron is a frequent speaker and trainer at Agile software-development conferences, including attending and speaking at all of conferences in the United States and some in Europe. He is a well-known independent consultant in XP and Agile methods.

Thus, I saw that Ron would be a great fit for the topic we are investigating. Without further ado, let us go ahead and see what Ron Jeffries had to tell us:

Do you think that “user story” is just a fancy name for SRS?

No, they are quite different. User stories are small descriptions of single features, usually the smaller the better. SRS has no standard definition that I’m aware of, but generally refers to the set of all requirements, not to a single one. Even a single requirement spec is usually much much larger than a story.

How do you compare a user story with SRS?

I wouldn’t. I don’t see the need to do so. You may see a need, of course.

Do you think that user stories replace SRS?

Certainly, products large and small can be and have been built without doing anything I’d call SRS. So the answer is clearly yes – user stories can replace SRS.

Which of the two do you prefer working with?

Stories. They are small, simple, and easy to use. Because they are focused more on conversation than on writing, they are far more collaborative. According to my explanation of stories, they explicitly include acceptance criteria and are also concrete enough for any purpose. Search for “Card, Conversation, Confirmation” for more on that thought.

Which of the two methods do you recommend using for regulated systems (i.e., health IT systems, medical device software)?

I would use stories for everything at the team level. There might be some higher-level SRS that is parsed out into stories. There is some good work being done with regulated systems and every reason to believe that a lot of the mechanism that big organizations have built up could be trimmed down a lot. This might be seen as more of a job for Lean than for Agile.

Do you agree with Ron Jeffries? Comments and discussion are welcome.

The next post in this series where I interviewed Johanna Rothman can be found here.