This is a guide to user stories

1. SYSANDE
Analysis and
Design
ROMMEL L. DORIN

2. Theme vs Epics vs User stories
Products are typically described by hundreds of
requirements which are organized in the product
backlog. Theme or epics cannot be completed in
one sprint so they are broken into more user
stories and subsequently a group of related
tasks. Epics are then delivered in releases. But
even small user stories from different epics can
have something in common. Such a group of
user stories is called a theme.

3. Process

4. Theme vs Epics vs User stories

5. Theme vs Epics vs User stories
 A theme provides a convenient way to indicate that a set
of related epics have something in common, such as
being in the same functional area.
 An Epic is useful as placeholders for large
requirements. Epics are usually defined during the initial
product roadmap and decomposed into stories.
 User stories are the smallest units of user functionality.
 Tasks are decomposed parts of a story that get into
HOW the story will be completed. Tasks can be hour
estimated if desired.

8. Process

12. Example

13. User Stories Mapping
A user story map captures the journey a
customer takes with the product including
activities and tasks they perform with the
system. Creating a story map
collaboratively ensures team members are
on the same page from the start of the
project through to the ongoing
development of new releases.

14. User Stories Mapping

15. Epic

16. User Stories

17. User Stories

18. Introduction
18
A user story is a tool used in
Agile software development to capture
a description of a software feature from
an end-user perspective. The user
story describes the type of user, what
they want and why. A user story helps
to create a simplified description of a
requirement.

19. User Story
19
User Story Template:
As a <role>, I want <feature> so that
<reason>.

20. User Story
20

22. User Story
22
Examples of user stories are:
As a user, I want to upload photos so that I
can share photos with others.
As an administrator, I want to approve
photos before they are posted so that I
can make sure they are appropriate.

23. User Story
23
 Using Index Card

24. User Story
24
Conditions of Satisfaction
The conditions of satisfaction is simply a high-level
acceptance test that will be true after the agile user
story is complete.

25. User Story
25
Example No. 1:
As a vice president of marketing, I want
to select a holiday season to be used
when reviewing the performance of
past advertising campaigns so that I
can identify profitable ones.

26. User Story
26
Condition of Satisfaction
Make sure it works with major retail
holidays: Christmas, Easter,
President’s Day, Mother’s Day,
Father’s Day, Labor Day, New Year’s
Day.
Support holidays that span two
calendar years (none span three).

27. User Story
27
Condition of Satisfaction
Holiday seasons can be set from one
holiday to the next (such as
Thanksgiving to Christmas).
Holiday seasons can be set to be a
number of days prior to the holiday.

28. User Story
28
Example No. 2:
As a conference attendee, I want to be
able to register online, so I can register
quickly and cut down on paperwork.

29. User Story
29
Questions for the Product Owner might
include:
 What information needs to be collected to allow
a user to register?
 Where does this information need to be
collected/delivered?
 Can the user pay online as part of the
registration process?
 Does the user need to be sent an
acknowledgment?

30. User Story
30
Acceptance Criteria
 A user cannot submit a form without
completing all the mandatory fields.
 Information from the form is stored in the
registrations database.
 Protection against spam is working.
 Payment can be made via credit card.
 An acknowledgment email is sent to the
user after submitting the form.

31. User Story
31
Example No. 3:
As a recurring customer, I want to re-
order items from my previous orders so
I don’t have to search for them each
time.

32. User Story
32
Acceptance Criteria
 AC1. Order history option is displayed on
accounts page.
 AC2. Previously purchased items are
displayed when clicking on order history.
 AC3. User may add previously ordered
items to the cart.

33. User Story
33
Example No. 4:
‘As a user I want to sign in to the site
from a login page so that users can be
authenticated.’

34. User Story
34
Acceptance Criteria
 On the sign-in page I can enter my email
address and password and submit it for
authentication.
 My password needs to follow the company
password policy for secure passwords
 Upon successful login, I am re-
directed to the homepage.

35. User Story
35
Acceptance Criteria
 If I enter an incorrect username and or
password I should see an appropriate
error message indicating my credentials
are incorrect.
 I should be able to retry authenticating
myself three times before I am locked out
of my account and must reset my
password to unlock my account.

36. User Story
36
Acceptance Criteria
 I must also see a link which allows me to
reset my password.
 I must also see a link which allows me to
register is I am a new user.
 I must see a CAPTCHA to protects the site
against bots

