SRS in scrum framework?

Question

IN scrum , everything is written in terms of user , They are called user stories. For starting new projects in scrum , should one write SRS document ? Or just go directly for user stories . I did not find any relevant source that points SRS in scrum environment ? Am I missing something ?

Answer 1

In the Agile Manifesto, you should prefer working software over comprehensive documentation. If you need an SRS document, there is nothing preventing or discouraging it, but you should give it serious consideration before going through the trouble. Just make sure the creating of the documentation is not at the expense of creating working software. It's not a matter of exclusion or maybe even priority (some industries find these documents to be absolutely required) just keep the end result in mind.

You could also see this as possibly modifying the amount of detail in the documentation or maybe don't write the entire document first, but do it as you go along, so you're not having to make constant changes. It would be a shame to not include changes in your project because an overly robust document becomes too difficult to change or worse no one has noticed that it hasn't.

Answer 2

If you following Agile, User Stories are enough. Agile projects will capture requirements in the form of user stories, scenarios, or other user-centric forms. The best approach will be - decide your components and split them into epics. Then, you can add user stories under epics. No need to create additional SRS. If you need to, and if you are using JIRA for Agile, use 'Confluence' with JIRA. You can create SRS in Confluence and later can split into user stories directly from Confluence. Also, you need to keep the document as a living document.

Answer 3

Even if the newer ISO/IEC/IEEE 29148:2011 defines requirement management processes that can be iterative, and explicitly mentions user stories as a mean to describe the requirements, I'd advise against the use of an SRS in an agile context.

Indeed, SRS are an old biest that emerged in 1983 in a time where big up-front analysis was still the norm. Using the terminology "SRS" might then easily mislead into bad practices.

Agile requires a dynamic approach to requirements, welcoming change and preferring interactions. Any SRS (Software Requirement Specification) tends to become less welcoming changes ("oh, a change ? New version of the SRS and the paperwork, do we really need this? why not stick to the plan? ...").

Take the best part of the SRS: the purpose of the software, an overview of the software product we'd like to have. Refer in this document to your backlog management tool (Jira or whatever), eventually mentioning the top epics to be considered. Keep it as short as possible for team member onboarding. Call this a "product vision document" rather than SRS. Maybe add a high level roadmap to manage expectations of your stakeholders.