This is the fourth post in the series in which I have interviewed several Agile experts to reveal the differences between user stories and software requirements and their application to regulated systems (i.e., health IT systems). You can find the previous post in this series here.

Today’s interviewee is Per Lundholm, a professional developer since 1980. He has been a member of Crisp since 2007. Per helps clients become agile both as coders and as coaches. He also enjoys learning new things, and he blogs both textually and in video.

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

No. It is a completely different thing.

How do you compare a user story with SRS?

A story is a hook for discussion and planning, while a specification leaves no room for discussion.

Do you think that user stories replace SRS?

In a sense they do, since requirement specifications as an idea is dead. Regulations still exist, of course, but that is a different thing.

Which of the two do you prefer working with?

I wouldn’t call them methods, but I see what you mean. User stories are by far the most productive way.

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

User stories, and speaking from experience. Regulations are a fact of life like many other things. You just need to adhere to them, or your stories will not be accepted as done. The definition of “done” becomes more complicated, and you may need to have more steps in the life cycle of a user story. User stories put focus on what brings value to the user and things that we can affect, putting things that we can’t affect in the background.

Do you agree with Per? Comments and discussion are welcome.