User Stories Applied

www.whizlabs.com | ©Copyright 2013 Page 1
Module 3:
User Stories Applied

Table of Contents
Module 3: User Stories Applied ....................................................................................................................3
User Story..................................................................................................................................................3
Writing Good stories.................................................................................................................................7
Splitting User stories and other guidelines...............................................................................................9
Use case vs. User Story ...........................................................................................................................10
Key ideas of user story............................................................................................................................10
Gathering Requirements / user stories...................................................................................................11
User Modelling and Persona...................................................................................................................12
Personas..............................................................................................................................................13
Extreme Characters.............................................................................................................................13
Responsibility of developer & customer in user role modelling.........................................................13
Module Revision .....................................................................................................................................14
Case Study...........................................................................................................................................14

Module 3: User Stories Applied
User Story
User story is one of the widely used tool/practice across agile methodologies. Let’s understand the user
story and concepts behind it, in the form of conversation between Tom and Harry.
Tom is quite proud about his lengthy, fleshy requirement specs while Harry is more into agile methods
recommending user stories.
Tom
Harry
Tom
Harry
Tom
Harry
Tom
Harry
Your team should really learn from this team, see how nicely they write a detailed
requirements spec.
Okay, how does that help? Aren’t there any changes later on? I have heard arguments with
customer and customer saying something like “I know what I said but that was 6 months back”.
Customer can change their mind, based on increased understanding.
These issues are there but isn’t that customer’s job to do enough thinking before confirming
the requirements, rather than changing the mind later on.
Yes, customer should try to do enough research and try to provide sufficient details. However,
there is a practical limit for customer to visualize everything up front. They might get better
ideas and have more understanding after seeing initial versions of software.
Think this way, while giving a paining contract for your house/office, how many people know
exactly what colour/shades should be applied where, what kind of designs should be present.
Even in practical life, we do, lot of trial and error. We change our mind after seeing initial
outputs.
Hmm. You have a point.
While you spend lot of time and effort in preparing detailed requirement documents, aren’t
there any issues of wrong interpretation or false assumptions?
Actually there are issues quite often and we run into long debates of what was written and with
what intent.
That’s the whole point. Customer rarely gets what they want. Vast amount of time and energy
are spent on debating what was written, instead of doing what needs to be done. Build is done
based on what is in the spec rather than what the customer want.
Other part of trouble with big bulky requirement specifications is, stakeholders find these quite
difficult to read. Some of them are not interested in all requirements but just interested in few
areas and these are the people whose inputs could be highly important. We miss out their
inputs as they don’t have time & energy to read the whole requirements documentation.

Tom
Harry
I tend to agree with all the issues that you have highlighted about up front big detailed
requirement gathering exercise but highlighting the problems is easy. Tell me if you have a
better way.
In Agile rather than a big requirement document, we create product backlog. The agile product
backlog is a prioritized features list, containing short descriptions of all functionality desired in
the product. Just to have everything at one place, there are other items also placed in product
backlog which can’t really be classified in functional terms.
A typical product back log contains (PBIs – product backlog items):
 Features – User Stories (will talk about this in a minute)
 Defect Repair – Defects found in Done stories
 Technical work – For e.g. Automation of test scripts
 Knowledge Acquisition – Prototyping, Modelling, Exploration
 Other – Documentation etc
By far, the predominant way for a Scrum team to express features on the agile product backlog
is in the form of user stories, which are short, simple descriptions of the desired functionality
told from perspective of the user. An example would be, "As a shopper, I can review the items
in my shopping cart before checking out so that I can see what I've already selected."

