How to work on Requirements in Scrum

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! 



 

In Scrum, requirements are gathered collaboratively through interactions between the Product Owner, development team, and stakeholders. Rather than gathering all requirements upfront as in Waterfall, Scrum focuses on iterative and incremental development, where user stories are written based on prioritized requirements and refined throughout the project. This approach allows for flexibility and adaptability to changing needs and priorities.

I'd rather think of requirements and lightweight desires of a Product Backlog. The first thing that needs to be in place is a Product Goal, defined by a Product Owner. From there the Product Backlog emerges in the form of desires and ideas expressed as Product Backlog items. As more is learned through an empirical lens, the Product Backlog changes. 

User stories might be a way to describe a Product Backlog item but not the way.