1

Decomposing into Business Valuable Units

July, 2013

Agenda

Develop willing and able leaders (Pre-condition)

Decompose into business

valuable units

Visualize end-to-end flow of

Work

Create a Collaborative

Vision & Shared

Understanding

Enable continuous

improvementDrive

Customer Value

0

1

2

34

5Limit work-in-

progress

Session 1

Session 1

Session 2

Session 3

Session 4

Session 5

Agenda

3

Decomposition, 1hr• The Project Delivery Problem• ‘In-one-go’ vs. Iterative Delivery• Decomposing into User Stories• Story Mapping

Story Mapping Exercise, 45 minFollow-up, 15 min

Some context?

Organizations are struggling to deliver software that is of value to the business user and that comes in on time and on budget

5

The fact is that projects can be large and complex, with a number of possible failure points

Things can get lost in translation

7

We can lose sight of the forest for the trees / get lost in details

8

It’s easy to become disconnected from user value, if we were ever connected in the first place

9

“If I'd asked my customers what they wanted, they'd have said a

faster horse. ”

Henry Ford

It’s hard to estimate time and cost at the start of the project

10

What can we do?

We can do nothing

12

We can do more of the same

13

“Insanity is doing the same thing over and over again

and expecting different results.”

-Albert Einstein?

Or we can rethink the way that we approach project delivery

14

Generally speaking, there are two ways to approach a project

We can try to deliver the project ‘in-one-go’

16

1 2 3 4 5

• Requires a fully formed idea to start (i.e., a long initial requirements phase)

• Focused on delivering detail from the start (i.e., can neglect other areas of the solution)

• Provides no validation of the end-to-end solution until the end (i.e., may not know if off track until the end)

• Course corrections can be hard and only one chance to right size (i.e., wasted effort and over/under solutioning)

Or we can take an ‘iterative’ approach to project delivery…

17

1 2 3 4 5

• Requires only a vague idea to start (i.e., a shorter initial alignment period with details determined ‘just-in-time’)

• Focused on producing a ‘rough’ end-to-end solution from the start (i.e., keeps ‘big picture’ view, detail added later)

• Provides a much earlier validation of the solution (i.e., can confirm business value and justify further effort)

• Course corrections can be made much earlier and right-sizing is enabled (i.e., with far less wasted effort)

A more direct comparison?

18

Project

Big projects and releases are hard…

Lots of variability and unknowns…

Lots of dependencies…

Why not decompose the project into iterations so that value can be delivered earlier and the risks mitigated?

But there is still a problem

20

An iteration can still constitute a large, complex project

21

It can also be hard to identify what the iterations should be

Where to begin?...

What to include?...

22

Finally, what if only one iteration is identified – are we back to this?

Although decomposing projects into iterations is important, what is also important is decomposing projects into increments, and to organize these into the iterations that will be delivered

24

Two views of project decomposition that are worth distinguishing

ProjectIterations(MMFs)

IncrementsDecomposed into Composed of

Project IncrementsIterations (MMFs)

Decomposed into Organized into

OR,

These increments are User Stories A Story Map is the organization

What is a User Story?

A way of representing an increment of what is to be delivered

26

A User Story describes requirements, which will then be delivered in the form of a solution that meets those requirements*

*A user Story IS NOT an engine with X cylinders and such and such horse power, but rather it is an expression of the user’s need to be able to go a certain speed and to have certain power, the solution to which is the engine…

At the right size – a bite sized portion!

27

Functional or “Sea level”I’d reasonably expect to complete this in a single sitting

Sub-Functional or “Fish level”Small tasks that by themselves don’t mean much. I’ll do several of these before I reach a functional level goal

Activity or “Kite level”Longer term goals often with no precise ending. I’ll perform several functional tasks in the context of an activity

Too abstract

Too detailed

Keep focus here!

Contextualized by a broader narrative

28

User Story

Broader NarrativeUser Stories are interrelatable!

Something that is itself iteratively produced

29

Project Duration

De

tail

Find Product

Story SketchingThinking pad...

Story Summary

Users and Systems Involved

Free Drawing

Specification by Example

Questions

Acceptance Criteria

Story Name:

MMF#:

Specifications by Example

GIVEN…

WHEN…

THEN…

The User Story is elaborated into greater detail ‘just-in-time’, one step ahead of design/build

In relatable terms

30

Stories should be in a ubiquitous language, and easily translate

Focused on the ‘what’ not the ‘how’

31

Solution Architecture should be incrementally / iteratively built in unison with the User Story / Story Map, but also be open to negotiation

hole (to put the flower in)

x dig hole?

They can be prioritized

32

