Agile User Stories | Effective Ways To Write
5 min readAug 23, 2018
What Are Agile User Stories?
- User stories are 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.
- In Agile methodology ‘User Story’ is a unit of work that should be completed in one sprint.
- If you don’t know who the users and customers are and why they would want to use the product, then you should NOT write any user stories.
User Story Template and Examples
They typically follow a simple template:
Few More Examples:* As a user I can create an account* As a user I can login to my account* As a user I can search for a doctor by specialty* As a user I can search for a doctor by zip-code* As a user I can search for a doctor by insurance provider* As a user I can book an appointment* As s user I can modify an appointment* As as user I can cancel an appointment* As a user I can reset my password
Who Writes User Stories?
- Anyone can write user stories. It’s the product owner’s responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them.
- The product owner and the team should discuss the stories together. This allows you to capture only the minimum amount of information, reduce overhead, and accelerate delivery.
- Over the course of a good agile project, you should expect to have user story examples written by each team member.
When Are User Stories Written?
User stories are written throughout the project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project or a three- to six-month release cycle within it.
Use Personas To Discover The Right Stories
The first step towards writing the right user stories is to understand your target users and customers. Personas offer a great way to capture the users and the customers with their needs.
- Start with your primary persona and capture the functionality as epics (An epic is a big, sketchy, coarse-grained story.). Write all the epics necessary to meet the persona goals but keep them rough and sketchy at this stage.
- Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. The story should not be too big and comfortably fit into a sprint; and there has to be an effective way to determine if the story is done.
What Additional Can Be Added?
- As you break epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story, they make it testable, and they ensures that the story can be demoed or released to the users and other stakeholders. As a rule of thumb, I like to use three to five acceptance criteria for detailed stories.
- Well-formed stories will meet the criteria of Bill Wake’s INVEST acronym:
Well-prepared Definition of Done (DOD) can make easier and speed up the daily work of a software development team. Precisely defined criteria of verifying the work was done, allow to avoid many conflicts arising from misunderstandings between team members and delays which may occur because of that.
- The most common use of DoD is on the delivery team level. Done on this level means the Product Owner reviewed and accepted the user story. Once accepted, the “done” user story will contribute to the team velocity. (Sample DOD is mentioned in Image)
Characteristics Of A User Story
- A story should be complete and big enough to provide a user with some value. The user story should be user-centric, normally people write user story which is too much centric around component or system aspect, when writing a user story, we should focus on what the user is doing or getting out of the story.
- The goal is that when the user story is done, the user can do something of value to them.
- Group user stories which offer a feature in the same domain, or its good to group a certain feature or use case into a single Epic or even multiple Epics. Ideally you’ll break up your features in a way that you can launch into production parts of the feature independently from the whole, but its not always possible.
User Story : Key Take Away/ Facts
- User Stories are not detailed narratives.
- User Stories don’t need to tell the development team how the feature works.
- User stories don’t need to come from users.
- User stories aren’t the final word in development.
- User stories aren’t one size fits all.
- User stories don’t need to be independent.
- User stories don’t need to include obvious details.
- Everything in your product backlog doesn’t have to be a user story.
- User stories are not always from an end-user.
- User stories are not a mandated part of Scrum.
- You don’t have to follow a specific user story format.
- There are no real rules for writing user stories.
- User stories are not always shared with customers.
