“Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.”
― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product
Last Updated on: August 19, 2022
A User Story is the most effective technique to enhance product Agility. Apart from being just a list of features, it brings the user to the picture. A user story is a vital component of Agile product management which bridges user and the product.
Mike Chouhan of Mountain goat software has defined this concept with best regards in his book ” user stories applied for Agile software”. According to him;
“We make decisions according to the information we have at hand right now, and we do it often. Rather than making one all-encompassing set of decisions at the outset of a project, we spread the decision-making uniformly across the duration of the project. To do this, we make sure we have a process for the procedures that get us information as early and often as possible. And this is where user stories come into the picture.”
Table of Contents
What Are Agile User Stories?
A user story is a core component of an agile program that includes an informal explanation of the features of software from the perspective of the end users. The purpose of these stories is to make it clear how a piece of work will deliver specific value to the customer. These customers can be external end users or internal customers or colleagues.
The main features of the agile user stories are:
- They use non-technical language to provide context for the development team and their efforts.
- They include only a few sentences and are not detailed documents.
- They put the end user at the centre of conversation and explain things from his/her perspective.
- They help provide a user-focused framework for daily work, thereby driving collaboration, creativity, and a better product.
Stories form an integral part of smaller agile frameworks, like Scrum and Kanban, and bigger frameworks, like epics and initiatives.
Who writes a User Story?
An agile user story is written in the context of the product from the customer’s point of view. It is written by generally Stakeholders, Product managers and product owners. Writing a user story is mere mapping of well-configured documents in pen and paper, but who is actually participating in the discussion of bringing them into life is the real concern.
It has a detailed expression of buyers’ personas experience and how about product usage. A good user story can only be written with a good understanding of the customer’s requirements and intentions. If the customer is not present in the course of time for feedback, the team consisting of designers, techies and writers behave as customer proxy to pretend as a user on behalf of the real clients. Participant vary for various stages,
- User story creation.
- User story maintenance.
- User story application and usage.
Features of Good User Story
A good agile user story has the following features:
- Independent – Agile user stories should be independent of each other so that they can be freely moved around the product backlog with a change in the priorities.
- Negotiable – A user story should be negotiable about the implementation and its scope.
- Valuable – A good agile user story should be of value to the customer, whether internal or external.
- Estimable – The story should be estimable. One that cannot be estimated indicates that you don’t understand the scope well enough, or it is too big to be estimated. A story that is estimable helps you differentiate between valuable low effort and valuable high effort.
- Small – The effort to implement a user story should be small, at most a few weeks. Smaller stories are also easier to estimate and negotiate.
- Testable – A story should be testable, which means that the customer can collaborate with the implementing team to tell you whether you have implemented what they want.
To add to your project management skills, consider GeekLurn’s Agile Product Manager & Product Owner program. You will experience holistic learning, with 120+ hours of live online sessions, 24/7 access to the LMS portal, experience in handling real-time projects as well as period mock tests and one-on-one performance assessment to evaluate your understanding of the subject matter.
Good User Story Writing Techniques:
Prior to writing, collect initial information through a user survey.
conduct query interviews through buyers persona to know the projectile of the journey and note it down in fragments before assembling them down. put the foot keynotes on a wall or post it in a common room so that everyone can have a look and work on it.
There are few techniques curated to write effective user stories.
1.RGB structure: Role-feature-reason or benefit
As a (user/persona/customer), I want to (do something) so that I will (achieve a benefit)
Ron Jeffries curated three C approaches, to add into the RGB module.
Card- conversation-confirmation.
Card: Write the answers to the RGB module questionnaires in the card.
Conversation: Whatever is written on the card in a precise manner, it has to be elevated in detail and require a discussion. This is acquired by a conversation among the teammates.
Confirmation: the result of the above conversation results in confirmation of the resulting queries. put down all of them on the back of the card. It will be used as a future reference checklist by team members before proceeding to next steps.
2.INVEST methodology:
I- Independence
N- Negotiate
V-Value
E-Estimated
S-Small
T-Tested
This acronym was coined in an article by Bill Wake in 2003. It is a method to evaluate user stories in consecutive steps and efforts.
- Independence to create a sequence
- Capability to negotiate to which extent a story can be developed
- facilitating Value to the business
- can be Estimated for completion
- It is feasible and Small enough to design, code and test in a one iteration
- and can be finally subjected and Tested.
Benefits of writing a great user story:
At some point of time, user stories may become a cumbersome task for product managers and product developers than a shortcut requirement list. but writing a user story keeps everyone involved as it is cooperation dependent and involves active involvement of all the team members at once. Do you know what happens by that?
it keeps everybody on the same page when it comes to following procedures and adapt to any changes henceforth on every step.
Some of the acquired benefits involve:
- Since it breaks down a bigger picture into smaller fragments, it accelerates the progression and make it happen more quickly
- facilitate smooth moving and quick succession of happenings among team members
- Put the customer ie the end-user at first priority which avails greater user experience
- Foster creative planning and collaborative group work for better productivity.
Hands-On Tips to Create a Good User Story
Agile User Stories let you define what benefits your product will bring to the customers or internal and external end users. User story writing techniques involve keeping the below mentioned things in mind:
- Definition of Done – A user story is done when the users can complete the task outlined in it. Ensure that the task is defined in the story.
- Outline subtasks – The story should outline the specific steps that need to be completed and by whom. The responsibility of completing each task should be outlined clearly.
- Define Users – Specify the end users.
- Ordered Steps – Write a story for each step in a larger process.
- Listen to Feedback – Talk to your users and identify their needs before writing a story.
- Time – The story should be completable in one sprint. If they are bigger and may take weeks or months to complete, it is better to break them up into smaller stories.
What are User Story Acceptance Criteria?
User stories aim to describe what exactly the end users want the system to do, and the user story acceptance criteria refer to the conditions that a specific user story must satisfy. The acceptance criteria for each user story are different and define the feature behaviour from the perspective of the end user. Well-written acceptance criteria ensure that users and all the stakeholders are satisfied with the user story.
The acceptance criteria for a user story needs to be defined before the development story starts working on it. Otherwise, the deliverables may not meet the needs and expectations of the client. The main purposes of user story acceptance criteria are:
- Making the Feature Scope More Detailed – Acceptance criteria define the boundaries of user stories by providing precise details on functionality.
- Describing Negative Scenarios – The acceptance criteria must define negative scenarios, like unsafe password inputs, besides explaining how the system must react to them.
- Setting Communication – The acceptance criteria must synchronise the vision of the clients and the development team. Developers should know what kind of behaviour the feature must demonstrate, and the stakeholders should understand what’s expected from the future.
- Streamlining Acceptance Testing – The acceptance criteria are the basis of the acceptance testing of a user story. Each acceptance criteria must be testable and have a clear pass or fail scenario. The criteria can also be used to verify the user story via automated tests.
- Conducting feature evaluations – The acceptance criteria must specify what exactly must be developed by the team. The precise requirements can help in splitting the user stories into correctly estimable tasks.
Written acceptance criteria help in creating a unified vision of how the functionality should be implemented. The acceptance criteria can be written in the following formats, depending on the initial task and the complexity of the requirements:
- Scenario-oriented by using the Given/When/Then template
- Rule-oriented by using the checklist template
- Custom formats
The acceptance criteria are defined and written by the product owner at the time of the creation of the product backlog. Some other criteria can be specified by the team at the time of user story discussions after sprint planning. The criteria can also be documented by a client who has ample technical and product documentation knowledge, but after negotiation with the team.
3Cs of User Story
The three critical aspects of working with and developing software starting with user stories are:
- Card – The stories are written on cards that can be used for prioritising, estimating, and scheduling.
- Conversation – Conversations, open discussions between the customers and the ones involved in implementing the story help in identifying specific requirements, besides providing greater clarity for implementation.
- Confirmation – The confirmation is done by acceptance tests that convey whether the acceptance criteria are met by the software. The acceptance criteria are outlined after the conversation.
User Story Template and Examples
User stories are short and simple descriptions of features told from the perspective of the end-user or the customer of the system. User stories are generally structured as:
“As a [persona], I [want to], [so that].”
The three components are:
- As a persona – refers to the person for whom we are building this.
- Wants to – refers to the user goal or what are they trying to achieve.
- So That – refers to the overall benefit that they are trying to achieve or what is the problem that needs solving?
Some agile user story examples:
- As an employee, I want to organise my work, to have more control.
- As a team member, I want to invite my colleagues, so we can enjoy this service together.
- As a team leader, I want to understand the progress of my team, so that I can report our success and failure.
FAQs
To put it succinctly, features are made up of user stories while user stories describe the ‘why’ of a feature. Features can be defined as the characteristics of a product or a service. It separates one version of a product from another. A user story, on the other hand, helps to create a simple description of a requirement. A user story is written from the user’s perspective & brings out what the user hopes to achieve & why.
The key difference between the two lies in the objective. The user story focuses on the experience, on what the person wants to be able to do with the product. A requirement on the other hand focuses on functionality, on what the product should do. Based on this key differentiator, the two also differ in terms of how they are written, who writes them, when they are written, and more.
Agile user stories can be written by anyone who is close to the software- it could be a developer or a QA tester. While anyone can write the user story, it is the product manager or the owner who maintains the backlog of user stories.
Monica Swain
Monica is a senior marketing executive. Her skillsets consist of digital marketing and strategy, SEO, marketing analysis and more. She also has her expertise in writing various copies, including web, newsletters, e-books, social media, etc. But, it does not stop here. Her love for writing goes as far as doing poetry connecting science and life.