• Must-haves– The features that must be

there for the product to be considered acceptable

• Wants– The more the better

• Nice-to-haves– Could live without these

but nice touches

Brakes(must have)

Basic brakes(must have)

Stopping distance(want)

Anti-locking(want)

Cool dashboard light when slipping

(nice to have)

How are User Stories produced?

As a… WHO?

I want to… WHAT? So that… WHY?

Some things to keep in mind

34

A User Story allows further refinement of scope with business stakeholders to provide options around timing and cost

A User Story is testable by itself and has clear acceptance criteria defined

A User Story has concrete business value or has an inherent investment value (e.g. ‘Approve expense report’ can be a work ticket but ‘Build data access objects’ cannot)

A User Story has high-level scope and high-level solution design defined so as to enable creation of coarse estimates

A User Story is sufficiently small to support and allow tracking of the project progress (e.g. a set of cohesive steps in a use case)

A User Story is structured to minimize dependency on other work tickets

Negotiable

Testable

Valuable

Estimate-able

Small

Independent

Some guiding principles (INVEST)

• Card represents physical capture of the story• Conversation represents a “promise for a conversation” or

collaboration between the team, customer/user, business, and other stakeholders

• Confirmation represents  acceptance criteria, which define the bounds of the story and as such can inform the solution and validate what is delivered

The various forms a story can take (3 C’s)

A convenient structure…

Some examples of more refined User Stories

35

“Send Money”As Glenn Mendoza, I want to use my online banking account for international transfersSo that I can securely transfer $300 Canadian dollars to family in the Philippines to be picked up at a Western Union retail outlet

“Receive Money”As Glenn Mendoza, I want to use my online banking account to receive international remittancesSo that I can receive an international remittance of $100 sent by my parents from a WU retail outlet in India

“Availability”

As Glenn Mendoza, I want to have access to the international remittance service 99.999% of the timeSo that I don’t get frustrated with the service and move over to other providers

Accommodating! Any requirement can be captured in a user story

Unambiguous

Embedded in a broader narrative

Focused on ‘who’, ‘what’ and ‘why’, not ‘how’

Light-weight and relatable

Negotiable

So what is a Story Map?

A Story Map is the organization of User Stories into a broader narrative

37

Put simply, it is a really big story

How is a Story Map made?

38

1. Collaborate as a group2. Start with what you know (or if necessary, establish a

nutshell understanding of the project)3. Think about the users and what their main Goals are4. Start identifying User Stories (build the Story Map

incrementally!)5. Leverage the interrelationship of the stories identified to

organize a left-to-right narrative6. Leverage the relative size of the pieces identified to

organize a top down structure (treat larger stories as buckets for smaller stories, and work towards right-size at all levels)

7. Ensure that the focus is on the ‘what’ and not the ‘how’8. Look for functional gaps9. Prioritize the User Stories vertically from must-have to

nice-to-have10. Iterate! The result is a living and highly

relatable representation of the project deliverable

A conventional view?

39

Manage Orders Manage FulfillmentGoalManage

Provisioning

Manage Activation and Billing

Activity

Story

Enter Order

Enter Order Info

Submit Order

Process Order

Update Order Info

Save Order Info

Add Accessory

Add Optional Mobile

Features

Receive Order

Notify Customer

Submit Fulfillment

Order

Process Fulfillment Order

Receive Fulfillment

Order

Submit to Fulfillment

Vendor

Update Order Info

Save Fulfillment

Order

Transform to Vendor Fulfillment

Notify Customer

Submit Fulfillment to Vendor

Receive Shipping

Notification

Update Order Info

Track Shipping Progress

Submit Order with Accessory

Submit Order with Features

Submit Fulfillment to Network Managmt

…

.

.

.

Submit Provision Request

Process Shipping Exception

s

Resend Fulfillment to Vendor

…

.

.

.

Time

Process Order

Exceptions

Process Fulfillment

Order Exception

Sales RepUser Sales RepFulfillment

VendorFulfillment

Clerk

View Order

Opt

iona

l

Network Operator

Billing Clerk

1

‘Users’ are laid out horizontally at the top of the map. Think of these as major categories of users that gain value from using the system. ‘Goals’ are laid out next. These are major objectives that the solution must support, with tangible business outcomes and real business. ‘Activities’ are the sequential events that describe what the user needs to do in order to get value. Think of them as constituting the workflow.‘Stories’ are laid out under the activity that they support. They are what need to be delivered in order to realize the solution.

2

3

4

1

2

3

4Sequential

Cor

e

End result should be a coherent narrative and representation of what needs to be delivered

With this example, we can see how iterations (or MMFs) are planned

