How to work on Requirements in Scrum
I am a Business Analyst and relatively new to the Scrum framework. Would like to know how requirements are gathered in Scrum as opposed to Waterfall methodology on a project. Are all requirements gathered and then user stories are written?
Scrum is a way to incrementally deliver value. In Waterfall, you define a body of work that will be delivered at the end of the project, usually months away. In Scrum you define something that will be delivered in increments and the requirements will change as each increment is delivered and reviewed by the stakeholders.
Some requirements are gathered and some Product Backlog Items are composed. Then using empirical practices, requirements are refined, some new requirements are found, Some requirements are found to be unneeded, some work is done. Repeat that cycle until the Product is no longer viable or needed.
User stories are not mentioned in the Scrum Guide. The Scrum Guide only mentions "Product Backlog Items". How those are captured is entirely up to the organization.
Also remember that the Product Backlog is not just new features. It is all changes needed to improve the Product. That includes work such as technical debt. So as part of your requirements gathering make sure to talk to the Developers and identify that type of requirement. Ignoring technical debt can lead to difficulty in implementing new features, enhancements and can even cause the product to fail.
Would like to know how requirements are gathered in Scrum
I'm not convinced that they are. The requirements of a complex product are not gathered like fruit from a tree. It might be better to say that hypotheses are framed and then tested. That's how a team figures out the right thing to build.
Are all requirements gathered and then user stories are written?
Think of it the other way around. Should user stories be employed, they ought to enable conversations from which potential requirements can then emerge.
Thanks for your feedback, Daniel and Ian!