The goal of this presentation is to explore the most efficient way to manage the product backlog, using blitz planning, story maps (walking skeleton) and improving the quality of our stories by focusing on stronger acceptance criteria, as well as using personas. The benefit of having a better way to organize and visualize the product backlog is to improve our ability to conduct release and iteration planning, as well as produce a better product road map. By attending this session you will be better equipped to help your team and product owner work with the product backlog. As a project manager, you will be introduced to simple techniques that will help you better manage your Agile project and improve visibility to all the work.

1. Stories, Backlog & Mapping
www.torak.com

2. About Dimitri Ponomareff
www.torak.com
Dimitri Ponomareff (www.linkedin.com/in/dimka5) is a Coach.
Whether it's a sports team, software products or entire
organizations, Dimitri has that ability to relate and energize people.
He is consistently recognized as a very passionate and successful
change agent, with an overwhelming capacity to motivate and
mobilize teams on their path to continuous improvements. He is a
master facilitator, as well as a captivating speaker with consistent,
positive feedback regarding his ability to engage an audience.
As a certified Coach, Project Manager and Facilitator of "The 7 Habits of Highly Effective
People", Dimitri brings a full spectrum of knowledge in his delivery of methodologies. Through
teaching by example, he is able to build teams of people who understand where to focus their work
to generate the most value.
He has coached and provided tailor-made services and training for a multitude of organizations.
The short list includes, American Express, Charles Schwab, Bank of America, Morgan
Stanley, Best Western, Choice Hotels, JDA Software, LifeLock, First Solar, Infusionsoft and
Mayo Clinic. Dimitri enjoys his work, and does everything to ensure he shares his knowledge with
others who seek it.

3. Agile Stories
● Why, What & How
● Work breakdown structure (WBS)
● What is a story?
○ Story form
○ Cards - Conversation - Confirmation
● Story writing workshops
○ Epics and story breakdown
○ INVEST guideline
● Stories vs. Use Cases vs. Requirements
● Product Backlog of stories
● Personas
www.torak.com

4. 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)
www.torak.com

5. Alternative to Work Breakdown Structure (WBS)
Activity
Functionality
Analysis Design Coding Testing
Feature Feature Feature Module Module Module
WBS or traditional projects
Functionality
Activity
Story Story Story Story
Analysis Design Coding
Feature Breakdown Structure
Testing
Define the project plan in terms of what will be delivered rather than what work steps will be
performed.
www.torak.com

6. 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
www.torak.com

7. 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?
www.torak.com

8. Acceptance Criteria
● like stories 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 and/or documents
○ 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)
www.torak.com

9. The 3 C's
1. Card
Written on a card
2. Conversation
Details captured in conversations
3. Confirmation
Acceptance criteria confirm that the story
is Done.
Source: XP Magazine 8/30/01, Ron Jeffries
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.Expired accounts fail
2. Remember the login, not the
password
3. After 3 attempts the account is
locked out for 24h (SOX
compliance)
www.torak.com

10. Story writing workshops
● define clear roles: facilitator and story writer
● include the entire team and anyone who can
express the WHAT aligned to the WHY (subject
matter experts, users, customers, etc...)
○ all participants must stay away from the HOW
○ promote open discussion and use open ended questions
● consider using story-boarding technique
○ work around themes/features
○ begin with the end in mind
● write as many stories as possible, plan for 2-4 hours
○ no need for prioritization
○ high level acceptance criteria
www.torak.com

11. Product, Epics & Stories
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Stor
y
Product
Epics
Stories
www.torak.com

12. Start with Epics and break down into Stories
As a frequent flyer,
I want to rebook a
room I take often
As a frequent flyer,
I want to book a
room using miles
As a frequent flyer,
I want to request an
upgrade
As a frequent flyer,
I want to check if
my upgrade
cleared.
As a frequent flyer,
I want to book a
room.
As a frequent flyer,
I want to check my
account.
As a frequent flyer,
I want to …
Frequent flyer
www.torak.com

13. INVEST guideline from Bill Wake
I - Independent
The user story should be self contained, in a way that there is no inherent dependency on another user story.
N - Negotiable
User stories, up until they are part of a Sprint, can always be changed and rewritten.
V - Valuable
A user story must deliver value to the end user.
E - Estimable
You must always be able to estimate the size of a user story.
S - Sized appropriately
User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of
certainty.
T - Testable
The user story or its related description must provide the necessary information to make test development
possible.
www.torak.com

14. Stories vs. Use Cases vs. Requirements
Stories Use Cases Requirements
Goal generate conversation capture a behavior establish a contract
Scope a single activity
a process
"day in the life"
everything
Format a single sentence numbered bullets specifications
Completeness
open for negotiation and
refinements
locked, changes may impact
entire process
locked, require scope
change and approvals
Language simple, comprehensible structured, flows precise, technical
www.torak.com

15. Personas
● modeling techniques to describe your target audience
○ Behavior patterns
○ Goals
○ Skills
○ Attitudes
○ Motivation
○ Environment
● useful when you don’t have easy access to real users
● help to guide your decisions about functionality and design
● be in your user's shoes - think the way that your users would
● ideal for building test script relying
www.torak.com

