Grooming Stages

CONFIDENTIAL AND PROPRIETARY 2014 DISCOVER FINANCIAL SERVICES

Portfolio
Portfolio Backlog
Backlog

Levels of Backlog Refinement/Grooming

Theme/Business Goal

Business Initiative

Program
Program Backlog
Backlog

Team
Team
Backlog
Backlog

Feature

Feature

Story

Story

Story

Story

Story

Story

Story

Story

WSJF for
Initiatives &
Features

11

22

33

Initiatives
span Program
Increments

Features fit in
Program
Increments

T-shirt Size

Architectural Initiative

WSJF

Infrastructura
Infrastructura
ll Enabler
Enabler

Architectural
Architectural
Enabler
Enabler

Enabler
Enabler

Enabler
Enabler

Enabler
Enabler

Enabler
Enabler

Enabler
Enabler

Enabler
Enabler

Enabler
Enabler

Spike
Spike

Spike
Spike

Enabler
Enabler

Enabler
Enabler

55

Points

Stories fit into

iterations
implemented
by Tasks

Grooming Patterns
Grooming is an ongoing event. It has no end but rather various states of
readiness
Initial grooming must take into account two things:
Work already in Progress (or a near time Horizon)
Intake of work for the next calendar (2017 Project Lists)
Because we have two patterns, the agenda switches for each pattern:
Minimal work to refine the work already in progress
Refine lightweight Business Case with missing data
Focus on Program grooming
Intake of new work:
Follow Portfolio Kanban Activities
Derive Initiative Value Statement
Refine to Lightweight Business Case
Prepare for Program Grooming

Work flow from Portfolio to Team

1 Senior Managers are engaged via Huddles/Stand-ups

4|

How Much Architecture?

In the enterprise, product management must work with
architecture to build new features on a solid architecture runway

If we let the Architect have his way, hell

rearchitect this thing until hell freezes over,
and then well all be out of a job

If we let the Product Manager

have his way, hell make us
band aid this thing until hell
freezes over, and then well all
be out of a job

?
Product
Manager

Architect

Portfolio Kanban
The Portfolio Kanban is a pull-based mechanism to pull work to
be groomed by the Portfolio Management Team. When items
make it to the Portfolio Backlog they are ready to be pulled by
Product Management to be decomposed into Features.

Concept
(Portfolio Grooming)

Program Management
(Program Grooming)

Execution
(Sprints)

(Team Grooming)

Execution
(PI)

Participants
VP Business
Sponsor(s)/Initiative Owner
BT VS Owners VP and
Product Manager

Product Manager
Product Owner
Release Train Engineer
Value Stream Architect
System team/QA Lead (optional)

The SCRUM TEAM:, PO

Other Tech Leads (Optional)
SMEs (optional)

PO, SM, TC,

Devs, Testers

SM, Devs,
Testers, RTE,
PM, PO,
Coaches

Decompose Initiative into Features

Complete Feature Sizing
Complete Design Control Gate &
ISS Pre-Assessment for
confirmation of SME engagement
(Security, Legal, ISPO, etc)
Engage additional Shared
Services needs (ex: HTML, DBAs,
external agencies)
Derive/Refine Program Vision &
Roadmap
Continually prioritize using WSJF
Governance of Existing Features
(Roadmap, Status, Metrics)

Prepare for Next Sprint:

User Story & HLD Refinement
discussions
Resolve dependencies
Refine estimates
Upcoming Sprint Plan

Sprint Planning
Daily standup
Design, build,
unit, system,
integration,
UAT test
Code review
Regression
testing
Demo and
accept stories
Retrospective

PI Planning
SoS
PO/PM
Sync
SoT
SoC

Testing Passed
Accepted
Stories for
Sprints 1-4
For shippable
features, code
is ready to ship
to prod

Accepted
Features

Activities
Consolidate Ideas into S, M, L
initiatives using Initiative
Value Statement
Continually Prioritize using
WSJF
Determine if initiative is ready
for the Portfolio Backlog.
Ready is defined as approved
by ValueStream
VP(s)/Governing VP(s) with
completed Outputs
Governance of existing
Initiatives (Status, Metrics)
Complete Requirements
Control Gate

Prepare for PI Event (3rd-4th sprint):

Decompose new Features into User
Stories, Spikes
Relatively Size Stories
Nominate new Stories
Refine current PI plan
Refine future Sprint Plan

