Theoretical basics how User Stories are used in agile software development

1. User stories in agile software
development
Prepared by:
Sandra Svanidzaitė & Eglė Kumpelytė

2. Agile background for stories
•
•
•
•
The Agile Manifesto
Communication
PDCA - Plan, Do, Check, Act
Why, What & How

3. The Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Source: www.agilemanifesto.org

4. Project Management is all about
communication
People who want IT must communicate
with people who can build IT.

5. Effective communication

6. PDCA - Plan, Do, Check, Act

7. Why, What & How
•
•
•
•
WHY are we doing this?
Voice of the stakeholder (Stakeholders)
WHAT needs to be done?
Voice of the user (Product Owner, Subject
Matter Expert)
• HOW do we build it?
• Voice of the developer (Agile Team)

8. Agile User Stories
• Work breakdown structure (WBS) in traditional vs. agile projects
• What is a user story?
–
–
–
–
–
Cards - Conversation – Confirmation
INVEST guideline
Story forms/templates
Skill levels regarding user stories of an Individual and Agile Team
Non-functional Requirements gathering
• User Story writing workshops, techniques and concerns
–
–
–
–
•
•
•
•
•
User Role Modeling
Trawling for Requirements
User Proxies
Epics and user story breakdown
User Stories vs. Use Cases vs. Requirements
Requirements IEEE 830
Product Backlog of User Stories
Tips for Writing Good User Stories
Smelly User Stories

9. Alternative to Work Breakdown
Structure (WBS)

10. What is a User Story?
• User Stories provide a light-weight approach to managing
requirements for a system.
• A short statement of function captured on an index card
and/or in a tool.
• The details are figured out in future conversations
between the team and the product owner or customers.
• This approach facilitates just in time requirements
gathering, analysis and design by the following activities:
– Slicing user stories down in release planning
– Tasking user stories out in sprint planning
– Specifying acceptance test criteria for user stories early in
development

11. Why User Stories are so Good?
•
•
•
•
•
•
Understood equally well by everyone
Useful for iteration planning
Great for iterative development
Encourage deferring of details
Support opportunistic design
Emphasize verbal communication

12. The 3 C's

13. What is a Story Card?
• Short description of user or customer valued
functionality.
• The visible part of a story, which is followed by
conversations between the customer and the project
team and confirmation of acceptance criteria.
– The customer team writes the story cards because they
are in the best position to express the desired features
and because they must later be able to work out story
details with developers and to prioritize the stories.
– The customer team includes those who ensure that the
software will meet the needs of its intended users. This
may include testers, product manager, real users and
interaction designers.

14. User Story - INVEST guideline

15. User Story - INVEST guideline

16. User Story-INVEST guideline

17. User Story - INVEST guideline

18. User Story- INVEST guideline

19. User Story - INVEST guideline

20. Story form/template I
As a < role >
I want < activity >
so that < business value >
• Role - represents who is performing the action. It should be
a single person, not a department. It may be a system if
that is what is initiating the activity.
• Activity – represents the action to be performed by the
system.
• Business Value – represents the value to the business.
Why is this story important?

21. Story form/template I
• The "role – activity – business value"
template is one of the most commonly
recommended aids for teams and product
owners starting to write user stories.
As a bank customer
I want to withdraw money from an ATM
So that I’m not constrained by opening hours or
lines at the teller’s

22. User Story form/template I
"As a < role >, I want < goal/desire > so
that <benefit> "
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.

23. User Story form/template II
"As a < role >, I want < goal/desire > "
so that <benefit> can be optional
As a non-administrative user,
I want to search for my customers by their first
and last names.

24. User Story form/template III
"In order to < receive benefit > as a < role >, I
want < goal/desire > "
In order commissions would be calculated
differently to each agency,
as I accountant
I want system to allow me to set up these values
manualy in commisions tab

25. User Story form/template IV
"As < who > < when > < where >, I want
<what> because < why >"
As a accountant who is managing policy commisions,
I want commisions to be calculated,
because we need use different rates for different
aggencies

