User story is a short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. There are different recommendations how to define User stories. A template could be as follows :
As an [actor], I want [action] so that [business value / achievement]
He/she is the 'owner' of the user story. This is often a user but it is recommended to be more specific here. By using specific actors (e.g. "Administrator", "Logged in Customer", "Unauthenticated visitor") it’s easier to understand and sets the user story into context.
Actual requirement of the actor in terms of feature.
Achievement specifies the Business value of action. This is the result from executing the action seen from the actor’s point of view. User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
User story writing
User stories allow you to say why the features you’re proposing to build makes sense. A user story answers 3 important questions:
1. Who are you building this for?
2. What are you building?
3. Why are you building this?
Example 1 : As a user, I want to filter items by item type so that I can see how my team’s time is being used between features and bugs on a weekly basis.
Example 2 : As a user, I want to filter items by item type so that I can create a report on everything we did this month for my boss.
Notice how changing one component of a user story would change your approach entirely? In the first case, you would probably display this information in a chart or graph for a simple breakdown of your team’s time. In the second example, you would likely create a function to export the data so it can be shared and presented.
With user stories, everyone in your team knows exactly “who,” “what,” and “why” they are building features. Each component adds a necessary layer of context to give your team a proper start. A user story immediately directs the focus to a specific circumstance which provokes further discussion and careful revision. The end result is that your team becomes more focused on delivering solutions to user problems as opposed to merely delivering functional code.
Why should I.N.V.E.S.T. be used to write good stories?
The I.N.V.E.S.T. guideline to writing user stories is almost universally accepted as the standard to work by. The acronym was made popular by Bill Wake’s original article from 2003. Our interpretation:
You should be able to prioritize and rearrange user stories in any way with no overlap or confusion.
As previously discussed, a good user story can be reworked or modified to best suit the business. User stories are not an explicit set of tasks.
User stories need to be valuable. By this, we mean valuable for the business or the customer. If it’s not, why would you have your team work on it?
A good user story can be estimated. It’s also important to differentiate time estimations from an exact timeframe. A rough estimate is beneficial to allow teams to rank and schedule their priorities.
We definitely recommend keeping your user stories small. While we don’t suggest an exact timeframe to stay in, writing user stories that focus on smaller tasks allows for greater focus. The larger a story is, the harder it is to estimate and easier it is to get caught up in sub items that should have probably been their own stories.
Before a user story is written, it is essential that a criteria to test it is in place. Outlining the testability first ensures that the story actually accomplishes the goal you are trying to achieve. A story is not finished until it is tested. For maximum productivity and team alignment, make sure your team knows how their work will be tested.
Benefits of writing user stories
Helps to express the business value.
Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution.
Avoid the appearance of false completeness and clarity.
Get to small enough chunks that invite negotiation and movement in the backlog.
Stories are comprehensible.
Developers and customers understand them.
People are better able to remember events if they are organized into stories.
They support and encourage iterative development.
They can be easily started as epics and later disaggregated at the development time.
Stories support opportunistic development.
Stories support participatory design.
Stories put the focus on the user’s goals