In this article, you will learn about User Stories, 3 C’s of a user story, who writes it, how to write it, how to INVEST in user stories, different types of user stories with examples and acceptance criteria.
Also, read more about Power BI Developer Future.
What is a User Story?
We usually write the story on physical index cards or digitally using project management tools. They are used to capture and communicate requirements in a simple, human-readable format. User stories serve as placeholders for ongoing conversations between development teams and stakeholders, fostering collaboration and flexibility in adapting to changing priorities or user needs.
During Agile development, we incorporate the user stories as part of the product backlog, and they are prioritized and pulled into development sprints based on their importance and value to the end users. They provide a basis for planning, estimation, and iterative development, allowing our teams to deliver valuable increments of software in a responsive and customer-focused manner. To study more, please refer to knowledgeHut best Agile training
“In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system”
In Agile software development, user stories are used to express the requirements from an end user perspective. The format of the user story is:
As a < user >
I want to < perform an action >
So that < I expect…. >
- <User> - is the end-user or the role of the user in the application software – “As a net banking customer”
- <perform an action> - the action the user is performing on the application software – “I want to add beneficiary in my account”
- <I expect..> - outcome, desired value, the user expects out of the action performed – “so that I can transfer money to the added beneficiary”
- The larger-sized stories are called “Epics” which are then decomposed to “Features” and then further decomposed to a “User Story”.
- Epic example: As a Bank, I want to provide net banking to customers, so that they can perform various transactions.
- The above Epic can then be decomposed into multiple features: few examples:
- As a Bank, I want to provide a funds transfer feature to customers, so that they can transfer funds from one account to another account
- As a Bank, I want to provide an account summary for all the customer’s types of accounts.
- As a Bank, I want to provide credit card details to customers.
- Now each feature can be decomposed further into multiple user stories.
User stories, based on the estimated size, are taken for implementation in an iteration. User stories should be granular enough that they can be completed within an iteration and cannot be continued in the following iteration. If a story cannot be completed within an iteration, the same should be split logically. User stories are prioritized by the product owner based on business priority and are available at the top of the product backlog. The best Agile certifications will provide you immersive, customizable courses on agile methodology by experts.
The dev team pulls the stories into an iteration backlog and implements them. The Definition of Done(DOD) for user stories is decided by the team which includes acceptance criteria, and processes that need to be followed like unit testing, regression testing, code review, etc. The story is said to be “done” only when it meets the preset Definition of Done.
Know more about agile vs traditional project management.
What are Agile User Stories?
Agile scrum user stories are succinct, user-centric descriptions of a software feature or functionality. They are a core element of Agile development methodologies, providing a lightweight and flexible way to express requirements and prioritize work. User stories are used in frameworks like Scrum, Kanban, and Extreme Programming (XP) to facilitate communication, collaboration, and iterative development.
Benefits of User Story
User stories offer us several benefits in Agile development and project management. Here are some key advantages:
- User-Centric Focus
- Improved Communication
- Flexibility and Adaptability
- Collaboration and Team Engagement
- Incremental Delivery
- Simplified Planning and Prioritization
- Easier Estimation
- Transparency
- Focus on Value Delivery
- Continuous Improvement
Who Writes User Stories?
So, whose responsibility is it to write user stories for an agile team?
Agile & User stories are typically written by members of the Agile development team like us, often with input from stakeholders, product owners, or end users.
- Product Owner
- Development Team Members
- Stakeholders
- Scrum Master
- Users or End Customers
Prepare for your interviews with these top Microservices interview questions.
When are User Stories Written?
Are user stories written at the beginning of the project in a traditional way?
User stories are written throughout the lifecycle of the project. At the start of the project, user stories are written in Sprint '0', also called as pre-sprint. Initially, the product owner elicits the requirements from the stakeholder and they are stored as EPICS, Features and User Stories in the product backlog. The requirements in agile software development are progressively elaborated and hence the need for writing user stories will arise throughout the project. These are written mainly during the backlog grooming session where the product owner decomposes epics/features into granular stories. The Dev team writes stories along with the product owner during this session and also gets involved in the 3 C’s (the next section describes this).
confirmation in the 3C’s of user stories “Card”, “Conversation” and “Confirmation” is a model that captures the components of a user story. This is popularly known as the 3Cs model which helps in planning and estimating the user stories by the Agile team.
- "Card" – denotes a Post-It note or physical card, typically 3”x5” in size, where the important information of a user story is captured. The card should contain enough information (not too less or too much) that the team is able to understand in order to plan & estimate the story.
- “Conversation” – The "Conversation" emphasizes the collaborative and communicative nature of user stories. Rather than relying solely on written documentation, user stories are meant to be a starting point for conversations between team members, stakeholders, and anyone involved in the development process. Conversations help clarify requirements, address questions, and ensure a shared understanding of the user story.
- “Confirmation” – The "Confirmation" refers to the acceptance criteria associated with the user story. Acceptance criteria are specific conditions or criteria that must be met for the user story to be considered complete and successful. These criteria provide a way to objectively assess whether the development work has fulfilled the requirements outlined in the user story.
The 3 C’s of the user story generally unfold during the backlog grooming session when the dev team and the product owner discuss the stories that need to be groomed. The user stories are written during this time as well on the card by the dev team and product owner. Just enough information is captured in the story that enables the team to discuss and get into the details, uncovering any hidden or explicit information in the process. The team then negotiates with the product owner and arrives at the acceptance criteria for the user story.
Next, the dev team estimates the user story with the available information. The conversation continues between the dev team and product owner until a consensus is reached with respect to the details and acceptance criteria and until the team can size the same. This round of conversation may happen again during the iteration/sprint planning session. The dev team then implements the story in an iteration which is reviewed by the product owner or stakeholders at the end of the iteration. They will then accept the story based on the acceptance criteria defined for the story.
You can also, check out the blog post on how Agile teams can use the 5 whys root cause analysis process to identify the main reason for the problem.
Characteristics of a user story
Key characteristics of Agile user stories include:
- Agile user stories prioritize the end user's needs and experiences.
- User stories are deliberately kept simple and focused.
- User stories encourage collaboration between development teams and stakeholders.
- User stories should be independent of each other, allowing for flexibility in prioritization.
- Each user story should deliver tangible value to the end-user or customer.
- User stories support the Agile principles of iterative and incremental development.
- User stories include acceptance criteria
Why Create User Stories?
What are the benefits that a team will get by documenting the need of the stakeholders in the form of user stories?
- It enables the team to understand the requirements from a user perspective.
- The focus is on the user to provide value to them; the user story clearly describes the expected outcome of every action performed.
- This manner of capturing requirements provides opportunities for the team to collaborate more with the product owner and business users.
- By having conversations (in 3 Cs), the team is able to uncover the hidden requirements and also come up with creative solutions.
- Provides a shared understanding of the requirements to the team so that everyone is aware of the outcome/goal of the story and is on the same page.
- User stories help the team to achieve smaller product increments.
- User stories are more understandable by all stakeholders (technical/non-technical/business/operations).
- User stories help the team to implement features in smaller iterations ranging from one week to one-month durations.
- User stories enable the team for progressive elaboration, where they can defer the story until more clarity is obtained.
- User stories help create transparency of the priorities defined by the product owner and the customer.
- User stories help the developers, product owner and business owners to reach a mutual consensus as they discuss the details and agree on the acceptance criteria. With the help of the user stories tool and CSM or PMP course, professionals can enhance their career skills in agile project management.
- This helps prioritize the product features by the stakeholders and also helps to take the right decisions at the right time.
Types of User Stories
We can classify user stories into functional and technical types:
Functional: Normally, a user story is written based on the functional aspects of the application software, while focusing on the user and the value of the functionality provided to the user. Functional stories concentrate on the product features which the customer will be testing at the end of an iteration based on the acceptance criteria defined for the story.
Technical: Technical stories are written to be able to support the functional stories. Technical stories can be classified as
- Infrastructure stories: any infrastructure addition/modification that may be required to support the functional story
- Refactoring: this type of story is written to maintain the code and address technical debts. This can be used for designing and automation needs as well
- Spikes: stories that require research on architecture and design which may in turn help achieve the functional need of the customer.
How to write user stories?
Writing effective user stories is a crucial skill in Agile development. User stories typically follow a specific format, and we write to capture the essential aspects of a feature or functionality from the end user's perspective. Here's a general guide on how to write user stories:
Template for User Stories: Agile story format
"As a [user role], I want [an action or feature], so that [benefit or reason]."
Steps to Write User Agile Stories:
Identify User Roles:
Determine the various user roles or personas who will interact with the system. Each user role may have different needs and goals.
Define Goals and Objectives:
Clearly articulate what the user wants to achieve or the problem they need to solve. Focus on the specific action or feature that the user is requesting.
Highlight Benefits:
Describe the value or benefit that the user will gain from the implemented feature. This provides context for understanding why the feature is valuable.
Keep It Simple and Concise:
Agile User stories should be concise and to the point. Avoid unnecessary details and technical language. A user story should fit on an index card or a few lines in a digital tool.
Use Non-Technical Language:
Write user stories in a language that is accessible to both technical and non-technical stakeholders. Avoid jargon and technical details unless they are crucial for understanding.
Include Acceptance Criteria:
Specify acceptance criteria to define the conditions that must be met for the user story to be considered complete. Acceptance criteria help in testing and validation.
Prioritize User Stories:
Prioritize user stories based on their importance and value to the end users. This helps in planning and ensures that the most valuable features are addressed first.
Keep the INVEST Criteria in Mind:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
Examples of User Stories
Let us see some examples of user stories (Epics, Features and User Story) in this section.
ID | EPICS |
E1 | As a Sales Professional, I want to generate reports so that I can take a decision on the marketing strategy for the upcoming quarter |
E2 | As a Banking Customer, I want to access net banking, so that I can access my account and make transactions |
E3 | As an Administrator of the software, I want to access master records so that I can make changes to customer data |
ID | Features |
E2F1 | As a Banking Customer, I want to access Savings account so that I can view/make transactions |
E2F2 | As a Banking Customer, I want to access Credit Card page, so that I can view and make transactions |
E2F3 | As a Banking Customer, I want to access Loans page so that I can view my loans |
E2F4 | As a Banking Customer, I want to transfer funds, so that I can move my funds to different accounts within my bank and other banks |
| ID | User Stories |
| E2F1U1 | As a Banking Customer, I want to access/view summary of my savings account, so that I know my balance and other details |
| E2F2U1 | As a Banking Customer, I want to Login to Net banking so that I can view credit card details |
| E2F4U1 | As a Banking Customer, I want to transfer funds within my own accounts so that I can move some balance across my accounts |
| E2F4U2 | As a Banking Customer, I want to transfer funds from my account to another account in another bank, so that I can send money to my family and friends who have accounts in other banks |
| E2F4U3 | As a Banking Customer, I want to add beneficiary to my account, so that I can transfer funds to the beneficiary |
| Technical Stories |
| E2TU1 | As a Net Banking Administrator, I want to have the customer’s data backed up so that I can restore it any time in case of issues |
| E2TU2 | As a Net Banking application, I want to shake hands with another bank using a specific formatted XML so that funds can be transferred based on the customers’ needs |
User Story Templates
You can utilize four user story templates available for download to capture new product functionality from the user's perspective and specify your acceptance criteria. Each template presents a distinctive layout that varies in the level of detail you wish to incorporate.
INVEST in User Stories
This is an acronym for a set of attributes or criteria that helps us to assess the quality of the user story. If any of the attributes falls short in a story, it means that the team may want to consider rewriting the user story.
1. Independent: User stories should be independent of other stories. There should be no overlap between them. They can however follow one after the other in a sequence, in a way that makes it easy to schedule and implement them.
This is one of the challenges that the team faces especially when they have just started adapting agile ways of working. They may have a story which is dependent on something else which may be done by another team. The teams may hope that they can run the two stories in parallel and by the time the first team is done, the dependent team will also complete their part of the story. This is not the right way of running user stories, as it can result in a lot of confusion and blame.
The advantage of having independent stories is that there is no blame game across teams. It also allows to consider the dependencies and come up with innovative ways of removing them to become independent.
2. Negotiable: The story should not be written in so much detail that it becomes a requirement document. If it is in too much detail, it does not give an opportunity for the dev team to have any conversation with the product owner or the business. The story should be written with just enough detail so that it paves the way to open discussions with the product owner or business, and helps to elicit details or come up with creative solutions. By negotiating on the story with the relevant stakeholders, teams can come to a common understanding.
3. Valuable: The story should be valuable to the customer. It should clearly state why we are doing this? How is it going to produce value to the customer? What value will the customer realize by implementing this story?
The only reason why user stories should be part of the product backlog is that they add value to the customer, right?
4. Estimable: The user stories should have sufficient detail for the dev team to understand and estimate them. The conversation in 3 C’s helps the team to uncover the details with the product owner and stakeholders, so that they can size the story. If the story is too big and not sizeable, then the story should be refined or decomposed further. Whatever information the team may require should be available in the story for them to estimate it. In case there is a part of the story where the team has to do research, then a “spike” story may be created while the rest of the story can be estimated and taken for implementation.
5. Small: Good user stories should be small. This does not refer to the size or number of words written in a story. A small story is of the right length so that the implementation team can complete the story within an iteration. It should be small enough that the story is “fully delivered” during an iteration.
A small user story helps the team to develop and test quickly and easily.
6. Testable: A good user story should be testable in order to be “Done”. This is supported by the “Confirmation” in 3 C’s where the team comes up with acceptance criteria for every story after the detailed conversation with the stakeholders.
The customer should be clear about what he should test during the review. If he is not clear, then the story is not good enough to be implemented.
The team works together in a collaborative way to INVEST in good stories. The team learns to write good user stories as they work together and also proactively think about the values and criteria that are laid out in INVEST.
Pros and Cons of User Stories
Pros of User Stories | Cons of User Stories |
User stories are designed to be flexible and adaptable, making it easier to respond to changing requirements or priorities. | Poorly written user stories may lead to ambiguity or misinterpretation, requiring additional clarification. |
User stories encourage collaboration among cross-functional teams, creating a shared understanding and sense of ownership. | In some cases, the exclusive focus on user needs may lead to neglecting broader system or technical requirements. |
User stories support the Agile principle of delivering working software in small, incremental increments, allowing for quick feedback. | User stories may lack comprehensive documentation, which can be a challenge for external stakeholders or new team members. |
User stories simplify planning and prioritization, making it easier for teams to manage their work. | User stories heavily rely on effective collaboration, and if communication breaks down, it can lead to misunderstandings. |
User stories support continuous improvement by providing a basis for feedback and adaptation in each development iteration. | Scaling user stories for large and complex projects can be challenging, and additional frameworks or techniques may be needed. |
Conclusion
Transformation of documentation on user requirements in a Functional Requirements Document (FRD) or Software Requirement Specification (SRS) in a traditional project management, towards User Stories in Agile project management, is a massive step. It helps shift the mindset of how teams can understand and collaborate with the customer in a better way, by shifting their focus of implementation towards value that the customer may realize from the story. This shift has worked very well in terms of meeting the requirements and expectations of the customer. KnowledgeHut best project management certification course will help you boost your learning about agile user stories.
.jpg&w=3840&q=75)
.jpg&w=3840&q=75)
