User stories are requirements described from the business perspective
User stories are business needs, not requirements in the traditional sense. They are oriented toward the user and a business need. The big difference between a user story and other types of requirements is that a story describes a business need, not the system’s functionality. The functionality that fulfills the need is the Development Team’s job — that’s design. Expressing what a user needs is the Product Owner’s job.
Let me show you the difference with a few examples with ways to show a report. Here’s the starting point:
We have an overdraft report and want to find overdraft trends quickly.
The IEEE requirements standard:
The system shall sort the report by overdraft amount and then customer account number.
Above is many traditional requirements are written. Very black and white and oriented toward the system.
Use Case:
The user selects the report. The system displays the report. The user selects column for overdrafts. The system sorts the report by overdraft column.
In both of the above cases it’s easy to get into what the system does and how it does it rather than why the business needs something. These formats, in the wrong hands, can muddle analysis (what) and design (how) while minimizing understanding by the development team. Use cases are often confused with user stories because of the name similarity. Both are useful, but the use case is a more design oriented view, also from the user perspective.
Stories usually are written with the format:
Title: some short description
Body:
As a <role>
I want <something>
So that <some value>
Acceptance Criteria:
Verify that . . . .
Verify that . . . .
Verify that . . . .
Verify that . . . .
Here are a few examples:
An awful user story
As a user I want to sort the report so that the report is sorted.
It does follow the format doesn’t it?
The first thing to ask is what do you get out of sorted report versus a non-sorted report (and don’t say sorting). You get some way to find something or see trends. Let’s change it a to a bit more business oriented and specific.
A slightly better user story
As a user I want to sort the report so that I can find overdraft trends in customer’s accounts.
That’s better but it’s still got some problems. Sorting is specifying the system behavior and is a technical specification. There may be better ways to find trends in a report, so we should be more business oriented.
A fairly good user story
As a user I want to organize the overdraft report so that I can find overdraft trends in customer’s accounts.
That’s better. It keeps the business out of the world of technology and allows the developer to present options such as sorting, filtering, line breaks, coloration, bolding, and more.
The last issue is the term user. Should this be the same for anyone who requests the report or only certain people, like account representatives, customers, branch managers, or just about anyone. The term user will imply anyone. Let’s make it a bit more specific by specifying a certain level of system authority.
The best user story so far
As a user with authority level XYQ I want to organize the overdraft report so that I can find overdraft trends in customer’s accounts.
Of course, the product owner has to make a choice as this story is refined and prepared for a sprint, but it’s giving the development team a chance to see the why not just the what.
While many people find them useful in an agile environment, user stories aren’t going to save your bacon; they’re just a type of requirement that allows the focus to be on “why” rather than “how”. Ultimately lighter documentation and more conversation is better than precision in your written word.
User stories are great if you want to decompose the work by business need rather than functionality, which can be quite helpful in Scrum. You can certainly use other requirements formats to get the same result, it can just be easier with the story format. Following the user story with a well-written use case can be useful to identify corner cases, edge cases, and exceptions that need to be handled, but that’s a topic for another blog post.