User Story
As mentioned above, User stories are short, simple descriptions of the desired functionality told from perspective of the user and always be written in the format: As a Type of User, I Want to do something, So that why do I want it.
Unlike the traditional requirement capturing, User Story focuses on what the user needs instead of what the system should deliver. This leaves room for further discussion of solutions and the result of a system that can really fit into the customers' business workflow, solving their operational problems and most importantly adding value to the organization.
User stories aren’t just single sentence affairs, they are not complete without Acceptance Criteria. The acceptance criteria, which define the boundaries of a user story, are used to confirm when a story is completed and working as intended. For example, if this is your user story: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:
- A user cannot submit a form without completing all the mandatory fields.
- Information from the form is stored in the registrations database.
- Protection against spam is working.
- Payment can be made via credit card.
- An acknowledgment email is sent to the user after submitting the form.
Writing the acceptance criteria is the first step of fleshing out the details of your user story.
User stories cover features, functions, enhancements, and epics. a large user story has been refined to an appropriate level of detail with estimates and acceptance criteria so that they can be worked on in a near-term sprint. As we get closer to working on a larger PBI, such as an epic, we will break that story down into a collection of smaller, sprint-ready stories during the backlog grooming. Typical guidance is that a user story can be completed in 2 days or less, while some experts say the work of the team on a story may last up to a week.
How is detail added to user stories?
Detail can be added to user stories in two ways:
- By splitting a user story into multiple, smaller user stories.
- By adding “conditions of satisfaction.”
When a relatively large story is split into multiple, smaller agile user stories, it is natural to assume that detail has been added. After all, more has been written.
The conditions of satisfaction is simply a high-level acceptance test that will be true after the agile user story is complete. Consider the following as another agile user story example:
As a vice president of marketing, I want to select a holiday season to be used when reviewing the performance of past advertising campaigns so that I can identify profitable ones.
Detail could be added to that user story example by adding the following conditions of satisfaction:
- Make sure it works with major retail holidays: Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.
- Support holidays that span two calendar years (none span three).
- Holiday seasons can be set from one holiday to the next (such as Thanksgiving to Christmas).
- Holiday seasons can be set to be a number of days prior to the holiday.
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. Over the course of a good agile project, you should expect to have user story examples written by each team member.
Also, note that who writes a user story is far less important than who is involved in the discussions of it.
When are user stories written?
User stories are written throughout the agile project. Usually a story-writing workshop is held near the start of the agile 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.
Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone.
Do user stories replace a requirements document?
Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items.
While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur.
It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.