The hardest thing to do in software is not coding – it is designing the system! And we are NOT talking about graphic design…we are talking about architecture, data modeling, customer requirements, etc. Some of those things are harder than others, but doing a list of requirements is probably one of the trickiest arts.
What is a Feature? It is a functionality that the application has! For example: sign-up, sign-in, vote, buy, etc.
Describing a feature seems easy, but it can be challenging: Where should you start? How detailed should it be? How technical can you be? But, don’t worry…"user stories" have come to the rescue!
User stories have become very popular as a feature-based-documentation-standard because they cut all the fat from the process. The are straightforward, easy to understand by everyone involved (not just the developers), and easy to test.
A user story is like having a conversation with your future user. They must be written in standard non-technical English for 12 year old kids with a low attention span:
13#### Here are some Examples:
It is so simple that it becomes tricky…the most important thing is to: (1) Maintain simplistic language, (2) Keep it short, and, (3) Specify:
As a [role], I can [feature] so that [reason]
Let’s look at another example:
As an "account owner", I can "check my balance online" so that "I can keep a daily balance 24 hours a day."
Pretty easy right? However, in some instances we find that the "so that" suffix reads redundantly, so go ahead and make that optional, if you wish.
As an "account owner", I can "check my balance online".
Feel free to use slight deviations of this template using synonyms:
There are millions of tools; we have Googled some: click here to access. Some are free, and some cost money, but throughout the years we have decided to do them ourselves using index cards. If you insist on using something digital, you should use this document template that we have prepared for you.
The theory is simple – if you use any larger than a 3" x 5" index card, you will write too much. Likewise, if you use anything smaller than a marker (such as a ball point pen) – you will write too much.
User stories are suppose to be short and sweet. They are suppose to aid in further communication and not tell the entire long-winded version of the story. Sticking to these physical constraints will help.
At the end you will have a huge "to-do list," with the stories moving from "To-do" to "Doing" and, finally, to "Done." Each story will be assigned to one developer at the beginning of each planning meeting.
If stories are short and sweet – how are we suppose to know all the different acceptance criteria? On the back of each story we will have to enter some "acceptance criteria" that we can check at the end when the developer thinks the feature is done.
To write great acceptance criteria, we need to think not only about the usual expected behavior in the application, but also about any cases where the app should fail (for example: When you specify a wrong password, when your credit card is rejected, etc.).
User Story: "As a music lover I want to be able to pay for my album with my VISA card"
Examples of Acceptance Criteria (specific for this story):
Please, this is a course about full-stack web development. You don’t have to write the best stories ever made. Perfect does not ship! Take some time to think about your stories, but don’t get stuck during the process.
You will be using user stories a lot, but, as a developer, it is not your responsibility to write them. There are people certified for that (Requirement Analysts). Your job is to read them and follow them.