40

Once overall prioritization of stories necessary to support each user activity is understood, the entire story map can be divided by planned releases/MMFs. Horizontal lanes can be used to divide different MMFs from each other. The story map can then be used to tell a narrative for a particular MMF. This is done by traversing the map from left to right and only looking at the stories within a particular lane.

Manage Orders Manage Fulfillment

Enter Order

Enter Order Info

Submit Order

Process Order

Update Order Info

View Order

Add Optional Mobile

Features

Add Accessory

Receive Order

Notify Customer

Submit Fulfillment

Order

Process Fulfillment Order

Receive Fulfillment

Order

Submit to Fulfillment

Vendor

Update Order Info

Save Fulfillment

Order

Transform to Vendor Fulfillment

Notify Customer

Submit Fulfillment to Vendor

Receive Shipping

Notification

Update Order Info

Track Shipping Progress

Submit Order with Features

Submit Order with Accessory

Submit Fulfillment to Network Managmt

…

.

.

.

Submit Provision Request

Process Shipping

Exceptions

Resend Fulfillment to Vendor

Process Order

Exceptions

Process Fulfillment

Order Exception

Save Order Info

…

MMF 1: Basic order entry integrated to the fulfillment vendor with manual provisioning and exception handling

MMF 2: Order entry with management features supporting order tracking, automated customer notifications and robust exception handling

MMF 3: Provide optional mobile features (Visual Voice Mail, Premium SMS, Wi-Fi to Wireless) to customers

MMF 4: Provide accessories and full product catalogue to customers for ordering

Time

Pri

ori

ty

What does Story Mapping provide?

A site for conversation and a conversation starter

42

A highly visible and collaborative way of

doing requirements!

The ‘vague’ or high-level idea of the project that we need to start

43

The Story Map sets the bounds of this

overarching ‘vague’ idea – it is the scope

of the project

Similarly, User Stories set the bounds of each increment

(e.g., what should her hands be doing?)

An informed build order

44

Helps identify iterations with must-have items sorted to the top and nice-

to-have items to the bottom

A direct feed into Kanban

45

Story Map

Kanban Board

A way of tracking project progress

46

0102030405060708090

100110120130140150160170180190200

1-Aug-10 1-Sep-10 1-Oct-10 1-Nov-10 1-Dec-10 1-Jan-11 1-Feb-11 1-Mar-11 1-Apr-11 1-May-11 1-Jun-11 1-Jul-11

Employee Trial BurndownRemoved RequirementsTotal Stories CompletedStories Remaining

New Requirements

0

5

10

15

20

25

31-Jan-11 14-Feb-11 28-Feb-11 14-Mar-11 28-Mar-11 11-Apr-11 25-Apr-11 9-May-11

Tota

l Sto

ries

Week Ending

Requirements

Design

Build Wait Time

Code

Test Promotion

QA Wait Time

QA

UAT Wait Time

UAT

RFC

RFC Wait Time

RTP Wait Time

RTP

Done

User Stories provide a unit of progress, and the full Story Map the measure of done

Some recap?

Returning to the project failure points identified, do User Stories and Story Mapping help mitigate the risk?

48

Things can get lost in translation These are collaborate practices! Highly visible and light-weight Using relatable terms

We can lose sight of the forest for the trees / get lost in details Story Map keeps focus on the forest User Stories keep focus on the trees Facilitates focus on the right level of detail at the right time!

It’s easy to become disconnected from user value, if we were ever connected at all Again, collaborative, and can include the user / business User Stories can have their value confirmed once delivered Story Map facilitates iterations and broader validation

It’s hard to estimate time and cost at the start of the project User Stories are estimate-able units Separates must-haves from nice-to-haves – focuses effort!

“If I'd asked my customers what they wanted, they'd have

said a faster horse. ”

Henry Ford

Although not a ‘silver bullet’, hopefully the potential value of these decomposition techniques has been shown

Some real world applications?

50

‘Claims’ Story Map from an Ontario Crown CorporationReceive Initial

Claim Information

Register ClaimCapture

Incident OnlyNotify of

RegistrationProvider

Registration

Collect Additional

Claim Information

Segment Claim

Assign Claim AssessDecide / Approve

Assessment

Notify (Claim Decision)

Receive Information

Record & Update

Collect Information

Case Planning

Case Management

(Implementation)

MonitoringClosure (Case Management)

Retrieve Billing Information

Review BillsBenefit

CalculationIssue

Payment

Receive Dispute

Information

Referral of Information to

Appeals

Assess Disputed Decision

Appeal Decision

Implementation

Refer Information to Collections

Implement Collection Decision

