Learn to use the user story backlog as a way to describe user’s experience with your product. Section 1: Importance of Product Owners Roll.  Identifying Scrum’s Product Owners roll.  Diagrammatic representation of PO Activities.  Diagrammatic representation of Product Feature Development tracks. Section 2: User stories & Product Backlog Management.  Agile User Stories overview .  Acceptance Criteria.  Backlog Management. Section 3: Project Scope, Product Backlog and Story Mapping.  User Story Mapping Steps.  Story Mapping example with valuable releases.  Benefits of User Story Mapping.

1. B Y : N . P A U L
T I T L E : P R O J E C T M A N A G E R
Product Backlog mapping
1

2. Goals and Agenda:
Goal: Learn to use the user story backlog as a way to describe user’s
experience with your product.
Section 1: Importance of Product Owners Roll.
 Identifying Scrum’s Product Owners roll.
 Diagrammatic representation of PO Activities.
 Diagrammatic representation of Product Feature Development tracks.
Section 2: User stories & Product Backlog Management.
 Agile User Stories overview .
 Acceptance Criteria.
 Backlog Management.
Section 3: Project Scope, Product Backlog and Story Mapping.
 User Story Mapping Steps.
 Story Mapping example with valuable releases.
 Benefits of User Story Mapping.
2

3. Scrum’s Product Owner Role :
The Product Owner role is generally filled by a single person supported by a collaborative team,
Subject Matter Expert
 Understand the domain well enough to
envision a product .
 Answer technical questions on the
domain for those creating the product.
End User Advocate
 Describe the product with
understanding of users and use, and a
product that best serves both.
Customer Advocate
 Understand the needs of the business
buying the product and select a mix of
features valuable to the customer.
Business Advocate
 Understand the needs of the organization
paying for the software’s construction
and select a mix of features that serve
their goals.
Communicator
 Capable of communicating vision and
intent – deferring detailed feature and
design decisions to be made just in time.
Decision Maker
 Given a variety of conflicting goals and
opinions, be the final decision maker for
hard product decisions.
Section 1
333

4. :- Communicate Business Goals, Customer Goals, End User Goals.
:- Coordinate involvement of SMEs, users, and business stakeholders.
:- Coordinate with other product owners to insure product releases.
Organize the backlog into
incremental releases
Specify objective acceptance
criteria for stories
Create and maintain the
product backlog
Participate daily
Available to answer
questions and
clarifications
Verify stories are done
based on acceptance
criteria
Evaluate product at
end of Sprint and
add or remove
stories from
backlog as
necessary
Section 1
4

5. Product Feature Development tracksProduct
OwnerTeam
Development
Team
Implement iteration
1 features
• Gather user input
for iteration 3
features.
• Design iteration 2
features.
• Support iteration
1 development.
implement iteration
2 features,
fix iteration 1 bugs
if any
• gather user input
for iteration 4
features.
• design iteration 3
features.
• support iteration
2 development.
• validate iteration 1
features.
implement iteration
3 features,
fix iteration 2 bugs
if any
• gather user input
for iteration 5
features.
• design iteration 4
features.
• support iteration
3 development.
• validate iteration 2
features.
• Planning.
• Gather user input
for iteration2.
• Design for iteration
1 features – high
technical
requirements, low
user requirements.
• Development
environment setup.
• Architectural
roadmap design.
Sprint 0 Sprint 1 Sprint 2 Sprint 3
time
supportdev
supportdev
Section 1
5

6. User stories & Product Backlog Management
Agile User Stories:
 Why, What & How.
 What is a story?
○ Story form.
○ Cards - Conversation – Confirmation.
○ Acceptance Criteria.
Product Backlog Management:
 Blitz Planning.
 Product Road Map.
 Project scope, product backlog & Story Mapping.
 User Story Mapping Steps with example.
 Benefits of User Story Mapping
Section 2
6

7. Agile User Stories Overview:
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 (Scrum
Team)
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:
o Slicing user stories down in release planning.
o Tasking user stories out in sprint planning.
o Specifying acceptance test criteria for user stories
early in development.
Section 2
7

8. Agile User Stories Overview:
Story Form
As a < role >
I can < 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?
The 3 C’s
 Card – Write on an Index Card.
 Conversation – Details captured
from conversations
 Confirmation – Acceptance
criteria confirm that the story
is Done.
As a user, I can
login and gain
access to the
intranet, so that I
can collaborate
with all the
organization.
What about
expired accounts?
Can it remember
my login?
1. Fail Expired
accounts.
2. Remember the
login, not the
Password.
3. After 3 attempts
the account is
locked out for 24
hours (SOX
compliance)
Section 2
8