Tom
Harry
This is how a typical backlog look like:
Basically the features on which work needs to be done in immediate future will be more
detailed, granular and properly prioritized. Functionality that will be worked on later could be
left as Epic i.e. a large user story. Epics are typically low priority requirements – they are low
priority that’s why these are left as epics otherwise they would have been broken into multiple
small user stories.
For e.g. Epic is – “User should be able to manager his/her resume”. Now this may be later
broken down into multiple user stories such as:
As a user, I want to be able to edit my resume
As a user, I should be able to inactivate resume
As a user, I should be able to delete resume
........
Let me also coin another term – Theme, which is nothing but a logical group of stories. For e.g.
All stories related to monthly MI; All stories for library Admin function. Typically word feature is
used for epic or theme and many times we show a hierarchy that feature contains multiple user
stories.
This user story sounds like an interesting thing. Tell me more about it.
How story look like: - A story contains three parts
1. Title – 3-10 words to distinguish this story form other stories
2. Description
3. Acceptance criteria
The recommended template for description part of user story is:
“As a [user role]
I want to [goal/desire]
so that [reason/benefit]” /* this clause is option
Please note this format is good but it’s not necessary that user story be written this way only.

Front of card
Story No: 172 Dependency on: None
Title : Save Prompt While closing
Description
As a user closing the application,
I want to be prompted to save anything that has
changed since the last save
so that I can preserve useful work and discard
erroneous work.
Priority : 4 Estimate: 2
Back of card
Confirmations
1) Change anything and then try to close
application. It should prompt for save
2) Try to close application without
changing anything, it should NOT
prompt this time.
Harry
Tom
Harry
Tom
Harry
Tom
User stories are composed of three aspects Card, Conversation, and Confirmation:
 Card : - A written description of the story used for planning and as a reminder,
typically written on index card.
 Conversation: conversations about the story that serve to flesh out the details
of the story
 Confirmation: tests that convey and document details and that can be used to
determine when a story is complete
Top Tip – Understanding three C’s of a good story and the fact that user story is a support tool
for analysis and estimation rather than detailed requirement, is quite important for ACP exam.
Index card? Even if it’s just one small functionality but how can you write complete details of
that on small index card?
You don’t have to put all the details. User story is a tool to support planning so you just need to
have basic details. It’s a reminder to collaborate about the topic of the user story later on. The
focus is more on verbal communication between customer and developer rather than written
specification. If you understand this basic, there is no hard & fast rule to put user story on index
card only.
The agile underlying values - collaboration and just-in-time – make user stories a good agile
tool.
Got what you mean by card & conversation but not so sure about confirmation part.
On the back of index card for user story, customer is asked to put success criteria - basically
some acceptance tests. The idea here is not to capture each and every test case but to broadly
understand the success criteria. Acceptance tests provide basic criteria that can be used to
determine if a story is fully implemented. Moreover, these provide additional information
about key business rules, which can be used by developers before start of the coding.
Who should write the user stories?

Harry
Tom
Harry
The customer team, rather than the developers, writes the user stories for two key reasons.
1) Customer team is best placed to describe the desired feature.
2) Story must be written in the language of the business, not in technical jargon, so that
the customer team can prioritize the stories for inclusion into iterations and releases.
Stories are initially typically written in story writing work-shop, but stories can be written
anytime throughout the project. In practice, many times domain experts or even developers
write the stories. They key here is, customer should provide content and own this activity.
Sometimes the end users are not available to play role of customer so we have to use user
proxies. Typically business analysts or domain experts are used as user proxies.
Are there any guidelines for what you call as good user story?
Yes there are:
Writing Good stories
To create good stories we focus on six attributes. A good story is INVEST (remember this
acronym), which means Independent, Negotiable, Valuable, Estimatable, Small, Testable.
Let me explain more:
 Independent
Dependencies in the stories lead to planning & prioritization issues so we should try to
create stories as independent as possible. There could be two tricks to resolve
dependencies:
a) Combine the dependent stories and create slightly large but independent story.
b) Do the split in a slightly different way
 Negotiable – Stories are not written contracts or baselined requirements, which are
hard to change. Stories should contain basic information (as mentioned in suggested
template) and other notes about issues to be resolved during conversation. The details
can later be negotiated between customer and development team.
 Valuable – Story should be valuable for user or purchaser. The details which are very
specific to IT processes and technology could be valuable for development team but
make no sense for customer/user. Let’s take few examples:-
a) All deliverables should be created using standard templates.
b) Team should produce traceability matrix and other deliverables in line with
CMM level 2
c) Use Db2 V9 referential integrity features
d) Performance testing needs to be done
e) More than 50 users should be able to work in parallel without any performance
issues
f) Add a new feature to group individual orders for same client to save courier
cost.
a), b),c) and d) are not valuable. These might be useful for development team but these
make no sense for customer team. e) and f) are valuable.

 Estimatable – The possible reason why story might NOT be estimatable are:
o Team lacking technical/domain knowledge
o Story being too big.
In case of issue with domain knowledge customer should talk to customer and try to
gain domain knowledge.
If problem is with technology knowledge, team can conduct a spike i.e. a short time-
boxed activity to research/experiment to learn enough to be able to estimate. The
story turns into two stories 1) Spike Story to gather information 2) story for real work.
For complex stories, it’s good to have spike story in one iteration and complex story in
subsequent iteration.
A large story should be disaggregated into smaller constituent stories so that these can
be estimated more confidently.
As explained previously a large user story is called as Epic. Sometimes we deliberately
write Epics as placeholder/reminder for further discussion and disaggregation. We can
provide a high level estimate, which can change late on.
 Small – The story should be of right size, not too big (Epics) or not too small (Just 15-20
mins task). What is ‘right size’ depends on the team, its capability and technology in
use. In case of very small stories, consider combining the stories.
In case of large stories consider disaggregation i.e. splitting of stories.
Epics could be of two types:
o Compound story – Containing multiple small stories
o Complex story – Large story which is difficult to divide into small chunks. In this
case, we might need a spike story to gather information.
 Testable – Stories must be written so as to be testable. See these:
o The screen performance should be good (What is good?)
o Software should be easy to use (How do we know what is easy?
In first example if someone says, that all inquiry screens should give the result back
within 1 second, that’s something tester can test. Otherwise it’s anyone’s guess to
define the good performance.
Top Tip – Remember the acronym INVEST and how that represent key aspects of a good user
story.

Tom
Harry
Splitting User stories and other guidelines
Tell me more about splitting of stories. It sounds like tricky area to me:
It is actually tricky and it does require experience in having the right split but let me tell you
some basic guidelines for story combining and splitting:
 Splitting stories Reasons - There could be multiple reasons for splitting a story such as:
- Story is too large to fit into iteration.
- Story is small enough to fit into iteration but there isn’t sufficient room to
accommodate this.
- A more accurate estimate is required. Bigger size means higher uncertainty and
less precision in estimate.
 Splitting Stories – Guidelines
- Splitting across data boundaries – If there are too many fields. One story could be
around handling only few basic fields. In subsequent stories, more data fields can
be added.
- Splitting on operational boundaries (Slice vertically) – Slice based on functionality
rather than going by architecture level layering. Think of this as below three layer
cake, wherein your layers are user interface layer, application layer, data layer.
Will you slice it vertically or horizontally?
Slicing vertically makes it independent and valuable. A common approach is to
split a story along the boundaries of common CRUD operations – Create, Read,
Update and Delete.
- Remove Cross cutting concerns – Often it’s good to remove non-functional aspects
such as security, error logging and performance etc in separate stories.
- Split stories of mixed priority – If a story contains multiple business rules but these
having different priorities, it’s better to split these into small stories.
- Don’t Split a story into tasks
 Combining Stories – Guidelines
- If stories are too tiny, it’s better to combine these logically into one or more
stories.
- Prefer to combine stories which are related and having almost similar priority
- Common to combine multiple bug reports
At the same time, let me tell you few other guidelines for user stories:
 Closed Story – Story for which success criteria is either clearly mentioned or implicit.
It’s desirable to have closed stories.
 Include user roles in the stories
 Write for one user
 Write in active voice
 Put constraints on the constraint cards – constraints are typically non-functional
requirements.

Tom
Harry
Use case vs. User Story
Thanks for your advice and detailed explanation. What is the kind of difference and
relationship between “Use Case” and “User Story”.
A user story is very simple and is written by the customer. The focus is completely on
understanding the need for customer and main scenario. It doesn’t handle all possible
scenarios of user interaction with system/product. It serves as reminder and starting point for
additional discussion with the customer to know the full extent of needs.
Use case is typically more complex and is written by the developer in cooperation with the
customer. It attempts to be complete, accurate, and handle all possible cases. During
development, it's intended to be able to answer any developer questions about customer
requirements so that developers may proceed without having to track down the customer.
There is no exact 1-to-1 or 1-to-many kind of relationship between these two terms. The exact
format and amount of details in use case vary. Agile methodology prefers user story but then
there are people who write user cases with less precision so that these are quite close to user
stories.
Another important difference between use cases and stories is their longevity. Use cases are
often permanent artefacts that continue to exist as long as the product is under active
development or maintenance. Stories, on the other hand, are not intended to outlive the
iteration in which they are added to the software. While it is possible to archive story cards,
many teams simply rip them up.
Key ideas of user story
Let me summarise the key ideas of user story:
1) User stories are support tools rather than requirements specifications
2) These highlight negotiation / collaboration to happen between the customer and the
team.
3) User stories help in deferring details till later – Just in time detailing
4) They talk problems not solutions
5) They fit nicely as product backlog items

Tom
Harry
Gathering Requirements / user stories
I now understand what is a user story but how to start the process of gathering requirements
and story writing?
Agile methodology doesn’t believe in spending long time in requirement gathering. However,
that doesn’t mean we should make an effort to gather as much requirements up front as we
can even if that means just capturing these at very high level.
For example, if user says she might require search facility, make a note – “user needs search
facility”. But there is no need to spend lot of time in finding further details such as basis of
search and outcome etc. This story will sit as large story or epic which can be disaggregated
into small stories later on.
The key techniques for gathering stories are:
 User Interviews: - Ask open ended questions. Don’t assume that user knows and can
explain exactly what they need. Ask follow-up questions; try to show some option to
reach to a common point.
 Questionnaires:- Questionnaires can be useful if we need to gather information from a
large user base. They can help in prioritization of stories for e.g. we may ask out of
these features, which one looks most interesting to you. However, this should NOT be
the primary technique to gather information because questionnaires can’t ask follow-
up questions and may lead to faulty conclusion. If you keep the question objective, it’s
hard to know what else users need. If you keep it free-form text, hard to consolidate
information.
 Observation:- If there is opportunity to see users using actual software, grab it. You
may get many ideas about how to improve user experience.
 Story Writing workshops:- This is a meeting attended by developers, testers, users,
customers and any other parties who can contribute in writing stories. These people
brainstorm and try to write as many stories as they can (focus on quantity rather than
quality i.e. amount of details in each story). No estimation or priority assignment
happens at this stage.
Create a parking lot of issues to come back to. Also, think about user roles and
personas while writing stories

Tom
Harry
User Modelling and Persona
Can you elaborate more about user roles?
Many times for same feature there are different types of users. Their needs and interaction
with product could be so different that writing story with just one generic role will not make
sense. For example, let’s consider a travel web site. Basic case would be to search hotels.
However, there could be different user types, just for illustration some of these could be:
a) Business people – Typically looking for hotel with business facilities – typically
frequent travellers can spend more.
b) Domestic holiday traveller
c) Newly married couple
d) Students – typically looking for budget hotels
While each user will come with a different background and try to user the application for
different purpose. However, it’s still possible to put all users in broad categories.
The typical steps in identifying and selecting a set of user roles are:
 Brain-storm and identify initial user roles – Customer and developers meet and try to
identify as many roles as possible.
 Organize the initial set – Try to put user roles in broad categories and try to check
overlap between various user roles. For e.g. in previous example of travel web site,
broader user roles could be a business/corporate traveller, Vacationer, Administrator
 Consolidate roles – Try to consolidate and remove roles having too much of overlap in
terms of usage, needs etc.
 Refine the roles – Identify relationship between various roles and role attributes. The
attributes worth considering are:
o User’s general proficiency with computers or electronic devices on which
software is supposed to run
o User’s level of proficiency with software being developed
o User’s purpose of using software.
o User’s level of knowledge of domain. For e.g. if software is for banking
application, domain here means general banking knowledge
o Frequency of usage

Tom
Harry
Tom
Harry
Just now you mentioned a term ‘personas’. What does that mean?.
Personas
Persona is an imaginary representation of a user role. We create persona for key important
roles (not for all) as it helps us in understanding the user experience better. Stories become
much more expressive when put in terms of a persona. Developers instead of asking “will it be
easier to use this feature for a user”, team would ask “Will it be easy for Jim to use this
feature”.
Add details to the persona such as name, likes and dislikes, job, goals etc. Instead of
“programmer looking for job”, it should be “Java programmer currently working for ABC Ltd.
Looking for a job in New York”. A photo can also be added. Basically everyone in the team
should feel they know the persona.
Personas do represent real, stereotyped, composite, and fictional people. They are archetypal
(exemplary) descriptions, grounded in reality, goal-oriented, specific, and relevant to generate
focus. However, personas are not a replacement for requirements on a project.
However, we don’t just make up persona. We have to ensure that enough market and
demographic research has been done so that personas really represent the product’s key user
base. Generally avoid picking personas who are real users.
Extreme Characters
Extreme characters as the name suggest are exaggerated personalities - people who are not
typical users of the product for e.g. a priest or housewife using dating website. It is very
possible that considering extreme characters will lead to stories which are likely to get missed
otherwise. It’s debatable whether it’s worth investing time in thinking about extreme
characters and the new stories discovered might never be included in the product.
Thanks for the explanation. Can you explain in this whole exercise of user role modelling, what
is the role of developer?
Responsibility of developer & customer in user role modelling
Developer Responsibilities are:
a) Participating in the process of identifying user roles and personas.
b) Responsible for understanding user roles or personals – their similarities and
differences.
c) While writing software, keep in mind how software will meet requirements of
different user roles and how these user roles with interact with software.
Customer responsibilities are:
a) Looking what could be the possible users and user roles.
b) Participating in the process of identifying user roles and personas.
c) Ensure software does not focus inappropriately on a subset sub-set of users.
d) Ensure that each story should be associated with at least one user role or persona.
e) Think how different user roles may prefer the software to behave
Ref: User Stories Applied: For Agile Software Development by Mike Cohn

Module Revision
Case Study
Cricket Mania Ltd is an organization, which sells Cricket books and other goods related to Cricket. They
are planning to launch a website to sell the goods online. They would start with Cricket books.
a) Identify key user roles.
b) Consolidate and come up with a list of key user roles
c) Write persona description for the one most important user role
d) Write user stories for a book search feature.
e) Write few user stories for gift-buyer role type.
f) Add few acceptance tests for administrator role type.
Ans:
This is a hypothetical case study so there is no perfect answer. Following are few examples to help in
understanding the concept:
a) Key roles could be: Novice Player, New player, Gift-buyer, Administrator, Cricket Coach, Cricket
academy, Professional player, Experienced player, Sales & Marketing person
b) After consolidation and narrowing, we might come up with a smaller list for e.g. Novice player
and new player can be a single role; similarly professional player and experienced player could
be a single role.
It’s important to consider various aspects here for e.g. user’s proficiency with computers &
internet, knowledge of cricket etc. A gift buyer could be quite proficient with computers but
don’t have much knowledge of cricket. On the other hand a professional player might have
limited knowledge of computers.
After understanding various aspects, you may come up with final list of roles. For e.g. you may
initially tend to put cricket coach in the same category as professional player but after adding
more role description, you may realizes it’s better to put in cricket academy category
considering that this user role typically buys in bulk.
c) Ron is an experienced player, who has played in under-19 national team. He is 22 year old and
trying hard to be part of national team. He is keen on improving his skills so he practices daily
and often reads cricket books. He is comfortable buying from internet.
d) A user can search for books by author, title or ISBN number.
e) A user can look for top 10 most selling books; A user should be able to see review rating of any
book

User Stories Applied

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (18)

Plus de Whizlabs

Plus de Whizlabs (20)

Dernier

Dernier (20)

User Stories Applied