Manage Workload

Usability Audit Changes

Security Access

(Internal & External)

Manage Reporting

Collection of Claim Information:

Online (Portal)

Creation of Profile: Worker

Creation of Incident: Online

(Portal)Notif ication: Email

Creation of Provider Profile: Online (Portal)

Collection of Information:

Off line (Phone, Fax, Email, Mail)

Segmentation of Claim

Assignment of Claim

Manual Adjudication

Snapshot of Claim & Facts

(When Decision w as made)

Notif ication: Email

Collection of Additional

Information: Online (Portal)

Adjustment of Claim

Receive Information from

External Data Sources

Create Recovery and RTW Plans w ith Goals &

Milestones Based on "Best

Practice" Pre-built

Implement RTW & Recovery Plan Interventions

Receive HC / recovery / WT updates from

providers

Create RTW codes

Manual Entry of Payment Data

Manually Input/Alter Payments

Manually and Automatically Calculation

Various Payment Types

Pay Special Bill Cases

Receive Dispute Forms

Refer Information to Appeals Team

Ability for Reconciliation

Implementation of Appeal Decision

Refer Information to Collections

TeamCollect Debt

Re-assign case based on w orkload

forecast and users' availability

Internal operational policy

help linkage

Log and view change history

Access for providers

Business analytics for

claims outcome info

Collection of Claim Information: Off line (Phone, Fax, Email, Mail)

Creation of Profile: Employer

Creation of Incident: Off line

(Phone, Fax, Email, Mail)

Notif ication: Portal

Creation of Provider Profile: Off line (Phone, Fax, Email, Mail)

Collection of Information:

Online (Portal)

Association of Claims

eAdjudicationManagement of Decision Making

Notif ication: Mail

Collection of Additional

Information: Off line (Phone, Fax, Email, Mail)

Amalgamate Claims

Collection of Information from

WPPs: Online (Portal)

Integrate Information from External Sources into Plan (RTW,

WT, HC)

Implement Activity Referrals

to Internal & External Users

Monitor & rack plans against best practice

guidelines

Notify relevant parties of case

closure

Additional Calculations (as

required)

Review Provider Bills

Manage Payment Types

Adjust PaymentsCollect Claim Information

Provide Acces to Claims and

Appeal Information and

Updates

Geo-map client to provider

High level case status view

Management dashboard w ith real-time KPIs

Collection of Other Information

(Including Claimant, Employer)

Creation of ClaimCreate an Incident w ithout Employer

Notif ication: MailValidation of

Collected Information

Validation of Required

Information for Assessment

Escalation of Decision

Notif ication: Portal

Creation of Activities

Management of Collected

Information

Collection of Information from WPPs: Offline (Phone, Fax, Email, Mail)

Counter-propose RTW & Recovery

Plan via Portal

Reopen and Adjust Plan

Based on New Information &

Decisions

Annual review of benefits

Validate Payment Information

Review Claimant Bills

Adjust Payment Calculation

Send Out Year-End Statements

User productivity enhancement

and error handling

Validation of Collected

Information

Validation of Claim Information

Notif ication: EmailManagement of

Collected Information

Generation of Activities

Link w ith External Data Sources

ReviewView RTW &

Recovery Plans via Portal

Travel Arragements

Internal

Re-assess & predict recovery

/ permanent impairment

View Payment Details

Management of Collected

InformationNotif ication: Portal

Notif ication of Changes

Self-serve Travel Arrangements

Create alerts for plan activities

achievement and non-cooperation

Pay Basic Bills

Ability to Search for Existing Records

Notif ication: Mail

View Changes to Financial

Exposures (Liabilities) by

Claims

Collection of Claim Information:

B2B

Communicate Goals / Plans

Updates: Online (Portal)

Communicate Goals / Plans

Updates: Offline (Phone, Fax, Email, Mail)

Registration Payment Objections System AdministrationClaims Maintenance Managing RTW & Recovery CollectionsClaims Setup Claims Entitlement Decision

Some real world applications?

51

‘Process Model Enablement’ Story Map from an Insurance company

An exercise

A mobile workspace booking app

53

Deloitte has commissioned you to develop a mobile application that will enable Deloitte staff to book workspaces across its national offices.

In teams of 5 or so, decompose this project into User Stories and organize them into iterations using the Story Mapping technique.

Think about the users that need to be considered, what their goals are, what activities make up those goals, and what functionality would be core versus nice-to-have in supporting those activities.

Catering?

Individual and group work spaces?

Canceling, editing, transferring bookings?

Logging in?

Office selection?‘Quick book’ feature? Non-functional requirements?

Reporting?