9. Acceptance Criteria:
 It's written in simple language
 Define the conditions of success /
satisfaction.
 Provide clear 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.
 Checklist or template of things to consider
for each story
- list of impacted modules
- Specific user tasks, business process or
functions
 Establish the basis for acceptance testing
- Steps to test the story (given-when-then
scenarios)
- Type of testing (manual vs. automated)
Section 2
9

10. Backlog Management:
 Blitz Planning
 Product Road Map
 Project Scope, Product
Backlog and Story Mapping
with example.
 Benefits of user story
mapping.
Section 2
10

11. Blitz Planning:
Process/Mechanics
 Everyone writes down all the tasks they know of onto index cards and
throws them onto a long table.
 Everyone sorts, adds estimates and notes.
 Look for the Walking Skeleton and the First Delivery.
 Strategize and re-strategize about
roadblocks, costs, time, resources, moving the cards around as we go.
 Some people might see this as an annotated Pert chart, constructed
collaboratively with cards.
Allow 90 minutes : 15 minutes for instructions, 40+ minutes for the
assignment, 20 minutes to discuss, and 15 minutes for variations in the
program.
The logic behind is to see the variations of the project plan grow
under your eyes.
Blitz Planning is also known as Project Planning Jam Session (as in jazz)
Section 2
11

12. Product Road Map:
 A roadmap is a planned future, laid out in broad strokes.
 proposed product releases, listing high level functionality or
release themes with high level target dates.
 Given Intentions for the future about what we know and
believe today - they are not commitments.
 Should be formulated by first understanding the target users, the
market, and the underlying technologies.
 Short development cycles and repeated prioritization of functionality
in the product backlog clashes with a long term product map – in
general making a long range roadmap has always been a challenge.
 Forms an integral part of any product strategy and provide the
framework for plan changes and the impact they would
have on the product.
 A good product roadmap should invariably deliver the right
products with the right features at the right time to the right
customers.
Section 2
12

13. Project Scope, Product Backlog and
Story Mapping
• Project Scope: Can be expressed as “scope and vision
statement”, “operational concept”, “statement of work” (SOW).
OR, As a Work breakdown structure (WBS)/ Product breakdown
structure (PBS) or a Product backlog. In general – WBS
expresses the SOW as activities – PBS/Backlog expresses SOW
as features.
• Product Backlog: A typical Scrum backlog comprises
different types of items like Features, Bugs, Technical
work, Knowledge acquisition etc. Because there's really no
difference between a bug and a new feature, each describes
something different that a user wants, bugs are also put on the
Scrum product backlog.
• Story Mapping: Building or arranging user stories into a
helpful shape which is more useful can be treated as User Story
Map.
Section 3
13

14. User Story Mapping Steps
Step1: Place activities – big user stories (UX), Epics (Mike Cohn)
– at the top.
 An activity is something people do –
 Has lots of steps, and
 Doesn't always have a precise workflow.
 E.g. Building an email system.
 Managing email.
 Configuring email servers.
 Setting up out of office responses.
 Activities provide the context.
Step2: Break activities down into user tasks i.e. smaller stories
 E.g. Read Message, Send Message, Delete Message etc.
 A user task is something that someone does to reach a
goal.
Step3: Move from left to right and top to bottom.
Section 3
14

15. User Story Mapping Steps
Step4: Arrange stories in the logical order in which
they would be completed – grid form.
Step5: Test your map.
 Discussion / walk it through.
 Analyzing and finding things we have
missed.
Step6: Annotate it.
Step7: Use different color for different levels.
Step8: Display it as a information radiator.
 Use for sprint or iteration planning.
 Mark of progress.
Section 3
15

16. E.g. Building an email system
Section 3
User Activities /
Backbone /
Epics
Tasks / Walking
Skeleton
User Stories /
Sub-tasks
Sprint 0
Sprint 1
Sprint 2
Sprint 3
16

17. Benefits of User Story Mapping
 Allows you to see the big picture in your backlog.
 Provides a better tool for making decisions about
grooming and prioritizing the backlog.
 Promotes silent brainstorming and a collaborative
approach to generating user stories.
 Encourages an iterative development approach where
early deliveries validate your architecture and solution.
 Is a great visual alternative to traditional project plans.
 Is a useful model for discussing and managing scope.
 Allows you to visualize dimensional planning and real
options for your project/product.
Section 3
17

18. QA Session and References.
18
 Official Scrum References:
 http://www.scrumalliance.org/
 http://www.scrum.org/
 http://scrumsource.com/blog/
 http://agileproductdesign.com/
 Next Session:
 Will be declared as soon as possible.