The document provides information on user stories, including their elements and examples. It discusses product backlogs, themes, epics, user stories, tasks and how they relate. It also covers acceptance criteria, estimating stories in points and calculating team velocity. Bad user stories are identified as ones that are non-independent, too large, lack value or are non-negotiable. The document emphasizes that user stories should provide value to users and be written from their perspective.

1. Session 15 + 16: User Story
R2S Academy – Internal Use – Author: TUAN NGO

2. Table of Content
Product Backlog
User Story
Examples & Exercises
R2S Academy – Internal Use – Author: TUAN NGO
1
2
3
Objectives

3. Backlog
Product Backlog / Sprint Backlog
User Story

4. User Story
Product Backlog

5. Backlog (Product Backlog)
ü Lists and prioritizes the feature-level details required to execute
the strategic plan in the roadmap
ü Communicates what’s next on the development team’s to-do list as
they execute on the roadmap’s big-picture vision. It is a giant to-do
list for development team
ü Translates how your team will deliver the vision outlined on an agile
roadmap
User Story
Product Backlog

6. Product backlog includes different items:
1. New features
2. Infrastructure updates
3. Changes to existing functionalities
4. Bug fixes
5. Technical debt and refactoring
User Story
Product Backlog

7. User Story
Product Backlog
Jira – Backlog

8. User Story
Product Backlog
Azure DevOps (ADO) – Backlog

9. User Story
Product Backlog
Team Foundation Server (TFS) – Backlog

10. Sprint Backlog
User Story

11. Sprint Backlog
ü The sprint backlog is a list of tasks identified by the Scrum
team to be completed during the Scrum sprint
ü During the sprint planning meeting, the team selects some
number of product backlog items, usually in the form of user
stories, and identifies the tasks necessary to complete each
user story
ü Most teams also estimate how many hours each task will take
someone on the team to complete
User Story
Sprint Backlog

12. User Story
Sprint Backlog

13. User Story
Sprint Backlog

14. User Story
Theme / Epic / User Story (US) / Task
User Story

15. User Story
Theme / Epic / User Story / Task
Task 1
Task 2
Task 3
…
Task 1
Task 2
Task 3
…

16. Theme
ü A theme indicate a set of related epics have something in
common, such as being in the same functional area
ü By assigning a financial value to Themes, managers can ensure
the highest value is being delivered and that the project is
aligned with its objectives and the strategic direction of the
organization
User Story
Theme / Epic / User Story / Task

17. Epic
ü An Epic is useful as placeholders for large requirements. It
probably won’t fit into a sprint and should be broken down
into stories.
ü Epics are usually defined during the initial product roadmap
and decomposed into stories in the product backlog as more
is learned and is usually written in a User Story format.
ü The decomposed stories in an epic have a common objective
and a specific outcome or high-level user need or part of the
journey or process someone takes in using the service
User Story
Theme / Epic / User Story / Task

18. User story / Product backlog item / Work item
ü User stories are the smallest units of user functionality in Agile
which can be delivered in one agile sprint.
ü They are typically estimated using story pointed and defined
using INVEST criteria
ü A user story must deliver particular value to the user and must be
describable in simple language that outlines the desired outcome
User Story
Theme / Epic / User Story / Task

19. Task
ü Tasks are decomposed parts of a story that get into HOW the
story will be completed
ü Tasks can be hour estimated if desired. Tasks are usually
defined by the people doing the work (developers, QA, etc).
Thus, the tasks no longer need to be understandable by
business users and so can be highly technical
ü The process of breaking a story down into tasks also helps the
development team better understand what needs to be done
User Story
Theme / Epic / User Story / Task

20. User Story
Theme / Epic / User Story / Task

21. Example 1
User Story
Theme / Epic / User Story / Task

22. Example 2
User Story
Theme / Epic / User Story / Task

23. Example 3
User Story
Theme / Epic / User Story / Task

24. User Story
Elements
1. "As a <user role>": Who are we building this for?
2. “I want <goal>”: Here we’re describing their intent. What is it they’re
actually trying to achieve? This statement should be implementation free
3. “so that <benefit>”: how does their immediate desire to do something
this fit into their bigger picture? What’s the overall benefit they’re trying
to achieve? What is the big problem that needs solving?
Template: As a <user role>, I can <story> so that <benefit>
As an employee user, I want to post my
resume to the website so that related
employers can view my experiences
As an employer user, I want search
resumes from the website so that I
can decide to hire candidates

25. 4. Acceptance criteria
ü Even though you know what your user wants, you need to be able to say
when the story is complete. The acceptance criteria helps you know when you
have successfully completed the story
ü Acceptance criteria can include details like
§ User experience
§ The current user story’s effect on existing feature
§ A key performance like speed
§ What the user story was intended to do
User Story
Elements

26. 4. Acceptance criteria - Example
ü As a user, I want to access my user account page, so that I update my contact
details at any time
→ AC 1
Given that I am logged in,
When I click on my avatar,
Then the system opens the user account page
→ AC2
Given that I am not logged in,
When I click on the avatar icon,
Then the system opens the log in page
User Story
Elements

27. 5. Additional details of User Story
ü Business rules (AC)
ü Workflows
ü Mockups
ü Algorithms
ü Story points
ü Status
ü Assigned to
User Story
Elements

