This is the second post in the series in which I have interviewed several Agile experts in order 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 of this series here.

Today’s interviewee is Johanna Rothman, known as the “Pragmatic Manager.” Johanna provides frank advice for your tough problems. She helps leaders see problems, seize opportunities, and remove impediments. Johanna is working on a book about Agile program management. Johanna writes columns for StickyMinds and ProjectManagement.com, writes two blogs on her jrothman.com website, and blogs on createadaptablelife.com.

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

No. User stories are often very different from an SRS.

A user story is a single scenario. An SRS is often a collection of requirements. You might have user stories in an SRS, but why would you? You rank each story in a backlog, and as you proceed, you get feedback on the story as you complete it.

In an SRS, you attempt to create all the requirements, often as functional/non-functional requirements.

The problem is that customers want features, stories. They don’t want functional or non-functional requirements. You need to explain these requirements in stories.

How do you compare a user story” with SRS?

An SRS is often written in the passive voice (like I just did). It’s often too long. It’s difficult to see the value, or the ranking of the requirements. If people rank the requirements, they often use buckets, as in “must,” “could,” “would,” or something like that. When we write user stories, we talk about a specific user, so we write the story in an active voice. We see the value. We can compare the value of one story against the other.

Do you think that user stories replace SRS?

For me, they do. Why wouldn’t they?

As you complete a story, you get feedback. With that feedback, you can decide which story to do next. You can change.

What I see most often is that product managers/product owners don’t require everything they think they do in an SRS if they use user stories and rank them.

Which of the two do you prefer working with?

I prefer user stories, even if I’m not using Agile. That way, I always see the value and the actor in the requirements. I can easily rank the requirements.

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

User stories. They explain who the requirement is for, and the story around each requirement, in addition to acceptance criteria.

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

You can see the next post in this series, where I interviewed Christiaan Verwijs, here.