26. Acceptance/Validation
criteria
•
•
•
•
like stories it's written in simple language
define the conditions of success/satisfaction
provide clear user story boundaries
remove ambiguity by forcing the team to think
through how a feature or piece of functionality
will work from the user’s perspective
• establish the basis for acceptance testing
– steps to test the story (given-when-then scenarios)

27. Acceptance Test form/template
The Given-When-Then formula is a template intended to guide the
writing of acceptance tests for a User Story:
(Given) some context
(When) some action is carried out
(Then) a particular set of observable consequences should be
obtained
Given my bank account is in credit,
When I attempt to withdraw an amount less than my
card’s limit,
Then the withdrawal should complete without errors or
warnings

28. Skill levels of Agile Team
An Agile team will benefit if the skills
that underpin effective use of user
stories are widely distributed among the
team.
– It is likely that people with background in
"requirements analysis" or with a history in
"analyst" roles will have a leg up in acquiring
these skills.

29. Skill Levels of an Agile Team
• Beginners
– the team is able to obtain, "just in time", the information
necessary to implement user stories, for instance by
having access to the product owner or domain expert
• Intermediates
– the team formalizes all activity as work on user stories,
each team member can answer at any moment the
question "what user story are you working on at the
moment“
• Advanced
– at any moment, any member of the team can answer the
question "what is the most important user story in the
backlog, and why"

30. Skill levels of an Individual Contributor
• Beginner
– able to illustrate a user story with an example (including
user’s goal, existing context, user’s actions and expected
outcomes)
• Intermediate
– knows or can identify the relevant user roles and
populations and refers to them appropriately in user
stories
• Advanced
– can assess a user story using the INVEST checklist or an
equivalent, and rephrase or split the user story as
necessary

31. Non-Functional Requirements
Do User Stories Really Help?
• Agile teams focus on identifying User Facing
Features in the form of User Stories that can
form the basis of incremental deliveries.
– Business Analysts work closely with stakeholders to
understand what user stories must be satisfied by
the product that they are developing.
• A flaw in this approach can be that users don’t
mention non-functional requirements (NFRs)
and developers don’t push to understand what
quality attributes the software should satisfy.

32. Consider Non-functional Requirements
from the Start
Most software systems are in use for many more times
longer than they take to build. So you need:
• Start conversations about the operating environment
and user expectations early.
• Talk about the quality capabilities of the system, like
performance and security, at the start of the project.
• Hold a session with the team to brainstorm risks to
consider what are the things that can go wrong once
the system is live?

33. Types of Non-functional Requirements
Basically, non-functional requirements relate
to qualities of the system that cut across user
facing features, such as availability,
efficiency, flexibility, portability, security,
performance, reliability, reusability,
robustness, scalability, usability.
—However, these requirements do affect the
function of the system and it is possible to design
tests that these qualities are present.

34. The difference from functional
requirements
•
The difference from functional requirements
is that these qualities must be present
throughout the system rather than delivered
in one-shot like a user facing feature.
 Alternative terms for non-functional
requirements are "constraints", "quality
attributes", "quality goals" and "quality of
service requirements".

35. NFRs Can be Grouped Into
• Execution qualities, such as performance and usability,
which are observable at run time.
• Evolution qualities, such as testability, maintainability,
extensibility and scalability, which are embodied in the
static structure of the software system.
Agile teams need to consider both categories of NFRs so
how do we ensure that these don’t get missed?

36. Who should have take responsibility?
•
When
asked
for
user
stories,
stakeholders often forget to mention the
NFR assuming that these will simply be
there.
Unfortunately, the agile team cannot
telepathically know what the business needs
and when pressure seems to be about
delivering features consideration of NFRs gets
neglected.

37. Agile Team should Take Responsibility
"Many development teams don't grasp the fact that
accountability for getting the requirements (all the
requirements) right falls to them." Dave Nicolette
• An agile team has to take a more proactive role regarding
requirements.
– User stories are not simply mini-requirements specifications
that are handed over to development fully formed.
– Writing stories on cards is a very interactive process that
involves the technical team asking questions about acceptance
criteria that includes NFR.
We must take responsibility for flushing out NFRs
so first tip for capturing NFR is to actively start looking
for them!

