Scribd
Upload
22 views3 pages

SE User-Stories

Software engineering user stories

Uploaded by

anjum murgod
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
22 views3 pages

SE User-Stories

Software engineering user stories

Uploaded by

anjum murgod
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

User stories

In software development and product management, a user story is an informal, natural language
description of one or more features of a software system.
A user story is a tool used in Agile software development to capture a description of a software feature
from an end-user perspective. A user story describes the type of user, what they want and why. A user
story helps to create a simplified description of a requirement.
User stories are often recorded on index cards, on Post-it notes, or in project management software.
Depending on the project, user stories may be written by various stakeholders such as clients, users,
managers or development team members.
“User stories are part of an agile approach that helps shift the focus from writing about requirements to
talking about them. All agile user stories include a written sentence or two and, more importantly, a series
of conversations about the desired functionality”
Why User Stories?
Requirements always change as teams and customers learn more about the system as the project
progresses. It’s not exactly realistic to expect project teams to work off a static requirements list and then
deliver functional software months later.
With user story approach, we replace big upfront design with a “just enough” approach. User stories
reduce the time spent on writing exhaustive documentation by emphasizing customer-centric
conversations. Consequently, user stories allow teams to deliver quality software more quickly, which is
what customers prefer. There are quite a few benefits for adopting user story approach in agile
development such as:
 The simple and consistent format saves time when capturing and prioritizing requirements while
remaining versatile enough to be used on large and small features alike.
 Keep yourself expressing business value by delivering a product that the client really needs
 Avoid introducing detail too early that would prevent design options and inappropriately lock
developers into one solution.
 Avoid the appearance of false completeness and clarity
 Get to small enough chunks that invite negotiation and movement in the backlog
 Leave the technical functions to the architect, developers, testers, and so on
Basic Concepts of User Story
A user story is a lightweight method for quickly capturing the “who”, “what” and “why” of a product
requirement. In simple terms, user stories are stated ideas of requirements that express what users need.
User stories are brief, with each element often containing fewer than 10 or 15 words each. User stories are
“to-do” lists that help you determine the steps along the project’s path. They help ensure that your
process, as well as the resulting product, will meet your requirements.

A user story is defined incrementally, in three stages:


The brief description of the need
The conversations that happen during backlog grooming and iteration planning to solidify the details

The tests that confirm the story’s satisfactory completion


How to Write User Stories?
When getting started with writing user stories, a template can help ensure that you don’t inadvertently
start writing technical tasks:

User Story Template


User stories only capture the essential elements of a requirement:
Who it is for?
What it expects from the system?
Why it is important (optional?)?
Here is a simple format of user story used by 70% of practitioners:

Role – The user should be an actual human who interacts with the system.

Be as specific as possible
The development team is NOT a user
Action – The behavior of the system should be written as an action.

Usually unique for each User Story


The “system” is implied and does not get written in the story
Active voice, not passive voice (“I can be notified”)
Benefits – The benefit should be a real-world result that is non-functional or external to the system.
Many stories may share the same benefit statement.
The benefit may be for other users or customers, not just for the user in the story.

User Story Examples:


As a [customer], I want [shopping cart feature] so that [I can easily purchase items online].
As an [manager], I want to [generate a report] so that [I can understand which departments need more
resources].
As a [customer], I want to [receive an SMS when the item is arrived] so that [I can go pick it up right
away]
In the examples above:

Role represents the person, system, subsystem or any entity else who will interact with the system to be
implemented to achieve a goal. He or she will gain values by interacting with the system.
Action represents a user’s expectation that can be accomplished through interacting with the system.
Benefits represents the value behind the interaction with the system.
It is not a rule but a guideline that helps you think about a user story by considering the followings:

The user story will bring value to someone or certain party (e.g. customers).
The user story is fulfilling a user’s need (e.g. receive an SMS when the item is arrived)
There is a reason to support implementing this user story (e.g. customer can go pick up the item she
purchased)

You might also like