One of the principal values of Agile is people over processes. Scrum embodies this and provides artifacts and features that are customer centric. A user story is one such feature, that enables transparency, is simple to understand, fosters collaboration and makes the process of delivering the sprint goal much easier. In this blog, we attempt to explain the best practices of user stories; also known as the 3C’s of user stories.
How do you define a user story?
A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer—Atlassian
Writing requirements may be easy for those developing the project. But what about customers, who may not always understand technical jargon? Scrum, with its emphasis on customer collaboration, solves this problem with the help of user stories.
Scrum involves breaking down a complex project into smaller chunks. Each chunk, called an epic, is further broken down into smaller units called user stories. A user story, thus, is the smallest unit of work in an agile project. It describes the end goal to be achieved and is always told from the perspective of the user. In other words, user stories are the foundation or the building blocks of larger units within the project—like epics and initiatives.
Since, it is told from the perspective of the user, it is written in a form that is easily understood by the user. Which means, it is written in a simple and informal way and explains what the software feature it represents is supposed to achieve. It is not detailed, rather it is short and not more than a few sentences long. If needed, requirements may be added to the user story as more get chalked out during the course of the development of the feature in the sprint.
So, in other words, a user story describes one specific need or requirement of the user. It may also be called as a scenario. Use stories can be written on index cards, word documents, or even on excel spreadsheets.
User stories are also great for estimating the work to be done or the work left to be done. The estimation of the amount of work to be done or the effort required to complete the work is necessary as this will help in determining the schedule, costs and resources required to deliver the requirement.
Some of the methods of estimating using user stories include:
- Planning Poker
- T-shirt sizing
- The Bucket system
- Affinity mapping
- Ordering Method, and more
When did User stories originate?
User Stories are chunks of the desired behavior of a software system. They are widely used in agile software approaches to divide up a large amount of functionality into smaller pieces for planning purposes–– Martin Fowler
So, the question here is, when did we first actually start using user stories? According to Agile Alliance®, user stories first originated in 1989 in Extreme programming, an agile software development framework like Scrum. While originally, at the time of their introduction they were very similar to use cases, over time their detail and scope changed.
User stories and use cases may still sound and look very similar, but there are subtle differences between the two. A user story is more about the need or requirement of the user while the use case describes the feature that we build to fit the needs described by the customer. They are a bit more technical and define the interaction of the feature being built with the rest of the system, software or process. User stories on the other hand are easier to read and understand.
According to Ron Jeffris, who proposed the Card. Conversation, Confirmation model for user stories, use cases are documentary requirement practices while user stories are social requirement practices.
Three Cs of User Stories—well explained
“Card, Conversation, Confirmation”; this formula (from Ron Jeffries) Captures the components of a User Story—Agile Alliance
In 2001, the Card, Conversation, Confirmation model for user stories was proposed by Ron Jeffris for extreme programming, where he states user stories to be critical elements of the XP “Circle of Life”. Let’s look at the three aspects of user stories.
Where are user stories written? On cards. They are written manually on index cards and this exercise helps keep the user stories concise. The card will not contain all or too much information on the requirement. Instead, the card will have only enough information to identify the requirement and help everyone understand what the story is.
The card represents the requirement and is a great tool for planning. It can also be used to write down some more notes like the priority or the story and the cost involved. The Product Owner, after finalizing the user story to be picked up for the particular sprint, will hand over the user story card to the developers.
The standard format used for writing the user story on the card is as follows:
As a [user type], I want / need [goal] so that I can accomplish [justification/business value].
The card is the first step towards formulating the user story, but the requirement needs to be further discussed and refined and communicated to the developers. This is done through conversation. The conversation between developers, Product Owner, Scrum Master and the stakeholders also fosters collaboration between all, thus helping in getting a shared understanding of the requirement and leading to the development of the product.
This exchange of thoughts and opinions through conversation takes place incrementally over time, starting from story estimation carried out during release planning and then during the sprint planning meeting when the story is picked up for implementation. While the conversations are mostly verbal, documents can be used for support.
Even with the most in-depth conversation, there is always an element of doubt about the requirement that has to be created. How do we proceed with the user story and ensure that this is what the requirement states?
This is done through the third C of the user story— ‘confirmation’. Confirmation is in the form of acceptance tests. The confirmation is the acceptance criteria that captures the essential requirements and helps us test the created product to ensure that it meets the defined criteria.
Acceptance criteria are generally created by the Product Owner and further refined and extended in the backlog refinement. The developers implement the acceptance criteria or acceptance tests. The increment created based on the user story should satisfy the acceptance tests, which confirms that the feature has been implemented correctly. The developers, at the end of the iteration, demonstrate the completion of the story by passing the acceptance criteria. This is confirmation completed.
When these three Cs of the user stories are completed and satisfied, the feature created is compete and can be released.
User Story Template: The Role, the Action and the Benefit
A user story template defines the format that is used while writing user stories. According to Agile Alliance the most common template uses the format, “As a… I want to… So that…”
- As a (who wants to accomplish something)
- I want to (what they want to accomplish)
- So that (why they want to accomplish that thing)
A user story is written from the point of view of the user. It describes the role of the user, the action or what the user needs and the why of the story or the benefit that it provides.
Let’s look at each of these components in detail:
- The role: The role refers to the user who uses the system or for who the feature is being built. The developers are not the users of the feature.
- The action: The ‘what’ part of the story suggests the action or the behavior of the system. Each story has a unique action.
- The benefit: This is the result of the action, which is what the user needs to happen.
As <a user> I want to be able to <search> so that <I can get the products I want>
As <a user> I want to able to <add items to cart> so that <I can check out the items>
How to Write a Good User Story with INVEST
INVEST is an acronym for:
A good user story should encompass all these properties. Let’s examine each of these features:
- Independent: Keeping stories independent of each other helps to prioritize stories on the backlog. If a story is dependent on other stories, then it cannot be taken up till the other stories are completed, even it has a higher priority.
- Negotiable: A story is negotiable which means that it can be altered based on the conversation that happens between the developers, Product Owner and the consumers. A collaborative dialogue between the developers and the users for whom the feature is being developed, or the user’s proxy, that is the Product Owner, is a must. All parties must arrive at a common vision and then development must start.
- Valuable: The user story must be measurable, which means that it must add value to the overall project. So, a user story must add value not just to the user for who it is being developed but it should also satisfy non-functional requirements.
- Estimable: A user story must be estimable so that its value and subsequent priority can be gauged. This helps the product owner decide its priority in the product backlog.
- Small: User stories represent the smallest unit of work in Scrum projects and represent a small functionality that the product delivers. If the user stories are large, they must be broken down into smaller units as smaller user units help in faster delivery of the features.
- Testable: Every user story needs to be testable to confirm that it is working as it should and delivering value to the customer. The acceptance criteria are written for this purpose. When the user story passes the acceptance criteria it is complete and ready to be shipped.
Tips for creating great user stories
Roman Pichler has come up with these tips that will help create fail-safe user stories:
- Write the user story from the point of view of the user
- Use personas to create the best user story scenario
- Ensure collaboration while creating user story
- Keep stories simple
- Start with epics
- Keep refining the stories till they are ready
- Add acceptance criteria
- Use paper/index cards for writing down user stories
- Make sure your stories are visible and accessible
The success of a Scrum project depends largely on the details and the user story is one such detail that should not be ignored. It’s a tool not just for creating a feature but also to promote collaboration and transparency among team members and the stakeholders. Writing good user stories is a necessity for Scrum projects as they give clarity to requirements and help create features and products that are approved by the customer.