38. Using Stories for Non-Functional
Requirements
As a < user role > I want < goal > so that
< business value >
• Some teams like to use this template for everything that
they work on including NFR because that's a consistent
format.
– Shaping NFR into user stories helps people outside the team
understand the benefits better.
• This can become a disadvantage, if these requirements may
be seen by business stakeholders as optional or "nice to
have".
– It’s important to include the "so that" part to make it easy to see
why such NFR stories are important from a business perspective
to help ensure that they don’t get de-prioritized simply because
they are not understood.

39. Using Stories for Non-Functional
Requirements
• Usually agile teams keep it simple and simply
factor NFR into acceptance criteria for affected
user stories.
• This effectively makes work on NFR invisible.
– The odd thing about doing this is that any stories
which imply significant architecture work have higher
estimates than others but because the architectural
piece is below the surface it the estimate belongs to
whichever story that gets worked on first. This can be
difficult to explain to stakeholders.

40. Using Stories for Non-Functional
Requirements
• Another approach is to introduce "technical stories" to cover
anything that needs to be built or restructured but is too difficult to
explain to business people.
• The developers are trusted to include only those technical stories that make
sense often working within an allowance of such stories per iteration.
• The benefit is that these don’t get de-prioritized by business people and yet
these stories explicitly appear on the team board and progress on them gets
discussed in daily stand-up meetings.
• This approach is often popular for teams working on legacy systems with many
complexities that need to be cleaned up and made testable.
• One worry with this approach is that this excludes the business
from deciding what the project budget is spent on.
"Try to avoid tech stories. Look hard for a way to transform a tech
story into a normal story with measurable business value. That way
the product owner has a better chance to make correct tradeoffs."
Henrik Kniberg’s

41. The beauty of User Stories for
Non-Functional Requirements
approach
Is that all requirements (functional and non-functional):
Look the same
Can be understood by everyone
Have the same visibility as other stories
This approach is that normally elaborating
requirements as user stories help a agile team
understand user needs better.

42. Non-functional Requirements
examples
• Efficiency: Specifies how well the software utilizes
resources (CPU cycles, disk space, memory)
• Flexibility: Increase or extend the functionality of the
software after it is deployed, that should be planned
from the beginning; it influences choices made
during the design, development, testing, and
deployment of the system.
• Portability: Portability specifies the ease with which
the software can be installed on all necessary
platforms.

43. Non-functional Requirements
examples
• Security: Security requirements define the security
attributes of the system, restricting access to features
or data to certain users and protecting the privacy of
data entered into the software.
• Performance: The performance constraints specify
the timing characteristics of the software.
• Usability: Ease-of-use requirements address the
factors that constitute the capacity of the software to
be understood, learned, and used by its intended
users.

44. How do we gather user stories?

46. Trawling for Requirements

47. User Proxies

48. Customer Team

49. User Role Modeling

50. User Role Modeling Steps
1.
2.
3.
4.
Brainstorm an initial set of user roles
Organize the Initial Set
Consolidate Roles
Refine the Roles

51. Refine User Roles with Attributes

52. User Role Example

53. Where are the Details?

54. Details added as smaller User Stories

55. Details as conditions of Satisfaction/
Acceptance Criteria

56. Types of User Stories

57. The Backlog Iceberg

58. Breaking Down Epics

61. User stories vs. use cases
User Stories
Use Cases
• Provide a small-scale and easy-touse presentation of information. Are
generally formulated in the everyday
language of the user and contain little
detail, thus remaining open to
interpretation. They should help the
reader
understand
what
the
software should accomplish.
• Must be accompanied by
acceptance
testing
procedures
(acceptance criteria) for clarification
of behavior where stories appear
ambiguous.
• Describe a sequence of interactions,
and may be worded in terms of a
formal model. A use case is intended
to provide sufficient detail for it to be
understood on its own. A use case
has been described as “a generalized
description of a set of interactions
between the system and one or more
actors, where an actor is either a user
or another system”.
May be delivered in a stand-alone
document.

62. Software Requirements Specification
IEEE 830
• The Computer Society of the Institute of Electrical and
Electronics Engineers (IEEE) has published a set of
guidelines on how to write software requirements
specifications. This document, known as IEEE Standard
830, was last revised in 1998.
• The IEEE recommendations cover such topics as:
–
–
–
–
how to organize the requirements specification document;
the role of prototyping;
the characteristics of good requirements;
Recommended way to write functional requirements is
“The system shall…” .

