Ytdyklly

We are implementing scrum in our company. The problem we faced is our traditional thinking, which always requires physical document.

Management is constantly asking for documents like Business Requirements Specification (BRS) and Software Requirements Specification(SRS).

When moving towards agile, is it ok writing user stories and their acceptance criteria as an alternative of (BRS and SRS) in a single document?

If that's the case, can you supply me with templates or examples? Is there something like an ISO standard related to Agile documentation?

We use TFS for project management.

In the manifesto for Agile software development one can read:

Working software over comprehensive documentation

This doesn't mean documentation is a bad thing. Instead, working code is better so you can document what you are going to code.

That being said, user stories and acceptance criteria might be all you need to understand the requirements, considering you're not responsible for the Vision and Scope Document.

I encourage people not to think of user stories (or backlog items of any kind) as another form of requirements. There is a critical difference in thinking between the use of requirements documents and backlogs that teams and organizations need to understand in order to effectively use the latter. Backlogs are emergent. This means that they not only change over time (there's nothing stopping a BRS from changing) but that later backlog items build on and modify earlier items such that it is possible that the earlier items no longer describe the application's behavior.

This means that the documentation you require will largely be separate from your requirements (think of it as what you walked into development knowing vs what you did in development). Note that things like ISO 9001 is mostly about validating that you follow your processes (whatever those happen to be) and that you record information you will need to audit or maintain the software later. The days where documentation and audit standards were about making sure the result matched the original idea perfectly are largely gone. The only place I see that anymore is places where they have it written into their processes and don't want to change the documented processes, in which case it's a conscious choice, not a constraint.

Adding this section to respond to the comment:

Agile and Scrum can be confusing to adopt because there are a lot of good practices that people have come up with that have been lumped into Agile and Scrum, while at the same time, many of the core practices and principles get left out.

Agile: Agile is just values statements and principles. You can find them at https://agilemanifesto.org/. You can't really practice Agile - rather, your practices can be more or less Agile (as an adjective) depending on how well aligned they are with these values and principles.

Scrum: You can follow Scrum practices. Scrum is a lightweight framework, meaning it gives a number of events, artifacts, roles, and practices, but there's a lot of space to fill in how you do the work and what that work looks like. You can find the latest version of the Scrum Guides at https://www.scrumguides.org/scrum-guide.html. It is probably worth noting that if many teams pick and choose what to follow out of Scrum. While that isn't inherently wrong, it is designed to work as a whole and many benefits are lost when you start dropping practices.

XP: You didn't mention this, but a lot of practices common in Scrum that aren't specifically listed in the Scrum Guide (like User Stories) are actually from XP. XP is a lot more prescriptive on how to do the work. There's a pretty big change curve with adopting XP and I don't see many teams do it, but when Scrum started, they were often assuming that XP was going to fill some of the how-to space in their framework, so it's always worth looking at. http://www.extremeprogramming.org/ is a good place to start, if a bit clunky.