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 and different types of user stories with examples
User Story is a tool in which requirements are captured in an easy to understand plain language, and is written from the perspective of an end user.
“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 stories, based on the estimate 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 dev team pulls the stories into an iteration backlog and implements them. The Definition of Done(DOD) for user stories are decided by the team which includes acceptance criteria, 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.
So, whose responsibility is to write user stories in an agile team?
Generally, the notion is that only the Product Owners should write user stories as they are the ones who elicit requirements from the stakeholders. However, in practice, any member of an Agile team may write user stories, though the overall responsibility is that of a Product Owner. The product owner should go through the stories and prioritize them in the product backlog. Over the course of an agile project, every team member is encouraged and expected to write user stories.
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. 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
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 needs 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.
What are the benefits that a team will get by documenting the need of the stakeholders in the form of 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.
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.
The only reason why user stories should be part of the product backlog is that they add value to the customer, right?
A small user story helps the team to develop and test quickly and easily.
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.
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.
Let us see some examples of user stories (Epics, Features and User Story) in this section.
|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|
|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|
|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|
|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|
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.
85 percent of respondents say Scrum continues to... Read More