Output
Lightweight Business Case
including Technical
implications
Discrete Success Criteria per
Initiative
T-Shirt Sized by PI
Approved (Funded) Initiatives
Initiatives Ready to be pulled
by Product Managers

Prioritized Features
Features Ready to be pulled by
Product Owners
Features written in Feature/Benefit
format and Acceptance Criteria
Prepare for PI planning
Needed Shared Services defined
Artifacts as defined by area (ex:
Wireframes, Comps, Model)
Design Documentation (ex: HLD)

Prepare for Next Sprint:

Stories meet DoR
Detailed designs for 1st stories
Obtain Legal approval for necessary
Artifacts (ex: Comps)
Test env and data ready
Dependencies resolved
Prepare for PI Event:
Stories written with Acceptance
criteria
Estimate via story points
80% of Stories fully elaborated prior
to PI Planning
DFSI Confidential
Revised Capacity/Load calculated

T-shirt sizing Used for Initiatives/Epics

T-shirt sizing is a low fidelity way of estimating the size of work within a ballpark
figure. More akin to Rough Order of Magnitude (ROM) or Level 0 estimating.
Initiatives should not be greater than 3 Program Increments (PI) in duration.
This encourages smaller batches, smaller queues, and manageable WIP limits.
T-shirt Size

# of Sprints

Factors/Reasons

1 PI

Around 10-12 weeks in size

Assumes multiple Teams from the ART

2 PI

May have dependencies with other

Value Streams or ART

3 PI

Usually Dependency based

If we were to assign numbers to S, M, L such as 1, 2, 3 then it can be

used as a rough approximation for Job Size. This allows it to be used for
WSJF purposes as well as to initially load-balance an ART.

DFSI Confidential

T-shirt sizing Used for Features

T-shirt sizing is a low fidelity way of estimating the size of work within a ballpark
figure. More akin to Rough Order of Magnitude (ROM) or Level 0 estimating.
Features must be able to be completed within a Program Increment (PI).
T-shirt Size

# of Sprints

Factors/Reasons

1 - 2 Sprints

Features that can be done in less than a

Sprint are probably Stories
Mostly 1 team might be shared

3 Sprints

Many User Stories & Enablers

Complexity or Sequencing important

4 Sprints

Usually Dependency based

If we were to assign numbers to S, M, L such as 1, 2, 3 then it can be used

as a rough approximation for Job Size. This allows it to be used for WSJF
purposes as well as to initially load-balance a set of teams.

DFSI Confidential

Appendix
Definitions
Sample Program Artifacts

CONFIDENTIAL AND PROPRIETARY 2014 DISCOVER FINANCIAL SERVICES

Definitions
SoS

Scrum of Scrums A meeting used when Scaling Agile to manage

Dependencies, Risks and understand Progress across multiple
teams. Generally composed of ScrumMasters with the RTE
facilitating.

SoT

Scrum of Testers Similar to the Scrum of Scrums, but all members

are Testers and the focus is primarily on Testing.

SoC

Scrum of Coaches Meeting where Coaches come together to

share learnings, coaching advice and align on coaching methods.

PO/PM Sync

Product Owner/Product Manager Sync Similar to the Scrum of

Scrums, but all members are Product Owners or Product Managers.

Sample Vision - Business context

Payment Services builds assets and capabilities as competitive

advantage
Discover Card needs a digital platform to compete in future payments

Immediately offering ewallet services to cardmember

Platform that enables new functionality/opportunities, like tokenizing cards-on-file
Critical payment services building blocks for future of payments that we want proprietary

Discover has an opportunity to leverage digital assets already being

built

DN assets (DPAS, applet/code) are one of 4 that enable global wallet acceptance
Discover debit issuers, DCI franchises, and DN prepaid issuers also need to connect their
cardmember to ewallets and other digital services
New opportunities with net-to-net partners and private label credit cards (PLCC) to sell digital
services (yes, for money!)

DFSI Confidential

Sample Vision - Business view of DDX

Custom

Clients

2200
11
55

Wallet
Wallet

Generic Services

Discover Digital
Exchange
Access

Portal/
Reporting

Security

Generic HCE / SE

NFC

Wearables

Generic Card on File

Communication

Translation

ONGOING /
A. Apple Pay / Android Pay
CUSTOM
B. MST portion of Samsung Pay
OTHER
A. DCI token support
B. Unbundled DDX

Any Client Connectivity

QR/
Bluetooth

Any Wallet Connectivity

DPAS

OBO
OTP

Multilanguage

Participants
Discover Card
Discover Debit
Prepaid
DCI
Enablers
PLCC
N2N
Merchants
Bank consortiums

