Stories, Backlog & Mapping

www.torak.com

About Dimitri PonomareffDimitri 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.

www.torak.com

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, Choice Hotels International, JDA Software, LifeLock, First Solar, Mayo Clinic and Phoenix Children's Hospital. Dimitri enjoys his work, and does everything to ensure he shares his knowledge with others who seek it.

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

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

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

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

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

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

The 3 C's

1. CardWritten on a card

2. ConversationDetails captured in conversations

3. ConfirmationAcceptance 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 fail2. Remember the login, not the password3. After 3 attempts the account is locked out for 24h (SOX compliance)

www.torak.com

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

Product, Epics & Stories

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Product

Epics

Stories

www.torak.com

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

INVEST guideline from Bill Wake

I - IndependentThe 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 - EstimableYou 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 - TestableThe user story or its related description must provide the necessary information to make test development possible.

www.torak.com

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

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

Backlog Management

● Blitz Planning● Product Road Map● Story Mapping

○ The Walking Skeleton ○ Release Planning

● Wireframes

www.torak.com

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

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

Product road map example...

www.torak.com

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

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

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

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

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

nece

ssity

time

Plan using your backbone!

www.torak.com

Release #4

Release #3

Release #2

Release #1 - Walking Skeleton

Story Mapping & Release Planningne

cess

ity

time

nece

ssity

time

www.torak.com

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 wireframes1. we rapidly create wireframes from the basic description of a user story2. 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

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

Agile Coaching, Staffing and Training.

Learn more at www.torak.com

Learn more at www.AgileTestingFramework.com

Thank You

www.torak.com

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

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