37. Acceptance Criteria
37
“Acceptance Criteria should not go
beyond the scope of the user story, if so
then additional user stories need to be
captured that define the feature ‘wants’.”
Acceptance criteria define the
boundaries of a user story, and are
used to confirm when a story is
completed and working as intended.

38. Acceptance Criteria
38
Guidelines in making Acceptance
criteria:
 Focus on the what and not the how – the
team is not looking for a ‘solution’ from you
as the product owner, just the ‘what’ is it
that you are asking of the user story.
 Keep the end user (and user acceptance
testing) firmly in focus, it’s their point of
view and value you are representing.

39. Acceptance Criteria
39
Guidelines in making Acceptance
criteria:
 Develop acceptance criteria as a
set of statements, each clearly stating a
pass/fail outcome.
 Specify both functional and non-
functional requirements.

40. Acceptance Criteria
40
Guidelines in making Acceptance
criteria:
 What are your security and performance
requirements, need it be real time data
display? Is the data sensitive?
 Start with a sketch of what you are asking
for, remember a picture paints a thousand
words!

41. Acceptance Criteria
41
Guidelines in making Acceptance
criteria:
 There is no such thing as
partial acceptance: either the
acceptance criteria is met or it is not.
 What is your user story? Think about what
your want is? Can it be visually displayed?
Is it related to display of data? Sketch out
the different data entities (columns) you
want to see, do you need to sort the

42. Acceptance Criteria
42
Guidelines in making Acceptance
criteria:
 What is your user story? Think about what
your want is? Can it be visually displayed?
Is it related to display of data? Sketch out
the different data entities (columns) you
want to see, do you need to sort the
display/view of data? Think it through in
detail.

43. Acceptance Criteria
43
Guidelines in making Acceptance
criteria:
 Is it a form to capture data? What data
entities do you want captured? In what
format? Think about what you don’t want
in those fields (restricting input types), how
would you validate the entries, what are
the validation business rules?

44. User Stories

45. User Stories
Prioritization

46. User Stories
Prioritization

47. User Stories
4 Types of User Stories in terms of complexity

48. User Stories

49. User Stories

50. User Stories

51. User Stories

52. User Stories

53. User Stories

54. User Stories

55. User Stories

56. User Stories

57. Wireframing
 Wireframing is a way to
design a website service
at the structural level.
A wireframe is
commonly used to layout
content and functionality
on a page which takes
into account user needs
and user journeys.

58. Wireframing
The designs you received are called wireframes
(sometimes called wires, mockups, prototypes or
mocks).
A wireframe is a schematic, a blueprint, useful to
help you and your programmers and designers
think and communicate about the structure of
the software or website you're building.
2 Types – Lo and Hi

59. Wireframing
 What is Fidelity?
 Prototypes don’t necessarily look like final products — they can
have different fidelity. The fidelity of a prototype refers to how it
conveys the look-and-feel of the final product (basically, its level of
detail and realism).
 Fidelity can vary in the areas of:
a. Visual design
b. Content
c. Interactivity
 There are many types of prototypes, ranging anywhere between
these two extremes:
a. Low-Fidelity
b. High-Fidelity

60. Wireframing
 Low-fidelity Prototypes
 Low-fidelity (lo-fi) prototypes is a quick and easy way to
translate high-level design concepts into tangible and testable
artifacts. The first and most important role of lo-fi prototypes is
to check and test functionality rather than the visual
appearance of the product.
 Here are the basic characteristics of low-fidelity prototyping:
 Visual design: Only some of the visual attributes of the final
product are presented (such as shapes of elements, basic
visual hierarchy, etc.).
 Content: Only key elements of the content are included.
 Interactivity: The prototype can be simulated by a real human

61. Wireframing
 Popular example: Paper prototyping

62. Wireframing
 Popular example:
Clickable wireframe

63. Wireframing
 High-fidelity prototyping
 High-fidelity (hi-fi) prototypes appear and function as similar as
possible to the actual product that will ship. Teams usually create
high-fidelity prototypes when they have a solid understanding of
what they are going to build and they need to either test it with
real users or get final-design approval from stakeholders.
 The basic characteristics of high-fidelity prototyping include:
 Visual design_:_ Realistic and detailed design — all interface
elements, spacing, and graphics look just like a real app or
website.
 Content: Designers use real or similar-to-real content. The
prototype includes most or all of the content that will appear in
the final design.
 Interactivity: Prototypes are highly realistic in their interactions.

64. Wireframing
 Popular example: Digital Tool

69. Class on Thursday
Topics:
Project Management
Data Flow Diagrams