The answer here is unfortunately...maybe.
It depends upon your organisation and the kind of development you are working in.
In our department we have Business Requirement Specifications in addition to the Product Backlog.
The reason for this is two-fold
- We have multiple projects coming into the same Scrum Team
- We have large scale dependencies that we require to be completed by other departments prior to the Scrum Team beginning their work. Since they require a BRS and we input into it it makes sense for us to help write the BRS and make sure our Backlog is reflective.
For instance, our department handle Front End Business Warehouse and Business Objects Development and the Product Owner can speak on behalf of the Business.
However the SAP R/3 architects (separate) require detailed specifications regarding the Business Warehouse back end preparatory work. Therefore the Business Requirements Specification are produced although we have a more complex Product Backlog which we can draw upon for Task-Level Sprint Planning.
I would argue that you absolutely should have a detailed requirements document if any of the following are true
- The Scrum Team are upstream or downstream of another non-Agile team producing the same product or a derivative of that product
- The Scrum Team / PO must anticipate the business needs of multiple projects, work streams or backlogs
- Non-Traditional Scrum processes are diluting the Scrum Framework due to business constraints
- The Product Backlog is highly technical or a complex project and resistant to User Story Breakdown EG SAP Master Data with 1000+ stakeholders across global landscape. There is very few ways of getting around the need for a large document detailing the exact scope, out of scope and risk management of this piece of work.
The truth is most Scrum examples always use the simplest possible explanation without considering the tailored work environment.
Not every Backlog can be
As a Customer of Amazon I want to be able to put items in a basket for future checkout.
The Benefits of Scrum for our team are that we can respond exceptionally quickly to project changes, we can filter and work on multiple projects at once as a merged backlog, our capacity planning and sprint cycle provide more realistic planning timelines (they get an iteration time box and they can get some work done in that box, if the work exceeds the box, ask for another box) and most importantly we can foster innovation and cross-functional development.