If you don’t get the user needs right, it doesn’t matter how well you execute the rest of the project. Requirements are the foundation for all the project work that follows. The software development project success lies in understanding the user requirements accurately and appropriately, and then implementing them in the final product. The purpose of a software project is to build a product that provides value to its customers. Thus customer involvement is the most critical contributor in eliciting requirements. Prior to agile, software requirements were described with respect to system. Though not bad, but still there was less user interaction or requirements were not formulated (in detail) from User perspective. The result – industry adopted a new standard. You might have heard about User Story in Agile Software development projects. In this article, let’s see what does User Story actually mean!
What is a User Story?
As the name suggests – it’s a story from users’ perspective. What story? Obviously the description of a required software feature. What’s different? The perspective! The User story focus on who the feature is for, what they want to accomplish, and why rather than what system can do. User story avoid the descriptions of how a feature should be developed – leave it to architects, developers & testers 🙂 Each user story should simply state what a user wants to do with a software feature and describe it from the user’s perspective.
A User story is a description with 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. It captures the “who”, “what” and “why” of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper note-card.
Don’t just write, talk – User stories help shift the focus from writing about requirements to talking about them. It’s often best to think of the written part as a pointer to the real requirement – to be discussed afterwards.
The History of User Story
User stories originated with Extreme Programming (XP), whose first written description in 1998 only claimed that customers defined project scope “with user stories, which are like use cases”. However, most of the further literature thrust around all the ways arguing that user stories are “unlike” use cases, in trying to answer in a more practical manner “how requirements are handled” in XP and more generally Agile projects. This drives the emergence, over the years, of a more sophisticated account of user stories.
In 1999, Kent Beck came up with a term User Stories for the product features. He described that a User Story is narrated from user perspective regarding what he or she wants to have rather that what system can do for him. Thus, the view changed from product to user completely and User Stories became de facto standard for Requirements in all agile frameworks.
In 2001, Ron Jeffries proposed the well-known Three C’s formula, i.e. Card, Conversation, and Confirmation, to capture the components of a user story:
- A Card (or often a Post-it note) is a physical token giving tangible and durable form to what would otherwise only be an abstraction;
- A Conversation is taking place at different time and places during a project between the various stakeholders concerned by the given feature (customers, users, developers, testers, etc.), which is largely verbal but most often supplemented by documentation;
- The Confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally.
The essence of user-centric and usage requirements elicitation is to focus on what the user wants to have, not what the user wants the system to do.
User Story Template
Having a template for a user story, provides a good guideline. It helps avoid common problems and pitfalls. With a template, you get to see what user role the story is for, what they want to be able to do, and why.
As a <user type>, I want to <function> so that <benefit>
As a <type of user>, I want <some goal> so that <some reason>
As a <role>, I want <goal/desire> so that <benefit>
As <who> <when> <where>, I <what> because <why>
As a <type of user> I want <to perform some task> so that I can <achieve some goal/benefit/value>
User Stories doesn’t need to be this format. The user story format is not a requirement of Scrum but it helps to force the story writer to articulate who, what & why. The concept of writing a user story is to start a conversation around the story, and the mutual understanding that we try to build, the value we want to offer to a user and how the user will utilize it. In fact, these discussions are more important than whatever text is written. User stories are often written on index cards or sticky notes, and arranged on walls or tables to facilitate planning and discussion.
User stories are often accompanied by Acceptance criteria – it provide the Definition of Done for the story. As details about the story evolve, capture the critical ones as acceptance criteria. The product owner should list as many acceptance criteria as possible in order to clarify the intent of the story. Once an iteration has begun, testers can formalize acceptance criteria into acceptance tests.
Example User Story
User stories are written throughout the agile project. Usually a story-writing workshop is held near the start of the agile project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project or a three- to six-month release cycle within it. User Story is only meant to describe a feature, but not describe how to implement it, meaning leaving out the technical aspect, it should describe the behavior or flow from user’s perspective.
User story title: Customer withdraws cash.
As a customer, I want to withdraw cash from an ATM so that I don’t have to wait in line at the bank.
Acceptance Criterion 1:
Given that the account is creditworthy
And the card is valid
And the dispenser contains cash,
When the customer requests the cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned.
Acceptance Criterion 2:
Given that the account is overdrawn
And the card is valid,
When the customer requests the cash
Then ensure the rejection message is displayed
And ensure cash is not dispensed.
Why User Stories?
- The perspective: First & foremost – change the focus from system-centric to user’s perspective
- Simple: Avoid being formal or adding too much detail (which inappropriately lock developers into one solution)
- Discuss: Don’t just write the requirement, discuss it
- Modular: Instead of overall requirements, get down to small enough chunks that invite negotiation and movement in the backlog
- Leave the technical functions to the architect, developers, testers, and so on
- Prioritize: Pick-up the most important user stories first and deliver the maximum business-value
- The ‘who’ part connects users who consume the capability with the project team
- Focused: User stories are short forms of the user’s needs which helps the project team understand the exact intent of the user need.
- Being Agile: User stories recognize the importance of change. If the scope of the user story becomes large, they can be split into smaller user stories OR by adding “conditions” to acceptance criterion
- The acceptance criteria captured for each user story leads to user satisfaction, as it is communicated early to the development community.
- Business value: The syntax of the User Story itself ensures to capture the goal or benefit or value that the user wants to achieve.
User Stories are managed in the Product Backlog. The User Stories are ordered according to priority. The most prioritized user stories are refined to granular level, while the least priority user stories are kept at a lesser detail level. For every sprint, the most prioritized and hence more granulated user stories are taken into the sprint backlog. If a user story is to be added to the product backlog, its priority is first determined, and it is placed according to its place as per the priority. The user stories can be re-prioritized at any time. It is also possible to remove any of the user stories if required.
In subsequent articles, we will look at some more agile concepts like Sprints, Product Backlog, Use case vs. User Story, etc. Till then, stay tuned!