63. Software Requirements Specification
IEEE 830
• IEEE 830–style requirements have sent many
projects astray because they focus attention
on a checklist of requirements rather than on
the users goals.
– And lists of requirements don't give the reader the
same overall understanding of a product that user
stories do.
• It's very difficult to read a list of requirements
without automatically considering solutions
in your head as you read.

64. SRS IEEE 830 examples:
• The system shall allow a company to pay for a
job posting with a credit card.
• The system shall accept Visa, MasterCard, and
American Express cards.
• The system shall charge the credit card before
the job posting is placed on the site.
• The system shall give the user a unique
confirmation number.

65. Software Requirements Specification
IEEE 830
• Documenting a system's requirements to this level is
tedious, error-prone, and very time-consuming.
– Additionally, a requirements document written in this way
is, quite frankly, boring to read.
– Just because something is boring to read is not sufficient
reason to abandon it as a technique; however, if you're
dealing with 300 pages of requirements like this (and that
would only be a medium-sized system), you have to
assume that it's not going to be read thoroughly by
everyone who needs to read it. Readers will either skim or
skip sections out of boredom.
Additionally, a document written at this level
will frequently make it impossible for a
reader to grasp the big picture.

66. Software Requirements Specification
IEEE 830
• A powerful and important feedback loop occurs when
users first see the software being built for them. When
users see the software, they come up with new ideas and
change their minds about old ideas.
• When changes are requested to the software contemplated
in a requirements specification, we've become accustomed
to calling it a “change of scope.”
– This type of thinking is incorrect for two reasons. First, it implies
that the software was at some point sufficiently well-known
for its scope to have been considered fully defined.
• It doesn't matter how much effort is put into upfront thinking about
requirements; we've learned that users will have different (and
better) opinions once they see the software.
– Second, this type of thinking reinforces the belief that software
is complete when it fulfills a list of requirements, rather than
when it fulfills the goals of the intended user.

67. Differences Between User Stories and
SRS IEEE 830
The cost of each requirement is not made visible until all the
requirements are written.
• With stories, an estimate is associated with each story
immediately.
– The typical SRS IEEE 830 scenario is that one or more analysts spends a
lot of time writing a lengthy requirements document.
– This document is then handed to the programmers, who tell the
analysts that the project will take longer as had hoped for. In this case,
time was wasted writing the document that the team won't have
time to develop, and more time will be wasted as the developers,
analysts, and customer iterate over which functionality can be
developed in time.

68. Tips for Writing Good Stories

69. Smelly user Stories

71. Literature
•
•
•
•
•
•
•
•
•
•
•
•
Mike Cohn, "User Stories Applied", 2004, Addison Wesley, ISBN 0-321-20568-5
http://www.powershow.com/view/143a1fMzFjO/User_Stories_Applied_For_Agile_Software_Development_by_Mike_Cohn_
powerpoint_ppt_presentation
http://www.slideshare.net/dneighbors/effective-user-stories-10265381
http://www.slideshare.net/dimka5/agile-stories-estimating-and-planning
http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html
http://guide.agilealliance.org/guide/stories.html
http://www.methodsandtools.com/archive/archive.php?id=113
http://broadcast.oreilly.com/2010/02/nonfunctional-requirements-how.html
http://en.wikipedia.org/wiki/Non-functional_requirement
http://en.wikipedia.org/wiki/User_story
http://guide.agilealliance.org/guide/stories.html
http://www.mountaingoatsoftware.com/articles/advantages-of-user-stories-forrequirements

72. Material For Further Reading
• http://www.agilemodeling.com/artifacts/userSto
ry.htm
• http://www.mountaingoatsoftware.com/articles/
advantages-of-user-stories-for-requirements
• http://www.mountaingoatsoftware.com/blog/no
n-functional-requirements-as-user-stories
• http://vimeo.com/43601248
• http://www.math.uaa.alaska.edu/~afkjm/cs401/I
EEE830.pdf