User story that came from Extreme Programming moves away from writing requirements and focuses more on talking. They are used to capture the requirements in multiple implementations of Agile, including Scrum.
According to Wikipedia, “A user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function”
Before we talk about user-story further, it’s important to understand why people needed to shift from big bulky requirement documents to something called user-story.
In waterfall, requirements are captured in big documents. Why? The team works in silos.
Silos are all about working as independent departments within the team. No more collaboration towards holistic goal. The focus is to complete their individual targets and not overall project goals. So for a tester in waterfall, the goal is to find as many bugs as he/she can. The goal is no more helping the developers build quality within the product from day one. Similarly, developers focus on completing their coding and leave quality to testers.
In waterfall, development team members come onboard at different point of time. For instance, testing team members come onboard only when development is over. As testing team members may not be around at the time the requirement got written or modified, the only way to know the requirements and the changes within was through the Functional Specs document.
Any change in the requirements have big repercussions as that could impact whole cycle of design, coding, testing and development over a course of time. It was also implicit that any change at any point of time had to be reflected in all documents, including Functional Specs.
Move to Agile and team consists of cross-functional team members (i.e. developers, designers, devOps and testers) working together to build a small functionality end-to-end that provides business value to the end user. Alll cross-functional team members communicate face-to-face and clarify their doubts. As soon as they arrive with fellow team members, they don’t need to rely on big bulky documents anymore. They create documents which serves purpose in the maintenance phase.
With this background, let’s understand the concept of user-story.
What is a user-story?
User-stories are written from end-user’s perspective. They typically follow the following templates:
As a <type of user>, I want <some goal> so that <business value>.
As a <who?>, I want <what?> so that <why?>
One should be able to write a user-story in 4×6 index card. They have to be small enough to explain the intent but details could be finalized after discussions within the team and product owner.
Example User Story
User stories can be written in varying details. Large user-stories are called epics or features.
Here’s an example of Epic written for email client:
- As a user I would like to have search functionality for my emails so that I don’t have to find the related email manually
Team should work on smaller user-story which could be finished within half sprint by a pair of developers. As this epic is too large, let’s break it in to smaller user-stories:
- As a user I would like to search my emails by keyword so that I don’t need to find them manually
- As a user I would like to limit my search to one field as that’s important for me to begin with
- As a user I would like to search my emails with attachments so that I don’t need to find them manually
INVEST Principle: Characteristics of Ideal small user-story
An ideal user-story should follow the INVEST principle
I – Independent
Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.
N – Negotiable
It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details.
V – Valuable
We don’t care about value to just anybody; it needs to be valuable to the customer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers.
E – Estimable
We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation.
S – Small
Good stories tend to be small. Stories typically represent at the most a few people’s days’ worth of work. Above this size, it seems difficult to know what’s in the story’s scope. Smaller stories tend to get more accurate estimates.
T – Testable
If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.
User-stories are very important and relevant while working in Agile methodology. As they are very concise, they encourage face-to-face communication and collaboration for further confirmation. They are also written from end user’s perspective and the focus is to build an end-to-end production ready functional slice which provides business value to the end-user. As there is a lot more focus on communication with just enough documentation which is useful for the team from maintenance standpoint.
Please share your thoughts and queries on the usage of user-stories in your projects in the comments section.
Got a question for us? Please mention them in the comments section and we will get back to you.
PMI-ACP is a registered mark of Project Management Institute, Inc. Edureka is a Global PMI® REP: ID 4021