16. Backlog Management
● Blitz Planning
● Product Road Map
● Story Mapping
○ The Walking Skeleton
○ Release Planning
● Wireframes
www.torak.com

17. 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
● we look for the Walking Skeleton and the First Delivery
● we strategize and restrategize 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 key 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)
www.torak.com

18. Product road map
● a roadmap is a planned future, laid out in broad strokes
○ proposed product releases, listing high level functionality or release themes, rough
target dates
● intentions for the future given what we know and believe today - they are not
commitments (disclaimer)
● 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 - making a long range roadmap has always
been a real challenge in general
● 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
www.torak.com

19. Product road map example...
www.torak.com

20. Product Backlog of stories
● a list of all desired work on the project
“The requirements”
● owned, managed and prioritized by
the Product Owner
● items estimated by the team
● re-prioritized at the start of each iteration
● ideally expressed such that each item has value to the
users or customers of the product
www.torak.com

21. Story Mapping
Problem
● You have a backlog full of stories.
● You have a set of prioritized features that need to go
out with your next release.
● You are in need of a simple and quick way of viewing
dependencies between stories and mapping features
and tasks to their corresponding stories.
What do story maps do?
● Group related stories together
● Break down stories from a user point of view
● Make visible the workflow or value chain
● Provide a useful context for prioritization
● Help confirm the completeness of your backlog
● Plan releases in complete and valuable slices of
functionality
www.torak.com

22. Story Mapping
How do you do story mapping?
● Choose user roles for the product
● Figure out what each user does within the product
● Map those user-roles to User Activity, User Task, and User Subtask
(Color coordination helps)
● Cluster items that seem similar and create labels for the clusters
● Arrange activities in a swim-lane to visualize workflow
● Meet with stakeholders and spot check the workflow
● On review, make changes
● Identify goals of the release with user-specific stories in mind
www.torak.com

23. Story Mapping
● helps us focus on the big picture and why we are building the product (business
value instead of feature details)
● look at product backlog differently
● keep breaking things down as you go down a path of functionality
● organize the backlog into a logical units for development
● elicit the core functionality of a product from a user-centric point of view
● focus on what the customers or users must do in order for the product to be useful
(bells and whistles can come later)
activity activityactivity
task task task task task task task task
details
details
details details
details
details
www.torak.com

24. The Walking Skeleton The Walking Skeleton is a
tiny implementation of the
of the system that performs
a small end-to-end
function.
It is missing the flesh of the
application functionality.
The Backbone
The Walking Skeleton
necessity
time
Plan using
your backbone!
www.torak.com

25. Release #4
Release #3
Release #2
Release #1 - Walking Skeleton
Story Mapping & Release Planning
necessity
time
necessity
time
www.torak.com

26. Wireframes
● Remember: the most effective/rich level of communication is 2 people in
front of a white board
○ helps the team to communicate better internally and externally
● wireframe capture something in it's simplest form (bare bones)
○ flesh out something - based on the idea of adding flesh to a picture
that shows only the bones of a creature
Steps for using wireframes
1. we rapidly create wireframes from the basic description of a user story
2. we gather feedback and adjust the wireframes accordingly (no coding yet)
3. the user interface is designed based on the approved wireframe
● various tools can be used for creating wireframes, but keep it simple!
○ Visio, wiki, scanned drawing, etc...
www.torak.com

27. Wireframes (example & pros/cons)
PROS
● simple and fast visual format
● generate feedback
● minimize rework / uncover potential gaps
● reduces miscommunication
● illustrates dependencies
● easy review process
● great when associated with workflow
diagramming
● uncover usability issues (early)
CONS
● may limit the team creativity if they are
over-engineered or stylized
● may create false promises about layout or
system functionality
● not kept up to date with the story
(acceptance criteria)
● should not be created too early
● who is responsible (ideally) to
create/manage the wrieframes
● eventually reach a point of diminishing
returns
www.torak.com

28. © Torak, Inc. www.torak.com
Agile, Kanban & DevOps Coaching
Learn more at www.torak.com
Learn more at www.AgileTestingFramework.com
Learn more at www.kanbanzone.com

29. Thank You
www.torak.com

30. Resources and References
● www.scrumalliance.org
● www.mountaingoatsoftware.com/scrum
● AgileProductDesign.com
http://www.agileproductdesign.com/presentations/user_story_mapping/index.html
● Agile and Iterative Development: A Manager’s Guide by Craig Larman
● Agile Estimating and Planning by Mike Cohn
● Agile Project Management with Scrum by Ken Schwaber
● Agile Retrospectives by Esther Derby and Diana Larsen
● Agile Software Development Ecosystems by Jim Highsmith
● Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
● Scrum and The Enterprise by Ken Schwaber
● User Stories Applied for Agile Software Development by Mike Cohn
www.torak.com

31. This presentation was inspired by the work of many people and we have done our very best to attribute all
authors of texts and images, and recognize any copyrights. If you think that anything in this presentation
should be changed, added or removed, please contact us.
http://creativecommons.org/licenses/by-nc-nd/3.0/
www.torak.com