This is the third 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 of this series here.

Today’s interviewee is Christiaan Verwijs. Christiaan is the founder of Agilistic, a company that specializes in helping small businesses and startups on their journey toward Agile software development. He has been working with Scrum for more than three years, for a variety of companies and with a diverse group of teams. He enjoys writing about his Agile adventures in his personal blog: http://www.christiaanverwijs.nl

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

The concept of a user story must be understood within the context of Agile software development. For me, a user story is mostly a vehicle to facilitate discussion and collaboration within the team. Some liken user stories to “unrealized product options,” and I like that idea. A user story is the simplest way to describe such options from the user’s point of view, “simplest” in the sense that it provides the team with just enough information to get started, test assumptions, and delivers something of value at the end of the sprint that can be reviewed. In a sense, you could describe a user story as a requirement. But it’s mostly just a “product option” that is either more or less desirable to the product owner.

How do you compare a user story with SRS?

User stories are a form of specification, but a very limited one – by design. Within the context of Agile software development, we accept that projects are subject to frequent change and mistakes (in estimation, in assumptions, etc.). Instead of spending a lot of time on writing thorough specifications, we prefer to work with the least-extensive specifications to get us started. The problem with SRS is that they are mostly a bunch of assumptions about what users want, how functionality should work, and how to technically implement it. Until you’ve built the actual software and shown it to actual users, it’s all just speculation. And if your assumptions turn out to be wrong (as they often are), you have wasted a lot of time on specification. This makes it an expensive failure. Instead, I prefer to work with a method where I can fail early and quickly. Mistakes are less costly this way. And the best way to do this is by frequently delivering and reviewing (real) working software. So instead of focusing on specifications, we focus on building working software.

This does not mean that you can’t extend user stories with more information, like acceptance criteria. For me, this is usually just a short checklist of what a user story must do. Like, “It must work in IE8,” or “The email uses the styling of [Brand X].” They can help to address nonfunctional requirements. Although I’m perfectly happy with backlogs that are not 100 percent made up of user stories. Nowhere in the Scrum Guide does it say that user stories are required or even needed. I prefer to write the acceptance criteria during sprint planning or when preparing the next sprint – just-in-time specification, in a sense. But very minimal, as I want to focus on writing working software instead of documents.

Do you think that user stories replace “SRS”?

User stories serve a different need. They are not supposed to replace SRS. They are supposed to be part of a different way to build software. Instead of a planned approach, it suits an approach based on collaborative discovery.

Which of the two do you prefer working with?

User stories. But not because of the stories themselves, but the different process they are a part of. I’m currently working on a large project with a team of six developers. We’ve completed about eight sprints now and have seen a major shift in what we’re building and how we’re building it. When we started the project, we had a lot of ideas and quite a detailed backlog (with user stories, but still). After only a few months, we’ve dropped a lot of supposed core features and replaced them with very different solutions that we discovered as we progressed. I really enjoy this approach because it fits with the discovery process and the unexpected stuff that happens in all projects. If we would’ve had to write software requirements, we would’ve spent months on that. And we would’ve still run into the same unexpected and unpredicted issues. It was a lot less painful to drop a few lightly detailed user stories than a bunch of specification documents.

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

As for regulated systems, you may need more specifications on the software that you’ve written. But I’m not sure if you really need more specifications before you start building software. After all, why would the problems that non-health-IT projects are facing – constant change, different interpretations, difficulty with estimation – not affect these kinds of projects? This software is equally vulnerable to incorrect assumptions. Maybe even more so. What you will need is to very carefully describe how the software works and what happens under what conditions. I think that this kind of specification can be in the form of documentation, but I would actually prefer batteries of exhaustive automated tests – unit, regression, etc. This way, your “documentation” stays up-to-date as tests are adjusted when bugs are fixed, new features are implemented, etc.

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

You can find the next post in this series, where I interviewed Per Lundholm, here.