QR/
Bluetooth

Mobile
In-app

Traditional
Browser

Localized DDX

DFSI Confidential

13

Sample Vision - SWOT: Generic Wallet HCE and Cards-on-File

Connecting multiple wallets and merchants to DDX, e.g. Samsung, Amazon, Google, Coin,
Fitbit, Microsoft, etc.

Strengths

#3 global acceptance, major player

Core assets: ZIP, DPAS and
applet/code
Client flexibility

Weaknesses

Opportunities

Platform and specification

standardization
Certification/launch efficiency
Regularly scheduled updates
Solid Generic COF authentication
strategy

Half competitor resources, same

assets
Lowest market share in US top 4
Merchant regulations/specification
updates impacting in-app txns

Threats

DFSI Confidential

Speed to market
Local specification third party
providers, biggest Gemalto
Regulations

Sample Vision - Generic Wallet HCE Features

Priority Feature

Description

DDX Consolidation

Merge Apple and Android Pay code onto a single codebase that can support the scale
required for a multi-tenant, wallet-agnostic Generic Wallet platform.

Simulators

Provide a full test environment and simulator that wallet providers can use to fully
validate and certify their generic wallet API (NWS 2.0) implementation.

Boarding

Ability to bring new wallet providers on-board as a token requestor to all necessary
downstream systems (ex: DDX, TSP, Hydra, etc).

Provisioning

Ability to generate, personalize and activate digitized card credentials to a digital

wallet.

Lifecycle Management

Ability to maintain the token lifecycle - Token state and replenish of payment
credentials for a Wallet provider.

Transaction Processing

Ability for cardholders to complete purchases using new wallets.

Notifications

Ability to provide real-time transaction notifications and alerts to cardholders.

Portal

Prepare https://developer.discover.com for commercial use by wallet providers, which

provides the ability to register, download the documentation required to implement
DDX, and connect to the DDX sandbox.

Reporting

Ability to generate and deliver wallet usage reporting and analytics to the wallet
provider as covered in the Wallet specific agreement.

DFSI Confidential

Sample Architectural Vision

Consolidation Current State Apple Pay and Android Pay

DFSI Confidential

Sample Architectural Vision

Consolidation End of PI State Apple Pay and Android Pay

Benefits

DFSI Confidential

Consistent set of
components
Simplify
Development
Process
New Functionality
available for all
wallets earlier

Sample Program Increment (PI) Roadmap

Samsung
Launch
Samsung Beta

DCI Client
Cert Start

Samsung Alpha
TODAY

Samsung Cert Start

NWS 2.0 Incubator

L2 Simulator

Jun

May

Jul

Samsung Prod Validation

DPAN
GW HCE Core Install
Notifications
ETA to Apple

Sep

Aug

8/299/1

7/31

PI 1

5/11
Feature

Initiative(s)

Oct

Feature

11/111/2
Initiative(s)

DDX Consolidation

GW HCE/COF

Reporting

Developer Portal

GW HCE/COF
(TO)

Apple Dev Sandbox

eWallet
ongoing

Boarding

GW HCE/COF
(TO)

Cloud Wallet
(HCE DDX Delta)

GW COF

Simulators (L1 & L2)

GW HCE/COF
(TO)

Cloud Wallet
Transaction Processing

GW COF

Provisioning

GW HCE/COF
(TO)

API Provisioning

GC

LCM

GW HCE/COF
(TO)

API Incubator

Transaction
Processing

GW HCE/COF
(TO)

Notifications
Addl DPAN
Notifications

GW HCE

Committ
eWallet ongoing
ed

Batch LCM

GC

Portal LCM

GC

Nov

GC
Remainin
g Install

Dec

Jan

9/12 9/26 10/1710/31

PI 2

8/2 8/3

Samsung
Delta
Install

GC API
Function
s Install

GW HCE/COF

PI 3

Feature

1/24
Initiative(s)

Token Guest Checkout

Token

Payment Authentication
Service

DDX Authent

Reporting

GC

Notification

GC

Certification

GC

API Life Cycle

Management

GC

GC

API Simulator

GC

Samsung Pay in GC

GC

Boarding

GC

Client Provided TSP

(Unbundled DDX)

GC

Transaction Processing

GC

Forecasted
Release

Joint Client Activity

Launch

Key: GW = Generic Wallet, COF (TO) = Card on File-Token Only, (LUK)= Card on File w/
Limited Use Keys

DFSI Confidential

18