Getting started with user stories
Everyone is talking about user stories, and planning to write their own. What are user stories? How we can benefit from them? OK let’s have a look …
What is a user story?
A user story is a tool to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
In simple words it’s user’s story on achieving their goals. So that everyone understand WHO wants WHAT and WHY.
So before going into user stories clearly identifying your users/personas is a must. A persona is a single representation of a subset of your target audience who have similar behaviors, goals, motivations and needs when it comes to your product. To get a better idea on personas, I recommend you to read these articles first Introduction to User Personas and DIY User Personas.
Why user stories?
In traditional Detail Software Requirement Specification (DSRS) requirements are written in product perspective. Requirements describe functionality in system activity. The typical scenario is that one or more analysts spends two or three months (often longer) writing a lengthy requirements document. Then it’s passed to client for approval, client skim the large document and approves it. Then it is passed to developers to start working on. Developers individually study it and builds what they understand. At the end all parts are integrated and put for user acceptance testing, where client find’s that it’s not what he thought of and essential business processors are missing. These type of disappointments happens mainly because of lack of direct communication.
♣ User stories describe functionality in terms of outcome. By focusing on the user’s goals for the product, rather than a list of attributes of the product, we can design a better solution to the user’s needs.
♣ User stories emphasize verbal communication. A user story is not a specification, but an communication and collaboration tool.
♣ User stories are usually written by stakeholders who are expertise in the domain. It’s better if stories can be written collaboratively and discussed together.
How to write one?
User stories is all about effectively communicating business problems to all the stakeholders. It doesn't necessarily needs to be 100% accurate overnight, it can be change and evolve over time. Most important is to base a user story and build a discussion around it, so that all the doubts are clear as early as possible.
Ideally it’s user/client who is expertise in the domain, writes the user stories. But the best way to write user stories is to have a workshop with all the stakeholders (Users,Developers,QA,Project Managers,System Administrators,UX,etc.). User explains his goals to stakeholders discuss and write the stories collaboratively. In a second round user stories are discussed deeply covering all the aspects.
Let’s look in to a user story format and what points that we need to discuss, when we write one.
As a <user type> I want to <goal> So that <benefit>
01. Describe who wants the feature (Personas)
● What do they do day to day?
● What is their level of comfort with technology?
● What goals are they trying to accomplish?
● What are the daily pains they deal with?
Once you really understand your users, It’s easy to personalize and provide a better experience.
02. Describe what they want
There is no story without a goal. Start by outlining the goals of the users in the system.
Remember, user stories describe functionality in terms of the outcome, or the goal of the user. Once you understand what the user is trying to achieve, it makes it much easier to create a good user story.
03. Describe why they want it
● It helps us understand the value associated with the functionality
● It gives us the opportunity to explore other ways of reaching that goal
04. Create acceptance criteria
Acceptance criteria are statements of requirements that are described from the point of view of the user to determine when a story is “done” and working as expected.
05. Engage in conversation to fill in the details
User story along will count only less, discussion on user story among the team is the most important thing.
Few points to keep in mind
● Identify your personas
● There is no story without a goal. Start by outlining the goals of the users in the system.
● Include metadata or other artifacts with the user story — Whatever you think will help with the communication process, you can attach to the user story. Say you are writing a highly technical user story and a particular diagram will come in handy to understated it. You can attached the diagram to user story and use it in the conversation later on.
● Involve the customer in writing the stories.
● Keep the stories short, remember, they’re just reminders to have the conversation.
For more information on user stories please read User Stories Applied, by Mike Cohn