28. Story Point
User Story

29. User Story
Story Point
We are not good at estimating
We are good at comparing

30. User Story
Story Point

31. User Story
Story Point

32. User Story
Story Point & Velocity

33. User Story
Team Velocity
Team velocity report
Sprint report

34. Examples
User Story

35. User Story
Examples
Example 1
As a signed in user, I want to able to comment a feed on a post so that I can get
feedback from others.
Acceptance Criteria
§ Display comment icon below the post
§ Display list of comments from other users
§ Display keypad when the user clicks on the comments icon
§ User should be able to type a comment in the textbox after clicking on comment icon
§ User can click on “Post” button to save comment
§ “Post” button should be inactive when nothing is typed
§ “Post” button becomes active after user starts typing
§ Display users comment in the list of comments
§ Display “profile picture” and “username” to the left of the comment
§ Display “remove” and “edit” icons opposite to the comment

36. User Story
Examples
Example 2
As an iPhone user, I can share photos I have taken with my friends so that we
can decide on what color to paint the new office
Acceptance Criteria
§ I can select photos I have already got store on my phone
§ I can share more than one photo at a time
§ Sharing the photos takes no more than 1 second per photo

37. User Story
Examples
Example 3
As a customer, I want to sign up for a mailing list, so that I can be notified of
daily restaurant specials.
Acceptance Criteria
§ I can see the sign-up form on the website and add their email address.
§ I can receive confirmation message on the web page that their email
address has been added.
§ I can receive a confirmation email that they have been added to the
mailing list.

38. User Story
Examples
Example 4
As an Account Manager, I want a sales report of my account to be
sent to my inbox daily so that I can monitor the sales progress of my
customer porfolio.
Acceptance Criteria
û The report is sent daily to my inbox.
û The report contains the following sales details: …
û The report is in csv format

39. Example 5
User Story
Examples

40. User Story
Examples
Example 6
As a writer, I want to receive notifications when others add comments so that I
am up-to-date.
Acceptance Criteria
û Given I don't have app open when my phone is locked then I should
receive a banner notification.
û Given I have the app open when I am writing on the doc then the bell icon
should update to show unread notifications with count.
û Given a user was mentioned in a comment using @ mention when the
mentioned user is reading the comments then a flash message should
show up on the same comment thread with a message notifying about
the new comment.

41. Good & Bad User Story
User Story

42. User Story
Good User Story
ü Independent – Độc lập
ü Negotiable – Đàm phán được
ü Valuable – Đáng giá
ü Estimable – Ước tính được
ü Sized appropriately / Small – Kích thước phù hợp
ü Testable – Kiểm thử được

43. 1. Excessive ‘So That’ (Misplaced Requirement)
As a food service customer I need to save my list so that later I can save a copy,
print, or email the list for other uses.
→ If the ability to copy, print, and email a list is what the product owner really
wants, it would be too big - a compound user story made up of many pieces.
2. Ultra-Huge Story
As a food service customer, I need to save, copy, print, and email my list so that
I can edit it again, check a received shipment against a printed list, and send the
list to a restaurant.
→ This is hard to estimate and hard to implement in a sprint. It’s difficult to see
the value that holds this story (or epic) together. Stories containing “and” or “or”
are likely candidates for splitting into several smaller stories
User Story
Bad User Story

44. 3. Waterfall
As a developer, I want to finalize the database table changes and additions for
the release so that we don’t have to make changes to the model later.
→ This story has no business value and a user (“developer”) who is not really a
system end user. There is only the technical side of the equation. Remove it!
4. Rigidity (Inflexible)
As a food service customer, I want to see different food item types displayed in
different colors—RGB = #FF0000 for meats, #A52AFA for grains, and #808000
for vegetables —so that I can quickly identify my food items by food type.
→ There may be better solutions that leave more flexibility, like using general
colors or using intent of the colors rather than the color themselves.
User Story
Bad User Story

45. 5. Non-User
As the system, I need to store customer account info and their order lists in the
database.
→ This story doesn’t deliver any value to the end user. Manny’s users cannot
directly use the database.
6. No Value
As a customer ordering food, I want to locate previous food order lists so that I
can see all the lists that I have.
→ This story doesn’t explain its value. Why does the customer ordering food
need to see lists? The answer could influence the usability.
User Story
Bad User Story

46. 7. Techie Value
As a tester, I want to have detailed test plans so that when the system is
completed, I can test the system.
→ The improvement would be to delete this story. Part of the team’s test plan
should be found in the acceptance criteria for each story.
Beware of user stories where “so that” is a technical capability, not any value
to the end user. This is very similar to no business value, but the value listed is
technical.
User Story
Bad User Story

47. Practice
Jira / Azure DevOps / Trello
User Story

48. Practice
Jira
https://www.atlassian.com/

49. Practice
Azure DevOps
https://dev.azure.com/

50. Practice
Trello
https://trello.com/

51. Session 15 Review
User Story

52. User Story review questions:
1. What is Acceptance Criteria?
2. How to calculate Scrum team velocity?
3. What’s wrong in the below User Stories:
§ “As a librarian, I can search quickly any book by title and publisher name”
§ “As a content manager, I want a text editor so that I can edit text”
§ “As a tester, I can access the website on the staging server so that I can create data for testing purpose”
User Story
Session Review