“My team is using a Scrum framework. Do I have to write requirements as user stories?”
Scrum teams work from a Product Backlog – a prioritized list of functionality for the product. The Backlog is comprised of Product Backlog Items (PBIs) – individual work items which deliver value. While PBIs can be anything the team desires, user stories have emerged as the most common form.
Why User Stories Became So Popular
1. Better Convey Business Value
In Scrum, requirements should be value-oriented, not solution-oriented. We are more concerned with WHY we should do it than HOW to do it. User Stories give a clear framework to accomplish this by specifying the Role and Business Value in addition to the desired feature. User Stories follow some variation of a specific pattern, such as:
As a <role>
I want <feature>
So that <achieve some goal>
-or-
In order to <achieve some goal>
As a <role>
I want <feature>
2. Light-weight Documentation
In Agile, we focus on light-weight documentation. User stories act as a representation of valued functionality. It serves as a conversation starter to determine what additional information is needed as opposed to providing detailed (and often unnecessary) documentation up front.
For example, when shopping for a new place to live, you create a short list of required features. You talk with your agent about these features. Based on that conversation and on home tours, you may change your list by adding new features or removing ones you no longer see as important.
So Do You Need to Write User Stories?
Your product backlog items should represent value and communicate needs to the team. It can include wireframes, process maps, user stories, etc. You don’t need to write user stories, but you are in good company if you do.