This presentation will help you write great user stories

1. Effective User Story Writing
Ahmed Misbah

2. Agenda
1. Quick Introduction
2. Product Backlog
3. User Stories
4. Acceptance Criteria
5. Evolution of a User Story
6. Effective User Story Writing

3. QUICK INTRODUCTION

4. Agile Framework - Overview

5. Agile Framework - Overview

6. Agile Framework – High Level Breakdown
…..

7. Agile Framework – Events Schedule
Day Event
Sunday Daily Standup (internal)
Monday Daily Standup
Tuesday Daily Standup
Wednesday Daily Standup
Backlog Grooming/Bug Review
Thursday Daily Standup
Sunday Daily Standup (internal)
Monday Daily Standup
Tuesday Daily Standup
Wednesday Daily Standup
Backlog Grooming/Bug Review
Thursday Sprint Review
Sprint Retrospective
Sprint Planning

8. PRODUCT BACKLOG

9. Product Backlog
In the simplest definition the Scrum Product
Backlog is simply a list of all things that needs to
be done within the project. It replaces the
traditional requirements specification artifacts
(e.g. SRS document)
https://www.scrum-
institute.org/The_Scrum_Product_Backlog.php

10. Product Backlog (cont’d)
The agile product backlog in Scrum is a
prioritized features list, containing short
descriptions of all functionality desired in the
product.
https://www.mountaingoatsoftware.com/agile/
scrum/scrum-tools/product-backlog

11. Product Backlog (cont’d)
The product backlog comprises an ordered list
of product requirements that a scrum team
maintains for a product.
These will define features, bug fixes, non-
functional requirements, etc. (i.e. whatever must
be done to successfully deliver a viable product).
https://en.wikipedia.org/wiki/Scrum_(software_d
evelopment)#Product_backlog

12. Product Backlog (cont’d)
The product backlog is what will be delivered,
ordered into the sequence in which it should be
delivered. It is visible to everyone but may only be
changed with the consent of the product owner,
who is ultimately responsible for ordering product
backlog items for the development team to
choose.
https://en.wikipedia.org/wiki/Scrum_(software_d
evelopment)#Product_backlog

13. Product Backlog Characteristics
1. Only entries that add value
2. Living Document
3. Different Level of details
4. No low level tasks
5. Ordered
6. Estimated

14. Product Backlog Items
Product Backlog Items can range from
specifications and requirements, to use cases,
epics, User Stories, bugs, or timeboxed research
tasks. Each PBI must have these qualities:
• Description: What the goal of the PBI is.
• Value: the Business Value of the PBI as
determined by the Product Owner.
• Estimate: the Team needs to estimate the relative
effort it will take to move the PBI to Done.
• Order: The Product Owner needs to prioritize
PBIs by their relative value.

15. Product Backlog Items (cont’d)
PBIs could be:
• Epics
• User Stories
• Technical Tasks (described as User Stories)
• Spikes (Knowledge acquisition or research
activity)
• Bugs
• Any item of value to the product

16. USER STORIES

17. User Stories
User stories are short, simple descriptions of a
feature told from the perspective of the person
who desires the new capability, usually a user or
customer of the system.
https://www.mountaingoatsoftware.com/agile/
user-stories

18. User Stories (cont’d)
A user story is a tool used in agile software
development to capture the 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.
https://www.easyagile.com/

19. User Story Template
• Written in the following notation:
– As who
– I want what
– So that why

20. User Story Template (cont’d)

21. User Story Characteristics – Three C’s

22. User Story Characteristics – INVEST

23. User Story Checklist

24. User Story vs. Task

25. ACCEPTANCE CRITERIA

26. Acceptance Criteria
Acceptance criteria or ‘conditions of satisfaction’
provide a detailed scope of a user’s
requirements. They help the team to
understand the value of the story and set
expectations as to when a team should consider
something done.
https://www.easyagile.com/

27. Acceptance Criteria Goals
• To clarify what the team should build before
they start work
• To ensure everyone has a common
understanding of the problem
• To help the team members know when the
story is complete
• To help verify the story via automated tests

28. Examples

29. Examples (cont’d)

30. What should acceptance criteria
include?

31. What acceptance criteria shouldn't
include?

32. EVOLUTION OF A USER STORY

33. Before the Sprint
• Discover: User Mapping Workshop
• Refinement: Definition of Ready

34. During the Sprint
• Sprint Planning
• Daily Scrum
• Acceptance
• Review
• Backlog Grooming
• Retrospective

35. EFFECTIVE USER STORY WRITING

36. Agile Manifesto
Individuals and Interactions over Processes and Tools

37. Agile Principles
4. Business people and developers must work
together daily throughout the project
6. The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation
11. The best architectures, requirements, and
designs emerge from self-organizing teams

38. User Story Template

39. User Story Template (cont’d)

40. Who writes User Stories?
• Anyone can write user stories. It's the product
owner's responsibility to make sure a product
backlog of agile user stories exists, but that
doesn’t mean that the product owner is the one
who writes them. Over the course of a good agile
project, you should expect to have user story
examples written by each team member
• Note that who writes a user story is far less
important than who is involved in the discussions
of it
• Product Owner verifies user stories

41. When are User Stories written?
• User stories are written throughout the agile project.
Usually a story-writing workshop is held near the start
of the agile project. Everyone on the team participates
with the goal of creating a product backlog that fully
describes the functionality to be added over the course
of the project
• Some of these agile user stories will undoubtedly be
epics. Epics will later be decomposed into smaller
stories that fit more readily into a single iteration.
Additionally, new stories can be written and added to
the product backlog at any time and by anyone

42. Story Mapping Workshop
• One of the key objectives of a project inception is
to collect requirements collaboratively
• But, many times, it is difficult to decide where to
start and what to focus on
• Story mapping is an engaging activity where all
participants are involved in the process of
building the product backlog on a wall, versus
writing a dull 100-page requirement document

43. Story Mapping Workshop (cont’d)
Story mapping is a top-down approach of
requirement gathering and is represented as a tree.
Story mapping starts from an overarching vision. A
vision is achieved via goals. Goals are reached by
completing activities. And to complete an activity,
users needs to perform tasks. And these tasks can
be transformed into user stories for software
development.
Story Map Structure: Goals > Activities > Tasks >
Stories

44. Story Mapping Workshop (cont’d)

45. Writing Good User Stories
1. Users come first
2. Use Personas to Discover the Right Stories
3. Create Stories Collaboratively
4. Keep your Stories Simple and Concise
5. Start with Epics
6. Refine the Stories until They are Ready
7. Add Acceptance Criteria
8. Keep your Stories Visible and Accessible
9. Don’t Solely Rely on User Stories

46. Dependency Structure Matrix
• The Dependency Structure Matrix or Design
Structure Matrix (DSM) is a simple, compact,
and visual representation of a system or
project in the form of a square matrix. It is a
great way to visualize and manage
dependencies between modules, which is
critical to the management of software
projects

47. Definition of Ready
• Complete User Story with acceptance criteria
• Meets 3 C’s and INVEST
• Field Description table
• Mockups attached to user story (wireframes in
some cases)
• High Level Test Cases
• DSM
• Workflow Diagrams