In this post I’m going to show you why User Stories are a better solution than Requirements Specifications to effectively understand user needs and build successful products.
Introduction
Software requirements is a communication problem.
How do you decide what a software system is supposed to do?
How do you communicate that decision between the various people affected?
Experience has taught us that Requirements Specifications do not work anymore in today’s world and that User Stories are a much better solution.
I’m going to explain you why in this post…
What are Requirements Specifications?
A typical Requirements Specifications fragment is the following:
There is a tremendous appeal to the idea that we can think about a system and then write all the requirements upfront.
Requirements Specifications written like that have sent many projects astray because they focus attention on a checklist of requirements rather than user goals.
What Is a User Story?
A user story describes functionality that will be valuable to either a user (who uses the system) or customer (who pays for the system).
The format of a User Story is the following
As a <Role> I want <Function> so that <Benefit>
as in the example below
As an executive, I want to generate a report so that I can understand which departments need to improve their productivity
Our goal with user stories is to write down a short place holding sentence that will remind developers and customers to hold future conversations.
Why User Stories are better?
1. Comprehension
A way that extensive upfront Requirements Specifications can kill a project is through the inaccuracies of written language.
The shift toward verbal communication of User Stories provides rapid feedback cycles, which leads to greater understanding.
2. Planning
A difference between User Stories and Requirements Specifications is that with the latter the cost of each requirement is not made visible until all the requirements are written down.
With stories, an estimate is associated with each one right up front so that they may be conveniently used for release planning.
3. Resiliency
Change always happens in projects…
- Users and customers do not generally know exactly what they want
- Many of the details needed to develop the software become clear only as the system is being developed
- Product and project changes occur
- People make mistakes
User Stories embrace change because
- Do not need to be all written before developers can begin coding the first
- Encourage deferring details because we can write them at whatever level of detail is appropriate in a given moment.
4. Prioritization
It’s hard to prioritize and work with thousands of sentences all starting with “The system shall…”.
That difficulty usually results in having the user considering 95% of the requirements high priority!
On the opposite, User Stories can be easily ordered by priority.
a journey into software best practices with maria grazia merlo 