User Story Mapping

gistfile1.txt

# Three levels #

Personal : Organizational
---------------------------
Goals : business objectives
Tasks : business processes
Tools/Features : employees, vendors & systems

# Business Goals #

## Business Value ##

Built Software for:
	internal use:
		Save Money or
		improves customer service
		(indirectly earns money)
	use by customers, earns money through:
		direct sales,
		improved customer retention, or
		improved customer loyalty

## Product Goals ##

Product goals describe the outcomes or benefits received by the organization after the product is in use

Example:
Output: The Product ships
Outcome: customers & users act - buy, use, & give feedback
Impact: Your company, customers, & users begin to see long term benefits

## Product Metrics ##

How would we observer progress towards our goal?

“if we’re making progress towards this goal, how would we know it?  What would we observe in our organization that indicates success?”

# Users #

## User Personas ##

Imagine the user experience (UX) as a scenario

Think about:
	Typical use, including typical problems
	Interesting plot points
	Goals and pains of your user

After 5 minutes of discussion write out the scenario

# User Tasks #

	"Cloud level" = Too abstract
	"Kite level" = Activities = long term goal with no precise ending. Perform several functional tasks in the context of an activity
	"Sea Level" = Functional tasks = reasonably expect to complete in a single sitting
	"Fish level" = Sub-functional tasks = Small tasks that by themselves don’t mean much.  I’ll do several of these before I reach a functional level goal.
	"Ocean floor level" = too detailed

from Cockburn’s Writing Effective Use Cases

## Tasks ##

User tasks are decompose to smaller tasks and organize into activities

Tasks require intentional action on behalf of a tool’s user 

Tasks have an objective that can be completed

Make ideal user stories. 
Example: As a [User Role], I want to [Task], so that I can [Benefit].

## Activities ##

Have:
	Some associated tasks
	One goal or purpose
	A main participant
	Other (human) participants
	Place or location
	Tools (computers, software, electronic files, telephones, information, paper, etc)

“Read an email message” is a task, “Managing email” is an activity.

List activities over time form the "skeleton" of the system, and associated Tasks (User Stories) are listed beneath the Activities/"Epics" they fulfill.

Push higher value or more necessary stories up and lower value stories down to form "swim lanes" for each Release/Iteration of the Product.

# Product release roadmap #

# Name: purpose/mantra
# Business benefits: 1-2 sentences
# User benefit: 1-2 sentences

Example:
	EasyPOS Point of Sale Software 

	Release 1: Replace the cash register

	Business: gets rid of old manual cash registers and gets accurate up to the minute sales information across locations.

	Users: Cashiers get an easier to use cash register that helps them make less mistakes, corrects them when they do, and saves time balancing cash drawers every night.


## Iteration ##

“iterating” builds a rough version, validates it, then slowly builds up quality

It's not iteration if you only do it once.

“incrementing” builds a bit at a time

Incrementing calls for a fully formed idea. 
And, doing it on time requires dead accurate estimation.

## Quality ##

Objective quality = ‘conformance to requirements’ 
	(measurable, easily validated, perform as specified, bug-free)
Subjective quality = ‘satisfaction of users.’

	Must-haves:
		The products must have this features for me to be consider the product acceptable

	One-dimensionals:
		The more of this I get, the better

	Delighters:
		I love this element of the product!

--Noriaki Kano

Subjective criteria: Simple to use? Efficient? Likable? Fun?
Criteria tend to vary from user to user.

“This car has many flaws. Buy it anyway. It’s so much fun to drive” 
-- from a NY Times review of the Mini Cooper


# Three Phases #

Opening Game: Build a simple system span of necessary features first – the walking skeleton
Example: A form with only necessary fields and no validation


Mid-Game: Add flexibility, business rule enforcement and safety next.
Example: a form with optional fields, date lookup tools, input translation on dates
Safety Examples: input validation, enforcement of business rules such as credit card validation  


End Game: Finish with comfort, performance, and luxury.
Refine the UI and interactions, take advantage of iterative learning.
Reserve time in the remaining third for unforeseen additions and adaptations
Example: auto-completion, sexy visual design, speed keys

Remember: Uncertainty decreases over time

Construx on the Cone of Uncertainty: http://www.construx.com/Page.aspx?hid=1648
Visdos on the cone: http://www.implementingscrum.com/2008/02/19/vegas-hangover-enlightenment/   
## Business Value over time ##

Like art: Sketch, under-painting, and slowly build up detail over time.

Value S-Curve: Most business value gained in the Mid Game.

Opening Game
Early stories emphasize iteration and learning.  We need to be sure we’re building the right product

Mid Game 
Once we’re confident we have the “shape” of the product right, we begin to pile in value

End Game 
Over time the value of stories begin to diminish signaling it’s time for release

To finish on time we may “trim the tail” by deferring stories of modest value


## Guidelines for releasing on time ##
	Thin stories aggressively during early sprints to build all essential functionality early.
	Build up functionality only after all necessities are in place.
	Protect time in the final sprints for product refinement.
	Assess release readiness at the end of each sprint as part of product review.

Source: http://www.agileproductdesign.com/presentations/user_story_mapping/index.html
and http://www.agileproductdesign.com/downloads/patton_user_story_mapping.ppt