lean agile accelerated delivery complete training

SDLC Training

July 2014

Scope of today’s training

Review Organization’s agile SDLC and how work flows through the system

Focused discussion on the Plan and Execute phases of Organization’s agile SDLC with hands-on exercises

Take the opportunity to put agile techniques into practice and apply them to a case study

Note: Although we are using hands-on exercises, we will not be focusing on advanced agile technical practices.

SDLC Training Agenda

3

SDLC Overview

Initiate – Overview

Plan – OverviewOpportunity Planning – Overview & Practices

ExerciseRelease Planning (Pre-Sprint) – Overview & Practices

Exercise

Execution – OverviewBacklog Grooming – Overview & Practices

ExerciseSprint Execution – Overview & Practices

ExerciseHardening

Deploy – Overview

Next Steps and Retrospective

SDLC Overview

A high-level view of an Agile SDLC

5

This is a proposed SDLC, and is being refined by several areas of SD to ensure that it is relevant across teams

6

Qualification

Intake ideas and triage

Generate initial opportunity model

using canvas

Opportunity PlanningStory Identification

Build Initial Story Map

Vet opportunities through canvas

walkthrough

Align to roadmapTrack ideas on

Kanban

Opportunity Definition

Outline Story Map (Business and

architectural epics)

Identify riskiest elements of model

on canvas

Develop business case / PRF

Validate business case / opportunity

canvas

Validate financials

Estimate cost of delay to prioritize

MMFs

Refine epics and initial stories

Explore unknowns / assumptions /

riskiest elements on the canvas

Architecture Identification

Develop System Context Diagram

Define platform layered

architecture

Identify technical constraints

Identify key mechanisms

List key non-functional

requirements

Group stories into MMFs and

prioritize on Enterprise Kanban

Release Planning (Pre-Sprint)Story Exploration

Refine Story Map

Build Story Sketches and Acceptance

Criteria

Explore Domain Model with CRC

Architecture Exploration

Design key mechanisms

Identify initial UX / wireframes

Estimate stories using collaborative estimation methods

(Planning Poker)

Validate C/P/S* assumptions

through tactical experiments

Story Acceptance

Backlog Grooming (Next sprint)

Execute

Spike key mechanisms and update design

Spike POCsRefine / Update

architecture

Story Elaboration

Create story scenarios

(Specifications by Example)

Elaborate Domain Model using CRC

Elaborate UX / wireframes

Sprint Planning

Refine estimates for stories in next

sprint (Planning Poker)

Sprint* ExecutionStory Definition

Refine Domain Model using Domain

Driven Design

Explore software design using Agile Modeling (Class

Diagrams, Sequence Diagrams, etc.)

Story Development

Build stories following red /

green refactor loop (Test Driven Development)

Switch pairs after each test (Pair Programming)

Practice SOLID coding conventions

Story Validation

Build examples with data for story

scenarios (Specification by

Example)

Integrate work using Continuous Integration to

enhance collective code ownership

Validate each story using examples

(Specification by Example)

Execute story integration testing

Formally accept stories for hardening

Plan next sprint and replenish stories

Hardening (Previous Sprint)

Stabilize codeConduct System

Integration Testing

Conduct Performance / Stress / Load

Testing

Conduct Smoke Testing

Conduct User Acceptance

Testing

Go-Live

Verify Deployment Readiness

Deploy

Deploy Release

Transition

Transition to Help Desk

Transition to Maintenance and

Production Support

Transition to I&O

Define non-functional

requirements

Spike reference architecture

Idea tickets on Kanban

Opportunity Canvas

Assign an execution team and work types

to stories

Prioritize stories (Kanban / sprints)

Formally accept stories for execution

Opportunity on Kanban

Business CaseRiskiest elements identified

Complete opportunity canvas Opportunity

Prioritization (EPRB/Shark

Tank)

Q&A, build and define rough

order of magnitude /

T-shirt size epics

Prioritized Opportunities on Enterprise Backlog

What opportunities are out there?

Should we work on it?

How should we deliver it?

When will we deliver it?

How will the work be done?

Prioritized MMFs on

Enterprise Backlog

Stories on Team Backlog

Regression Testing

Production-Ready Code (MMFs)

Refine initial architecture

Architecture Description

Explored Assumptions

Story map with identified stories

Story map outline

Business / Technical PoC

Refined story map, sketches, and acceptance criteria

Initial CRC model

UX / Wireframes

Validated Assumptions Business

KPIs for MMF

PoCs for risk validation

Refined Architecture Description and

Reference Architecture

Coded Stories

CI suite running on all code

Unit Test Coverage

Completed Acceptance TestsDefined Stories

Stories validated by customer

Improvement Backlog

Team Lean MetricsCRC Domain Driven

Design ModelStory Estimates

for Sprint + 1

Track Story Discovery on Team Kanban

Manage Risks, Issues, and

Blockers

Implement Improvements

Update KT Documentation

Conduct Standups

Conduct Retrospective


Blockers



Conduct Daily Standups


Deployment Plan

Help Desk FAQ

Deployed SolutionRelease Notes

Operations Manual User Manual

Track Stories on Kanban


Blockers




Conduct Enterprise Standups

Prioritize demo feedback into

backlog

Validate infrastructure and

environment

Create sprint backlog

Validate business outcomes through business metrics

Track Portfolio Metrics

Define Financials and

ROI

MMFs on Kanban

MMFs on Team Backlog

Stories on Team Kanban

Explore high risk elements

Top ideas ready for business case

MMF Prioritization

Track MMFs & MMF Dependencies on

Enterprise Kanban


Prioritize opportunity based on cost of delay

profile and track on Kanban

Cost of Delay estimates

Implement measurability of

business value for MMF

Triage & Prioritization

New/revised opportunities from plan and execution

progress

Validate Business Value

Identify measurable

business outcomes for MMF

Identify infrastructure /

network / security requirements

Engineer infrastructure /

network / security design

Design data management architecture

Define transition and support

*Customer-problem-solution fit

Setup infrastructure and configure platform

Architecture Review

Rough order of magnitude estimates / T-shirt sized epics

Refined order of magnitude estimates

Definition of Done· Business urgency exists for idea

· Thoughtful dialog concerning major components of idea (business, technology, cost, value, risk etc.) · Opportunity vetted by

appropriate cross functional specialists (business and technical)

Definition of Done· Business and technology specialists have

completed opportunity canvas and

identified riskiest assumptions

· Highest risk assumptions within the

canvas have been evaluated and explored

· Assumptions/risks placed on product

backlog for future validation · Sufficient analysis of story map epics to

support rough order of magnitude / t-

shirt estimates· EA deliverables have been defined

· Business case completed

Refine order of magnitude estimates

Update support guide /operations

manuals

Update deployment plan and support /

operations transition plan

Business assumptions validated through user metrics

Definition of Done· Stories and architecture have been identified sufficiently to support release level estimates

· MMFs identified and prioritized

· Technical requirements identified sufficient to support

downstream infrastructure/operations/other activity

Definition of Done· Explored stories sufficiently to

support story level estimation and

prioritization · Opportunity Canvas assumptions

validated· Major architectural decisions have been made· Technical environment has been

planned/designed sufficiently to

support execution

Definition of Done· Code tested and stabilized at the MMF level · Users have validated business functionality for

MMF· Validated code passes non-

functional requirements· Production Infrastructure &

Environments built and validated

Definition of Done· Validated that MMF code works in production

· Support, operations, infrastructure have confirmed transition MMF ownership · Validate MMF against

business outcomes with metrics

Conduct sprint demo with Product

Owner

Definition of Done· Story spec by example completed· Design and architecture

modelled sufficiently to support story development

· Stories are developed at production level quality

· Code validated at story level by testing and business

Stories ready for hardening

Infrastructure Requirements

Definition of Done· Stories have been articulated to a sufficient level of detail to be pulled into the sprint· Sprint + 1 stories have been

groomed· Execution Environment built and validated

Groomed stories

Support and transition

Support / operations Transition Plan

Support Guide

Triage `̀

Identifystories and acceptance

criteria



Definition of Done· Triaged request sufficiently to identify

stories, cost of delay and prioritization

· Scope is understood for stories

Stories and acceptance criteria Cost of Delay estimates




Blockers

Conduct Standups

Small Work Ideas

Ideas

Small Work Ideas

Re-Prioritized MMFs on Enterprise

Backlog based on execution progress

Environment for Spiking

Plan

Initiate

Small work intake

Legend

Queue

Fixed cadence/ceremony

Artifact description

Artifact

Activity Ongoing Activity

Report Metrics

Report Metrics

Report Metrics

Report Metrics

Execution Environments

EA Context

* A sprint can be defined based on time boxed iterations or establishing Work In Progress limits with cadences

Review architecture

assets

Business (Product owner)

SAEABIM

Key Roles for Initiate


SA

Key Roles for Plan

PM Scrum Master

Analyst / Tester

Dev lead

Key Core Roles for Execute

Scrum Master

Analyst / Tester

Dev

Business (PO)

PM

Key Core Roles for Deploy

Analyst / Tester

Dev

PM Dev Lead

Key Specialist Roles for Deploy

UX Infrastructure / network

Security DBA Reporting

Change Management

Test Automation

Other

Key Release & Transition Roles for Deploy

Release & Deployment

Trainer / Change

management

Key Specialist Roles for Execute



Change Management

Test Automation

Other

Domain Driven Design Model

Refined Architecture

Elaborated Stories

Case study overview: Student and course registration system

During today’s training, we will be referring to the following case study for all examples

In a similar fashion, we will be using a different case study for all of today’s exercises

ACME University would like to create a computerized system that would automate registration for their students.

When the student chooses to purchase a textbook the system should automatically send the request to the ACME University Online Bookstore. This bookstore will then take the students payment information, and process the transaction.

Courses are categorized by credits (1 or 2) , time of day (morning, night), and mandatory or elective. Students should be able to search, sort, and view courses by several criteria.

Senior Professors are responsible for creating degrees and the details around them, and have several requirements from the system.

Professors are responsible for scheduling the course for each semester as well as providing course material such as course notes and the supporting textbook material.

Students who have already registered and been accepted into the university for particular program or degree should be able to log into the system and choose appropriate courses for the upcoming year

Qualification



using canvas




walkthrough


Kanban





on canvas



canvas

Validate financials


MMFs






using CRC


architecture




requirements




Refine Story Map


Criteria






(Planning Poker)



Story Acceptance


Execute



architecture

Story Elaboration





Sprint Planning





Driven Design



Story Development





Story Validation



Example)










Integration Testing


Testing



Testing

Go-Live


Deploy

Deploy Release

Transition



Production Support

Transition to I&O


requirements



Opportunity Canvas


to stories





Complete opportunity canvas

Opportunity Prioritization (EPRB/Shark

Tank)



T-shirt size epics







Prioritized MMFs on

Enterprise Backlog


Regression Testing






Initial story map and epics



Initial CRC model

UX / Wireframes


KPIs for MMF




Coded Stories


Unit Test Coverage



Improvement Backlog



for Sprint + 1



Blockers



Conduct Standups



Blockers





Deployment Plan

Help Desk FAQ





Blockers






backlog


environment





ROI

MMFs on Kanban





MMF Prioritization


Enterprise Kanban









progress


Identify measurable










Architecture Review


















manuals





· MMF’s identified and prioritized · Technical requirements identified sufficient to support







support execution









Owner









Groomed stories



Support Guide

Triage `̀


criteria










Blockers

Conduct Standups

Small Work Ideas

Ideas

Small Work Ideas




Plan

Initiate

Small work intake

Report Metrics

Report Metrics

Report Metrics

Report Metrics


EA Context


Review architecture

assets


SAEABIM



SA

Key Roles for Plan

PM Scrum Master

Analyst / Tester

Dev lead


Scrum Master

Analyst / Tester

Dev

Business (PO)

PM


Analyst / Tester

Dev

PM Dev Lead




Change Management

Test Automation

Other



Trainer / Change

management




Change Management

Test Automation

Other



Elaborated Stories

Initiate

During the Initiate phase, ideas are identified and defined into opportunities

9

The purpose of the Initiate phase is to gather ideas for projects that align to the overall vision and roadmap, and identify high-level goals

10

•Validate that a business need exists for the idea •Have thoughtful dialog concerning the major components of the idea•Vet the opportunity with functional specialists (business and technology)

Qualification

•Complete opportunity canvas and identified inherent risk and assumptions•Create a backlog of, and evaluate the highest risks and assumptions•Analyze story map epics to support rough order of magnitude or t-shirt estimates

•Enterprise Architecture deliverables have been defined •Business case completed


As ideas come into the Initiate phase, they are mapped out on an Opportunity Canvas and their high level goals are identified to create a business case

Idea Opportunity Canvas

Business Idea is mapped on an

Opportunity Canvas

Produce rough order of magnitude

estimates

Evaluate cost of delay profile

Act

ivities

Initial Story Map and Epics

Riskiest Elements Identified

Opportunity Visualization board

Socialize canvas with teams

Complete Canvas and prepare additional agile artifacts to

support business case

Track Idea on Opportunity

Visualization board

Qualification Opportunity Definition

Create a business case

Prioritize duringEPRB / Shark

Tank

Prioritized opportunities

Business Case

Art

ifact

s

Qualification

Qualification – What opportunities are out there?

Overview Practices

New ideas and improvements are identified and are initially triaged through conversations

• N/AIntake ideas and triage

During this stage the idea is assessed against the business strategic roadmap and technology’s strategic roadmap to determine fit for the organization

• N/A

Align to roadmap

Creation of an opportunity canvas to visualize key components of the idea. The purpose of canvassing is to gain alignment and a shared understanding of the idea across various business and technology perspectives

• CanvassingGenerate initial

opportunity model using

canvas

Qualification – What opportunities are out there?

Overview

Definition of Done

•Business urgency exists for idea

•Thoughtful dialog concerning major components of idea (business, technology, cost, value, risk etc.)

•Opportunity vetted by appropriate cross functional specialists (business and technology)

Key Output


Practices

Vet opportunities

through canvas walkthrough

Walkthrough Opportunity Canvas with relevant specialists to validate the different areas of the canvas

• Canvas Refinement

Track ideas on Kanban

The ideas are visualized and tracked on a Kanban board. Visibility ensures the right attention is being placed on the idea by specialists and IT is focusing on bringing in ideas at a rate they can deliver

• Kanban• Standups

“no business plan survives the first contact with customers”

Steve Blank,

Entrepreneur & Thought Leader

Author of The Four Steps to the Epiphany: Successful Strategies for Startups that Win

Lecturer @ Stanford

Traditional tools are not 100% appropriate

15

Planning is important but not so much for the plan it self but for the journey and discovery

“Plans are worthless, but

planning is everything”

Dwight D. Eisenhower,

US President 1953-1961

16

What is an Opportunity Model?

17

What is an Opportunity Model?

An Opportunity Model describesthe rationale of how anorganization creates, delivers,and captures value

18

We require tools to describe, challenge, design, and inventbusiness models more systematically

describes all the parts of the company necessary to drive value

9 Building Blocks

Alexander Osterwalder

19

20

Substitute heavy documentation with a lightweight canvas to drive consensus, collaboration & quickly begin validation

Validated Learning Cycle

1. Co-Create Your Opportunity Canvas with multiple stakeholders

2. Identify the Riskiest Parts of Your Opportunity Canvas

3. Validate, explore top risks / assumptions experiments

5. Verify Business Oriented Metrics of Success (per MMF)

4. Identify Business Oriented Metrics of Success (per MMF)

Initiate

Initiate and Plan

Initiate and Plan

Initiate and Plan

Deploy

The Opportunity Canvas lays out the Opportunity ‘on a page’ to drive a shared understanding across the Team(s)

Customer

Segment /

Business

Area

Key Metrics

of Success

OpportunityKey

Activities

Key

Partners

Cost/Investment Benefit/Revenue

Increments

of Value

Who are our Key Partners?

Who are our Key Suppliers?

Which Key Resources are we acquiring from our Partners?

Which Key Activities do Partners perform?

Key

Resources

What Key Activities are required to realize the opportunity? (e.g. to Build, to Support, etc.)

What are the key milestones associated with a successful deployment of the opportunity?

What is our Unique Value Proposition to our Customer Segments?

What customer problem are we solving?

What major capabilities will address the problems?

What alternatives exists in the marketplace / internally?

What are the key metrics that will tell us whether we received value from the opportunity?

How can value be realized earlier by thinking about the opportunity incrementally?

For whom are we creating value?

Who are our most important customers?

What are the most important costs drivers inherent in our Opportunity?

What is the investment we are will to put to realize the opportunity?

What Key Resources are most expensive?

Which parts of our Plan are most expensive?

What are the top 3 benefits?

What is the cost of delaying this opportunity?

What is the cost of delaying each increment of value for the opportunity?

ProblemCapability

Consider• Adoption Metrics (e.g., Volume,

Net Promoter Score, etc.)• Profitability Metrics• AARRR (Acquisition, Activation,

Retention, Revenue, Referral)

Types of Resources• People (internal Teams,

departments, etc.)• Process (Customer Support,

Dispute Resolution, etc.)• Technology resources

(infrastructure, platform, etc.)• Intellectual Property (brand

patents, copyrights, data, etc.)

Sample Cost Structure Characteristics• Fixed Costs (salaries, rents, utilities)• Variable Costs (ongoing support, technology maintenance)• Economies of Scale

What Key Resources and Capabilities does the Opportunity leverage to be realized?

Types of customer• Users• Influencers• Owner• Other Stakeholders

Classify Cost• Financial ($)• T-Shirt Sizing• Team Size

Product Market

Opportunity Canvas Sample – ACME University Course Registration System

Customer

Segment /

Business AreaFull-time/Part-time Students

Professors

Senior Professors

Department heads can also play the role of professors and senior professors

Opportunity

ProblemCapability

Capability

Automated Course Registration for

Students and Degree/Course

Maintenance for Professors

Automated course searching, information, and registration

Course information will be visible and easily accessible to the students

Ability to manage degree information with the appropriate approval workflow

Ability to store course information and syllabus documents with the appropriate approval workflow

Lack of an automated course registration system causes frustration among students and negatively affects the reputation of the university

Students don’t have a single source for course and degree information

Department heads and Senior professors don’t have a single source for degree information and change approval

Course approval process is managed through emails resulting in delayed approval time and lack of a paper trail

Problem

Benefits Reduced Administrative Overhead (for course registration course refunds, degree management)

Increased Student Satisfaction (Higher Net Promoter Score due to streamlined registration)

Decreased errors due to consistent degree approvals

Reduced Classroom booking time giving more time for teaching and research

Ease of use for students purchasing books from the online bookstore


Key

ActivitiesKey

Partners

Cost/Investment

Online Bookstore Payment team

Course payment team

Key

Resources

Understand current processes

Incorporate payment team(s)

Conduct analysis/design and build new applications systems

Understand infrastructure requirements

Build integrations with other systems

Develop document repository

Conduct regular demonstrations of the product

Open product up to users early on for validation

Subset of end users (students, professors, etc.) and a product owner

Internal knowledge experts who understand how the current processes work in order to integrate the new system

Internal IT application and infrastructure departments

Existing student database, course information database,

Existing online bookstore system, University document management system

New/existing hardware to support the system

New Course and degree management applications

New Class scheduling system

New Application Development costs

Bookstore integration cost

Hardware for new applications

Time commitment from internal knowledge experts


Reduce Temporary staff hired during registration time to X people

Reduce overtime hours for full time registrar office staff by 90% to X hours

By 3rd month of each semester, registrar’s office reduces hours spent on course refund administration by 70% to X hours

Administration process section of the Student satisfaction survey scores above 4 of 5

Average time to book all courses for a student reduced below 1.5 hours

Online bookstore pre-semester purchases of course textbooks increases by 10% during class registration period

Classroom scheduling takes less than 5 minutes per room

Student to course registration without integrated textbook payment

Roll out degree/course management functionality internally per department/faculty

Classroom scheduling rolled out internally per building

Integrate additional course information to student registration

Key Metrics of

Success

Increments of

Value

Opportunity Canvas Sample – Putting it all together

Customer

Segment /

Business

Area

Key Metrics

of SuccessOpportunityKey

Activities

Key

Partners


Increments

of Value

Online Bookstore Payment team

Course payment team

Key

Resources

Conduct analysis/design and build new applications systems (e.g., student registration system, course information system etc.)

Understand infrastructure requirements

Engineer net new infrastructure to for degree information, course information, student registration systems

Build integrations for online bookstore system

Build integrations for course refund system

Course Document repository

Existing databases

Validate solution with key stakeholder groups (professors, dept heads)

ProblemCapability

Internal IT application department

Internal IT infrastructure

Existing student database

Existing course information database

Existing online bookstore system

Existing University document management system

New/existing hardware to support the system

Internal knowledge experts who understand how the current processes work in order to integrate the new system

New Course and degree management applications

New Class scheduling system

Product Market

Automated course searching, information, and registration

Students can purchase textbooks associated with their courses via online bookstore

Ability to manage degree information with the appropriate approval workflow

Ability to store course information and syllabus documents with the appropriate approval workflow

Course information will be visible to the students

Ability to drop courses with automatic refunds

Ability to schedule classrooms for courses

The system needs to support 1,000 concurrent course searches and 500 concurrent enrollments

Lack of an automated course registration system causes frustration among students and negatively affects the reputation of the university

Students purchasing the wrong books or don’t get the correct books resulting in administrative overhead (for returns) and lost revenue

Department heads and Senior professors don’t have a single source for degree information and change approval

Course approval process is managed through emails resulting in delayed approval time and lack of a paper trail

Students don’t have a single source for course and degree information

Manual course refund administration results in overhead costs to the university

Professors spend too much time booking classrooms. Information currently requires professors to search through too many systems and manual entry resulting in wasted time

The student population has been growing and the current enrollment processes are not scaling to support

Reduce Temporary staff hired during registration time to X people

Reduce overtime hours for full time registrar office staff by 90% to X hours

By 3rd month of semester, registrar’s office reduces hours spent on course refund administration by 70% to X hours

Administration process section of the Student satisfaction survey scores above 4 of 5

Average time to book all courses for a student reduced below 1.5 hours

Online bookstore pre-semester purchases of course textbooks increases by 10% during class registration period

Classroom scheduling takes less than 5 minutes per room

Full-time/Part-time Students

Professors

Senior Professors

Department heads can also play the role of professors and senior professors

Student to course registration without integrated textbook payment

Roll out degree/course management functionality internally per department/faculty

Classroom scheduling rolled out internally per building

Integrate additional course information to student registration

New Application Development costs

Bookstore integration cost

Hardware for new applications

Time commitment from internal knowledge experts

Reduced Administrative Overhead (for course registration course refunds, degree management)

Increased Student Satisfaction (Higher Net Promoter Score due to streamlined registration)

Decreased errors due to consistent degree approvals

Reduced Classroom booking time giving more time for teaching and research

Ease of use for students purchasing books from the online bookstore

Breakout Activity

27

Opportunity Canvas

1. Generate an initial Opportunity Canvas for the case study to understand it and gain alignment within your team

2. As you generate the canvas try to think about risks, assumptions or unknowns that embedded in the idea

Team 1

Coach

Team 2

Coach

Team 3

Coach

Team 4

Coach

If your name is not listed here, please see one of the trainers

Opportunity Definition – Should we work on it?

Overview Practices

The Opportunity Canvas may still require additional refinement and socialization with specialists

• CanvassingComplete opportunity

canvas

The opportunity is decomposed into a set of business goals (epics) to understand the high-level goals and objectives . Eventually epics will be further decomposed / refined but the team may decompose at this stage to understand complexity and inform a rough order of magnitude

• Story Mapping• Epics

Outline story map

The riskiest business assumptions are extracted from the canvas, so that they can be validated through experimentation (e.g. solution, scope, team / capacity, cost / benefits, etc.)

Identify riskiest

elements of model on canvas

• Validated Learning


Define and build rough order of magnitude

For the opportunity (or epics) identify a rough order of magnitude (size / effort) in collaboration with business and technology

• T-Shirt Sizing


Explore top risks to mitigate, or assumptions to validate through research, proof of concepts, spikes, surveys,

feature stubs, segmentation analytics, etc.

• Validated Learning

A business case around the opportunity is created to highlight what the key benefits and costs / resources of this opportunity

• N/ADevelop business case

/ PRF

Overview Practices


Initiate / continue to vet the opportunity canvas and / or business case with the appropriate business and technology specialist


canvas

• N/A

Validate financials within the business case with financial specialists

Validate financials

• N/A

Identify the overall cost of delay by not having this opportunity realized today (e.g. loss of revenue, inability to decrease cost, etc.). Leverage this estimate to prioritize the opportunity against other IT priorities

Prioritize opportunity

based on cost of delay profile

• Cost of Delay

Overview Practices


Definition of Done

•Business and technology specialists have completed opportunity canvas and identified riskiest assumptions

•Highest risk assumptions within the canvas have been evaluated and explored

•Assumptions/risks placed on product backlog for future validation

•Sufficient analysis of story map epics to support rough order of magnitude / t-shirt estimates

•EA deliverables have been defined

•Business case completed

Key Output

Prioritized opportunities on

EKB

Review high level architecture to understand the impact on the current enterprise architecture landscape (e.g. buy, build, existing capability, etc.)

Review architecture

assets

• N/A

Overview Practices

Build story map outline

33

Actor or Persona

Epic

Register for degree and enroll in courses

Buy textbooks

Manage degree

Manage courses

Schedule a classroom

Part-time Student

Full-time Student

• In some instances this it the team may go further and break the epics down to understand the underlying complexity and reach a rough order of magnitude

• This information will feed the business case which will be used to determine the priority of the project

Let’s explore this further

Senior Professors

Professors

Senior Professors

Professors

Build story map outline

34

Actor or Persona

Epic Buy textbooks

Part-time Student

Full-time Student

Activity Purchase Textbook

View required reading

Link to online

bookstore

Select a textbook

Send purchaserequest

Add to shopping

cart

Choose shipping method

Process Purchase Transaction

Receive payment

info

Process payment

Receive shipping

info

Send purchase confirm.

Story

Types of Risk

35

• Incorrect Prioritization of risk is one of the top contributors of waste found in delivery

• A successful delivery of an opportunity is fundamentally about managing and systematically mitigating risk

• Risk Definition: A state of uncertainty where the outcome of the possibilities involve a loss, catastrophe, or other undesirable outcome

• Key to driving value early is to prioritize the riskiest elements on your opportunity canvas

• Risk can be broken down into the following categories

– Value Risk - Understanding the need, solution and customer fit

– Technical Risk – Having the right technological infrastructure, skillsets and architecture to meet the need

– Delivery Risk – Having the right capabilities available to deliver

Sections of the Opportunity Canvas are more often associated with specific types of risk

commonly

Customer

Segment /

Business

Area

Key Metrics

of Success

OpportunityKey

Activities

Key

Partners


Increments

of Value

Top 3 Reasons

Cost of Delay

What teams will need to work on this opportunity?

What resources are required from these teams?

What key activities do these partners perform?

Are any external vendors key partners?

Key

Resources

What Key Activities are required to realize the opportunity? (e.g. to Build, to Support, etc.)

What are the key milestones associated with a successful implementation of the opportunity?

What is our Unique Value Proposition to our Customer Segments?

What customer problem are we solving?

What major capabilities will address the problems?

What competitive alternatives exists in the marketplace?

What Key Resources and Capabilities does our Opportunity leverage for being successful in the market?

What are the key metrics that will tell us whether we received value from the opportunity?

How to deliver 1st increment?

What are the benefits of each increment? (E.g., We want to do X to achieve Y)

Users

Influencers

Owner

Other Stakeholders

Financial ($)

T-Shirt Sizing

Team Size

What are the most important costs drivers?

What Key Resources are most expensive?

Which parts of our Plan are most expensive?

Top 3 Benefits

Increased revenues

Maintaining revenues

Cost savings

Cost maintenance

ProblemCapability

Consider• Adoption Metrics (e.g., Volume,

Net Promoter Score, etc.)• Profitability Metrics• AARRR (Acquisition, Activation,

Retention, Revenue, Referral)

Types of Resources• People (internal Teams,

departments, etc.)• Process (Customer Support,

Dispute Resolution, etc.)• Technology resources

(infrastructure, platform, etc.)• Intellectual Property (brand

patents, copyrights, data, etc.)

Sample Cost Structure Characteristics• Fixed Costs (salaries, rents, utilities)• Variable Costs (ongoing support, technology maintenance)• Economies of Scale

V

T T

D

VD

D V

V

V

T

D

• Value Risk

• Technology Risk

• Delivery Risk

The Opportunity Canvas can be used to think through risks and identify assumptions that

need to be validated

Value Risk

Technical Risk

· Do the Customer Segments consider this their top pain point(s)· Does our Opportunity (set of capabilities) address our Customer Segment’s top problems? · Do I have early adopters within my Customer Segments who really want to use the Opportunity’s capabilities

now?· Does the Opportunity identify a unique value proposition in comparison to current competitors or existing

alternatives?· Do our Increments of Value resonate with our Opportunity to our Customer Segment?· Does this Opportunity support our current and future brand in the marketplace or internally?· Is our Customer Segment (Market Size) large enough to sustain a long term solution? Are our Benefits

sustainable?· Is solving our Customer Segment’s problem(s) worth the Investment required to realize the capabilities? · Does my Opportunity break into a set of Value Increments that can be released to the Customer Segments?· Does my Increments of Value quantify its cost of delay? · Do the top Increments of Value maximize the value delivered to the Customer Segments?· Does our Opportunity cater to the diversity of the Customer Segments?

· Is the solution technically feasible? What are the riskiest / uncertain parts of the architecture? Where are key integrations points?

· Does the organization have the Key Resources (capability, competence, etc.) to deliver the opportunity?· Are there Key Activities (development, ongoing support, etc.) require procurement of any new technologies

(Cost)?· Are our Key Partners able to provide the necessary technical capability to deliver the opportunity?

DeliveryRisk

· Are the timelines for the Increments of Value reasonable (internally, key partner)? · Which parts of my product depend on the ability of our Key Partners? Internal Key Resources?· Do we have a good working relationship with our Key Partners? Past Experience?· What risks are introduced if certain Key Resources are Resources?· Do we have the Key Resources available to deliver this Opportunity?· What Key Resources provide us an acceleration to meet the Opportunity?· Have we identified post deployment support (Key Activities & Key Resources)?

Visualizing and Tracking our Risk, Assumptions and Unknowns will enable common awareness, alignment and prioritization of the riskiest elements

Use a Risk / Assumptions / Unknown Validation Board to track and prioritize the risks/assumptions

Example Risk / Assumption / Unknown Validation Board

Risk / Assumptions Backlog Plan Validate Learn

Value Risk

Technical Risk

Delivery Risk

Other Risk

Consultation

Proof of Concept

Research / Analysis

Risk / Assumption

Legend

2. Track the risks / assumptions / unknowns related to an idea on the Validation board as the idea goes through the initiate phase

1. Identify the top priority risks that would must be explored before a business case can be completed

Visualizing and Tracking our Risk, Assumptions and Unknowns will enable common awareness, alignment and prioritization of the riskiest elements

Example Risk / Assumption / Unknown Validation Board

Risk / Assumptions Backlog

Value Risk

Technical

Risk

Delivery Risk

Other Risk

What existing payment

processing capabilities

does the university use?

Does the bookstore

system have existing

integration points for

external systems?

Does the Internal IT

department have the

required skills/capacity

to implement a solution?Will the solution greatly

increase the

maintenance budget on

an ongoing basis?

Validate with professors

which component would

provide the greatest

immediate benefits.

(E.g., course, degree,

classroom management)

Can any increment of

value be delivered

before the next

semester?

Priority

These risk / assumptions / unknowns would be explored as part of opportunity planning, unless it has a material impact of the effort / benefits

To support agile delivery, we need to be able to decompose an idea into smaller components

“Sea level”Activities refined by Scrum Team; still too big to be completed within a sprint“Fish level”Stories identified by Scrum Team; can be completed within a sprint

“Kite level”Business or Architecture Epics defined in intake; need to be refined and decomposed by Delivery Teams

Too abstract – Release (e.g. MMF)

Tasks - Too detailed

Receive and route work to the right person efficiently to meet service standards

Description Example

• Intake Work• Create Work Request• Categorize Work

Request

• Ability to accept work via fax

• Ability to record phone calls

• Ability to accept work via mail

Manual telephony and document mgmt with automated workflow mgmt and routing

Epics Explained

There are four key ingredients that makes up a Epic:

Customer Segment – Who is the user?

Need / Want – What is the functionality or capability we want to provide?

Business Benefit – Why are we doing it?

Large Effort Deliver – Complex, Unknown, Risky, Big

e.g.,

For Serve Customers, we want to support US$ transfers from Serve Accounts to local Mexico Banks so that we can gain new revenue from transaction fees

For Operational Risk, we want to identify and manage fraudulent transactions so that we can reduce loss of revenue

“For [Customer Segment], we want to [fulfill a need] so that we can [drive a business benefit]”

Standard Format for Epics:

Story Mapping is a systematic decomposition of a idea into smaller units of work (Epics, Activities, Stories) so that the work is refined and without gaps

Focus for Opportunity Definition

The Story Map gives a canvas to paint the initial scope of the opportunity which will be leveraged for the purpose of estimating effort for the opportunity

Optionally stories can be identified to help understand the order of magnitude of the Epic

Epics will be further refined upon prioritization of the opportunity and assignment of a delivery team

Additional Decomposition

is optional

1

2

3

Sample T-Shirt sizes facilitate consistent estimation

Small

modifications to

existing

functionality

Architecturally

insignificant

Few dependencies

but only involves

one Team

Similar to work

done in the past by

Team

No new

technologies

involved

More significant

modifications to

existing

functionality

Minor architectural

changes

Few dependencies

across 1-2 Teams

Precedents exist

for the work but

Teams

inexperienced in

doing it

May involve new

technologies

No existing

functionality to

leverage

Major architectural

changes required

Multiple

dependencies

across multiple

Teams

No precedents for

the work / no

experience on the

Teams

Involves new

technologies

Small Medium Large

Borderline

Story

Consider Further

Decomposition

Small

modifications to

existing

functionality

Architecturally

insignificant

Only involves one

Team

Similar to work

done in the past by

Team

No new

technologies

involved

X-Small

No existing

functionality to

leverage

Major architectural

changes required

Multiple

dependencies

across multiple

Teams

No precedents for

the work / no

experience on the

Teams

Involves new

technologies

X-Large

Points: 30# of Sprints: 1





The suggested mechanics for sizing epics

Epic 1 Epic 2 Epic 4Epic 3

1

Pull from Story Map the epics

that need sizing

2Set a reference point / baseline, i.e., an Epic from the set that is medium sized

Small Size

‘Bucket’

Medium Size

‘Bucket’

Large Size

‘Bucket’

3

Perform silent placement of the remaining Epics into size buckets based on relative size (participants pull Epics and place in buckets until all Epics are placed)

Epic 6Epic 5

Epic 4

Epic 6

Epic 1

Epic 5

Epic 2

4Every participant gets 3 ‘re-shuffles’ if they don’t like the initial placement

Epic 3 Discuss results focusing on re-shuffled items and ‘fist to five’ as a group on the comfort-level with them

…

Not at all

I’d rather not, but I could change my mind if…

Absolutely

No, unless….

OK

Yes

5

Breakout Activity

45

Opportunity Epics & Initial Story Map

1. Refine the opportunity canvas as needed

2. Identify a list of epics utilizing the format of: For [Customer Segment], we want to [fulfill a need] so that we can [drive a business benefit]

3. Contextualize the Epics by laying them down into a story map format

4. Extract and prioritize risk / assumptions (from the canvas and / or story map). How would you mitigate / validate the top 5?

Qualification



using canvas




walkthrough


Kanban





on canvas



canvas

Validate financials


MMFs






using CRC


architecture




requirements




Refine Story Map


Criteria






(Planning Poker)



Story Acceptance


Execute



architecture

Story Elaboration





Sprint Planning





Driven Design



Story Development





Story Validation



Example)










Integration Testing


Testing



Testing

Go-Live


Deploy

Deploy Release

Transition



Production Support

Transition to I&O


requirements



Opportunity Canvas


to stories







Tank)



T-shirt size epics







Prioritized MMFs on

Enterprise Backlog


Regression Testing









Initial CRC model

UX / Wireframes


KPIs for MMF




Coded Stories


Unit Test Coverage



Improvement Backlog



for Sprint + 1



Blockers



Conduct Standups



Blockers





Deployment Plan

Help Desk FAQ





Blockers






backlog


environment





ROI

MMFs on Kanban





MMF Prioritization


Enterprise Kanban









progress


Identify measurable










Architecture Review


















manuals












support execution









Owner









Groomed stories



Support Guide

Triage `̀


criteria










Blockers

Conduct Standups

Small Work Ideas

Ideas

Small Work Ideas




Plan

Initiate

Small work intake

Report Metrics

Report Metrics

Report Metrics

Report Metrics


EA Context


Review architecture

assets


SAEABIM



SA

Key Roles for Plan

PM Scrum Master

Analyst / Tester

Dev lead


Scrum Master

Analyst / Tester

Dev

Business (PO)

PM


Analyst / Tester

Dev

PM Dev Lead




Change Management

Test Automation

Other



Trainer / Change

management




Change Management

Test Automation

Other



Elaborated Stories

Plan

During the Plan phase, the prioritized opportunities are refined and broken down to MMFs and stories that are ready to be delivered

The purpose of the Plan phase is to further define high-level requirements and identify solution options

48

• Enable a common understanding of the business vision across the team• Provide a sandbox for the delivery team to explore solution options• Decompose the business vision into smaller units of work and prioritize

releases to drive business value early and incrementally• Investigate key unknowns, risks and assumptions

Opportunity Planning

• Decompose the selected release scope into stories with acceptance criteria • Collaboratively estimate the effort required to deliver stories• Design solution architecture• Allocate stories to teams and prioritize stories on the backlog based on

business value

Release Planning

(Pre-Sprint)

Opportunity Planning – When will we deliver it?

50

Conduct a set of workshops to build the initial story map and identify key risks, unknowns and questions. Significant unknowns and assumptions are investigated while other localized unknowns and assumptions are investigated as part of Story Exploration and Architecture Exploration.

Story Identification

• Story Mapping • Canvas

Exploration• Cost of Delay

Identify the solution architecture to create a high-level understanding of the solution and how the system interacts with external interfaces. The team also identifies non-functional infrastructure, network, and security requirements.


• CRC Modeling• Architecture

Modeling• Key Mechanism

The rough order of magnitude estimates determined during the Initiate phase are refined to help understand potential release timelines for increments of the opportunity.


• T-shirt Sizing• Planning Poker

Overview Practices

Opportunity Planning – When will we deliver it?

51

Definition of Done

• Stories and architecture have been identified sufficiently to support release level estimates

• MMFs identified and prioritized

• Technical requirements identified sufficiently to support downstream infrastructure/operations/other activity

Key Output

Prioritized MMFs on enterprise

backlog

The stories are grouped into MMFs (releases)based on several factors, such as business value, development cost, dependencies, and the amount of risk removed by implementing the story. The MMFs are visualized on IT’s enterprise kanbansystem for common awareness and impediment escalation

Group stories into MMFs

and prioritize on EKB

• Story Mapping• Enterprise

Kanban

Overview Practices

Story Identification

52

The lifecycle and evolution of a story

53



Release Planning

Backlog Grooming and Sprint Execution

MMF1

Build the initial story map

54

Actor or Persona

Epic


Buy textbooks

Manage degree

Manage courses


Part-time Student

Full-time Student

Senior Professors

Professors

Senior Professors

Professors

Activity

Search for available degree

Register for degree

Search for a course

Sort search results

Enroll in course

• Build out the activities for each Epic

Build the initial story map

55

Actor or Persona

Epic


Buy textbooks

Manage degree

Manage courses


Part-time Student

Full-time Student

Senior Professors

Professors

Senior Professors

Professors

Activity

Search for available degree

Register for degree

Search for a course

Sort search results

Enroll in course

• Identify initial stories for each activity

• Not all stories may be known at this point and should be considered for later MMFs

Enter user details

Create login credentials

Login

Login as guest

Login w/ Google

Login w/ Twitter

Search by name

Search byfaculty

Search byspecializ.

Story

Your initial story map should look something like this:

56

Epic

Activity

Story

Persona


57

System Context

58

• System Context Diagrams are diagrams used to define the system boundaries (i.e. system under discussion) and represent interactions between the system under discussion and external systems/interfaces

• These diagrams usually picture the system at the center, with no details of its interior structure, surrounded by all of its interacting systems, environments and activities.

• Often, the System Context Diagram can be supplemented with Domain Driven Design interaction patterns (e.g. Anti-corruption layer). Below is an example of a system context diagram:

Purpose

Sample System Context Diagram

59

Course Registration

System

Online Book Store

Degree and Course

Management System

University Document

Management System

Room Booking System

LDAP

Authenticate

Authenticate

Schedule Classrooms

Purchase Books

Stores / Uploads Course Content

View / Download Course Content

Update Course and Degrees

Key Mechanism Overview

• Key mechanisms are solutions to a common recurring problem within the system

• Explicitly call out aspects of the solution mechanics that are common across the system. This helps you plan.

• Put down markers for the developers to build those aspects of the system once and then re-use them. This reduces the workload.

• Promote the development of a consistent set of services. This makes the system

easier to maintain.

An initial cut at the mechanisms that will form the backbone

of the architecture of the system

Key Mechanism Sample

Corporate Data Warehouse

Description: One of the requirements as part of this project is the desire to have management reports on how long it takes to process registrations as well as the number of successful, unsuccessful and declined registrations.

Key Participants: Versions of the registrations persisted into the Course db2 database will be extracted and persisted into the corporate data warehouse on a regular basis to meet reporting requirements. Reports can be written and run from this data when required using Cognos or Sas.

Google Web Toolkit:

Description: One of the architecture principles that we are implementing in this project is “to enable ease of extendibility” of the functionalities provided within the application.

Key Participants: GWT will act as View layer in our Spring Model View Controller framework. So it will work with our Controllers as well as our Spring configuration mechanism.


62

Group stories into MMFs and determine rough order of magnitude

63

Epic

Activity

Story

Persona

MMF 1 – Basic functionality for students to register and enroll in courses online

MMF 2 – Basic functionality that allows senior professors to create and manage degrees and courses

MMF 3 – Additional search and sort functionality for degrees and courses. Students can drop a course online?

Cost of Delay Profiles: How much does queuing cost us?

64

Week 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

Value Add

Risk Reduction

Waiting

Opportunity Identified

10 Weeks waiting

11 Weeks waiting

9 Weeks waiting

PoC

(24 hrs)

Dev & Test

(160 hrs)Go-Live

• Your organization has identified an Epic with the cost of delay being $150,000 per week. The value stream below illustrates the progression of the Epic through an organization’s system of work:

• How much did queuing, or waiting time cost this organization?

The 30 weeks that this opportunity spent waiting in various queues cost the organization $4.5m in lost revenues

Cost of Delay: Putting a price tag on time

65

Cost of Delay

Business value of the increment

Information Discovery of Value

How value decays over time

A framework for thinking about value

66

Protect Revenue

Reduce Costs

Increase Revenue

Avoid Costs

Increasing sales to new or existing customers. Delighting or Disrupting to increase market share and size

Improvements and incremental innovation to sustaincurrent market share and revenue figures

Costs that we are currently incurring, that can be reduced. More efficient, improved margin or contribution

Improvements to sustain current cost base. Costs we are not currently incurring but may do in the future

Without information about

VALUEthe system optimizes for other things

Why should this surprise anyone?

Cost of delay

o Creates focus on value for money

o Enables better trade-off decisions

o Changes the focus of the conversation

Value

Increase Revenue

Increasing sales to new or existing customers. Delighting

or disrupting to increase market share and size to

attract additional revenue

Protect Revenue

Sustaining our current market share and revenues through

incremental innovation and improvements for

existing customers

Reduce Costs

Reducing costs that we are currently incurring. Ideas that make things

more efficient, improving margin or contribution

Avoid Costs

Costs that we are not currently incurring but may do in the future.

Improvements to avoid likely increases in our

cost base

Urgency1. Long-life cycle. Peak unaffected by delay 2. Short-life cycle. Peak affected by delay

3. Long-life cycle. Peak affected by delay 4. Impacted by an external deadline

Cost of Delay profiles

Estimates worksheet

MMF 1

MMF 2

MMF 3

Cost of Delay template

• Make estimates for the top MMFs or increments of value

MMF 4

Implementing basic functionality to automate student registration reduces overhead costs and error during each semester. These costs of delay follow a cyclical pattern

Implementing basic degree and course management for senior professors also provides a cyclical benefit, but the magnitude is reduced as the benefit applies to fewer users

Additional search and sort functionality for degrees and courses provides an unknown cyclical benefit

Displaying textbook and additional course information provides an unknown cyclical benefit

?

?

Breakout Activity

71

Initial Story Map

1. Continue building your Story Map by decomposing the epics into stories2. Brainstorm on how stories could be grouped into a set of MMFs (incremental releases of value)

• Note: At this stage not all stories across every release needs to be identified, consider allocating a # of stories for later MMFs

System Context Diagram

1. Describe the solution and key behaviors through a system context diagram

Key Mechanisms

1. Identify common, reoccurring problems in the system2. Describe a high level key mechanism for these problems

Cost of Delay Profiles

1. Identify the Cost of Delay profile for each MMF2. Prioritize the MMF based on the cost of delay

Release Planning

Release Planning (Pre-Sprint) – How should we deliver it?

Overview Practices

Continue to refine the story map while creating story sketches for each user story to build additional detail. Validate key assumptions extracted from the opportunity canvas.

Story Exploration

• Story Mapping• Story Sketching• Persona Definition• Wireframing• Planning Poker• CRC Modeling

Elaborate on the architecture, including key mechanisms and non-functional requirements. The team may develop an executable architecture that represents a working, deployable solution to validate architecture risk in the system.


• Key Mechanism Design

• Spiking

Identify measureable success criteria that evaluate an MMF against business outcomes. These outcomes should be based on the opportunity canvas. As MMFs are released, they are evaluated based on real usage and the canvas can be validated or modified.

Identify measureable

business outcomes for

MMF

• Lean Metrics• Canvas Refinement

Release Planning (Pre-Sprint) – How should we deliver it?

Definition of Done

• Explored stories sufficiently to support story level estimation and prioritization

• Opportunity Canvas assumptions validated

• Major architectural decisions have been made

• Technical environment has been planned/designed sufficiently to support execution

Key Output

Stories on team backlog

Overview Practices

Delivery teams coordinate with change management, release management and the business to ensure that the business is ready to accept the release.

Define transition and

support

• Agile Planning

The team meets with the business to validate that the MMF is ready for delivery. This includes final validation of the acceptance criteria and story estimates.

Story Acceptance

• Acceptance Review

Story Exploration

75

Refine the story map

76

Epic

Activity

Story

Persona

MMF 4 – “Buy a textbook” functionality and displaying additional course information

New story

New story

New story

New story

• The team may continue to refine the story map, adding new stories or removing obsolete stories; additional MMFs may be identified as the story map evolves

• Each story within an MMF will be explored through story sketching

Story Sketch Sample

77

When the student clicks on register course

Student

Course Registration System

And viewing course information

Given the student has selected a course

Given the student has selected a course

And a message is given for successful registration

Then the student is registered for the course

When the student clicks on register course

Questions / Risks / Unknowns

Unknown: How quick ly does the course need to appear on the

Unknown: What other scenarios exist to where a registration

might be unsuccessful

And a message is given for why the course registration is

unsuccessful

Then the student is not registered for the course

And viewing course information

5

Submit a course selection

Users/Personas and Systems Involved Free Drawing

Specification By Example

Story Name

MMF # Story ID Estimate Size (days)1 XYZ

Story Summary

As a Student

I want to submit a course that I've selected

So that I can register for a course

Story Summary Acceptance CriteriaAppropriate message is provided for a successful or failed (e.g.

full or canceled) course registration

Confirmation number is generated for the successful registration

Any changes student's courses is reflected on student's profile

Student

PictureStudent Information

Selected Course Name

Course DescriptionCourse Schedule Calendar

Navigation

Pane

Register for Course

button

Search for Course

Story Sketch Sample

78

79

Class Responsibility Collaboration (CRC) Modeling

• A CRC model is a collection of CRC cards that represent whole or part of an application or problem domain

• The most common use for CRC models, is to gather and define the user requirements for an object-oriented application

• Cards that collaborate with one another are close to each other, cards that don’t collaborate are not near each other

• CRC models are created by groups of business domain experts, led by a CRC facilitator who is assisted by one or two scribes. The CRC facilitator is responsible for planning and running the CRC modeling session

What is CRC Modeling?

• CRC modeling relies on natural language to describe concepts and their relationship to each other making it much easier for users and business subject matter experts to participate

• With business actively involved, buy-in for the potential solution is greatly increased

• People who understand the problem and business domain are the ones who create the model and this ensures the right model is developed

Benefits

80

CRC Modeling

• A CRC card is a standard index card that has been divided into three sections

• A class represents a collection of similar objects. An object is a person, place, thing, event, concept, screen, or report that is relevant to the system at hand. The name of the class appears across the top of the card.

• A responsibility is anything that a class knows or does. For example, customers have names, customer numbers, and phone numbers. These are the things that a customer knows. Customers also order products, cancel orders, and make payments. These are the things that a customer does. The things that a class knows and does constitute its responsibilities. Responsibilities are shown on the left hand column of a CRC card.

• Sometimes a class will have a responsibility to fulfill, but will not have enough information to do it. When this happens it has to collaborate with other classes to get the job done. The collaborators of a class are shown in the right-hand column of a CRC card.

CRC Card

CRC Sample

81

CRC Sample – Visualizing how to model interactions within the domain (i.e. University Course Registration)

82

Collaborates


83

Identify measureable business outcomes for MMF

84


85

Story Acceptance

86

Prioritize your stories within the MMF for Execution

87

Epic

Activity

Story

Persona

2

3 4

• As the team identifies the priority of the stories for a given MMF, the Sprint Execution backlog or Kanban backlog may be built accordingly

1

Breakout Activity

88

Refined Story Map

1. Review your Story map and refine any stories focusing on the first release that has been identified

Acceptance Criteria & Story Sketches

1. Complete a story sketch for 2-3 stories identified in your first release2. Define only the acceptance criteria for the remaining stories

CRC Model

1. Build an initial CRC model for the system2. Identify all domain objects, their responsibilities, and other domain objects they collaborate

with

Planning Poker

1. Collaboratively estimate the size of the stories in MMF1 using Planning Poker2. Discuss differences in estimates due to differing assumptions

Story Prioritization

1. Prioritize the stories in MMF 1 so that they are ready for execution2. Prioritization factors include value delivered, cost, risk mitigated, degree of risk mitigated, etc.

Qualification



using canvas




walkthrough


Kanban





on canvas



canvas

Validate financials


MMFs






using CRC


architecture




requirements




Refine Story Map


Criteria






(Planning Poker)



Story Acceptance


Execute



architecture

Story Elaboration





Sprint Planning





Driven Design



Story Development





Story Validation



Example)










Integration Testing


Testing



Testing

Go-Live


Deploy

Deploy Release

Transition



Production Support

Transition to I&O


requirements



Opportunity Canvas


to stories







Tank)



T-shirt size epics







Prioritized MMFs on

Enterprise Backlog


Regression Testing









Initial CRC model

UX / Wireframes


KPIs for MMF




Coded Stories


Unit Test Coverage



Improvement Backlog



for Sprint + 1



Blockers



Conduct Standups



Blockers





Deployment Plan

Help Desk FAQ





Blockers






backlog


environment





ROI

MMFs on Kanban





MMF Prioritization


Enterprise Kanban









progress


Identify measurable










Architecture Review


















manuals












support execution









Owner









Groomed stories



Support Guide

Triage `̀


criteria










Blockers

Conduct Standups

Small Work Ideas

Ideas

Small Work Ideas




Plan

Initiate

Small work intake

Report Metrics

Report Metrics

Report Metrics

Report Metrics


EA Context


Review architecture

assets


SAEABIM



SA

Key Roles for Plan

PM Scrum Master

Analyst / Tester

Dev lead


Scrum Master

Analyst / Tester

Dev

Business (PO)

PM


Analyst / Tester

Dev

PM Dev Lead




Change Management

Test Automation

Other



Trainer / Change

management




Change Management

Test Automation

Other



Elaborated Stories

Execute

During the Execute phase, the stories are further groomed in order to be developed into working features that deliver value

The purpose of the Execute phase is to elaborate on requirements and iteratively build working software

91

•Iteratively deliver tested software focusing on highest business value first•Build quality using a single source of truth for requirements and test cases•Provide the Product Owner with a demonstration of the software

Sprint Execution

•Elaborate on stories for next sprint to clarify assumptions•Prioritize stories based on business value and clarified assumptions•Setup environments and infrastructure to execute sprints

Backlog Grooming

•Stabilize code and stories and ensure they are ready for deployment•Provides an opportunity to fix bugs and defects•Ensure that everything is working end-to-end

Hardening

Execution Cadences

92

Backlog Grooming every 2-4 weeks

Sprint Execution every 2-4 weeks

Hardening

every 4-8 weeks

Next

Ongoing Activities

• Daily Stand-up

• Resolve / raise risks, issues and blockers

• Manage WIP and Velocity through Metrics

• Track / Implement Improvements

• Product Demos

Retrospective and Product Demo

every 2-4 weeks

Leadership Updates / Escalation

Executive Escalation

Backlog Grooming

Backlog Grooming – How will the work be done?

94

Spike key mechanisms and update

design

Story Elaboration

Sprint Planning

To validate solutions to recurring system problems, the team spikes key mechanisms (a spike solution is a very simple program to explore potential solutions). As unknowns and assumptions are explored, the team updates the architecture.

Practices

• Key Mechanism• Spiking

Overview

The requirements for each User Story are expressed as business scenarios. The scenarios are documented using real examples/data in the ‘Given, When, Then’ structure of Specifications by Example.

• Specification by Example

• CRC• Domain Driven

Design• Wireframing

The team refines the estimates for next sprint’s stories and commits to the amount of work they can complete in the next sprint based on past performance metrics.

• Planning Poker

Backlog Grooming – How will the work be done?

95

Setup Infrastructure & Configure Platform

Definition of Done• Stories have been articulated to a sufficient level of detail to be

pulled into the sprint

• Next sprint’s stories have been groomed

• Execution environment built and validated

To ensure that the developed stories can be deployed on time, any infrastructure and platforms required to support the stories are setup and configured.

Key Output

Groomed Stories

Practices

• N/A

Overview

Story Elaboration:

What is Specification by Example?

Specifications by Example Overview

What is Specification By Example?

• A Collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements

• The objective is to focus development and delivery of prioritized, verifiable, business requirements

• Supports a very specific, concise vocabulary used by everyone on the team (known as a ubiquitous language)

• Can be used as a direct input into building automated tests that reflect the business domain

• Enable executable requirements

• While Specification by Example is relatively new, it is simply a rephrasing of existing practices, not a radically new departure

• Created by a cross-functional team, it captures everyone's understanding

Specifications act as the single source of truth about functionality during delivery

Thin slices of system behaviour

That describe business value

Described as concrete / real life examples

That are testable without translation

To create executable requirements

Captured in live documentation

What do Specifications By

Example Represent?

Specifications by example are a better way to do acceptance testing

• One single artifact used for both testing and detailed requirements

• Automation allows instant understanding of the impact of a requirement change on the solution

• No ambiguity in progress of the project

• A test is either passing for a requirement (it's complete) or it's not

• A project that has 70 behaviors completed, and requires 100 to be finished, it's only 70% finished

• Requirements become explicit, executable

• Testers switch from defect fixing to defect prevention, and they contribute to the design of the solution

Advantages

Why Should You Care?

Business Analyst • Requirements will be unambiguous and

without functional gaps• Developers will actually read the

specifications

Developer • Developers will better understand what is being developed

• Development progress can be better tracked by counting the amount of Specifications that have been correctly developed

Tester• Testers will better understand what

is being tested• Testers will be involved from earlier

on and play a role in design

Everyone • Time will be saved by catching mistakes earlier on

• Quality will be built in from the start

Key Process Patterns of Specification by Example

Source: Adzic, Gojko. Specification By Example - How successful teams deliver the right software. 2nd ed. New York: Manning Publications Co, 2012. Print.

Focus on building the right productAnd

building the product right

How to Write Specifications by Example

Improved understanding by both the business and the technical

team

Validates correctness of the

system

Business Scenarios

describing the behaviour of the

system

Example data

Executable Acceptance

Tests

Acceptance Scenarios

The Team Produces Result

Clients

Business Analysts

Testers

Developers

Speaking in a ubiquitous language to gain a common consensus on the objectives of the system being built

Specification by Example provides a collaborative mechanism to detail requirements

UI Mockups

Supplementary Business Rules

Domain Model

The Composition of a Specification by Example

• Sample format for a story can be:

• Who - As a … CustomerSalesRepresentative

• What - I want to … select a TN for a customerDevice order

• Why - So that … I can map a TN to a Device SKU for order provisioning and activation

Sample Story Format Management practice*invest qualities of stories*

Independent

Negotiable

Valuable

Estimate

Small

Testable

…

Plan

Acceptance Scenario A

Acceptance Scenario B

Acceptance Scenario A: testcase 2


Acceptance Scenario B: testcase 1

Spec DocumentStory X

Story CardAcceptance

Criteria

UI Mockup

Supplementary

Business Rules


• Acceptance Scenarios• Provides explicit, unambiguous requirements• A scenario is an example of the system’s behavior from one or more users’ perspective• Each Acceptance Scenario is broken down into Acceptance Test cases

Examples = Acceptance Criteria Building Examples

Acceptance Scenarios are specified using the following structure to create a testable story:

Given <some precondition>And <additional preconditionsWhen <an action/trigger occurs>Then <some post condition>And <additional post conditions>

Use And to provide further context for the feature. Similar to Use Case development

…

Plan








Criteria

UI Mockup

Supplementary

Business Rules


They should be further expanded into the Given/When/Then format:

• Given the Account is a triple play account,

• And an Order has been created,

• And a Device has been selected,

• And one or more non-portedTNs are available

• When the OrderManagementSystem provides a list of available non-ported TNs,

• And the CustomerSalesRepresentative selects a TNfor the Device

• Then the OrderManagementSystem maps the selected TN to the Device SKU in the Order

Writing Acceptance Scenarios for the Story

Initially Acceptance Scenarios can be written as simple testable statements that the story must satisfy:

• CustomerSalesRepresentative can select a non-ported TN and map it to a new device

• CustomerSalesRepresentative can select a ported TN and map it to a new device

• CustomerSalesRepresentative can select either a ported or non-ported TN and map it to an existing device the customer already has

…

Plan








Criteria

UI Mockup

Supplementary

Business Rules

Example for Specification By Example – ACME University

Story: Create a Course

Given a Senior Professor is logged in;

And the create course option has been selected;

And the course does not already exist

When course name is entered and submitted;

Then a course is created with a unique ID;

And a message is given for successful submission

Another Example for Specification By Example – ACME University

Story: Purchase Textbook

Given a Student is logged in;

And a textbook has been selected;

And the textbook is not out of stock;

And a shipping method has been selected;

And billing information is complete

And shipping information is complete

When the Student clicks Purchase;

Then send the payment information to the 3rd party;

And send Order Details to the bookstore;

And a message is given for successful submission

A Closer Look at Sprint Planning

108

Stories Ready for Execution

Outstanding Quality Issues

Prioritize and select work to capacity

Initiate Sprint Planning

Refine estimates as necessary

Team Backlog

Sprint Backlog

Breakout Activity

109

Initial Specifications by Example

1. Identify scenarios and create Specifications by Example for the stories in MMF 1 using the “Given, When, Then” format

2. Identify all pre conditions (Given), actions/triggers (When), and post conditions (Then) for each story

Sprint Execution

During Sprint Execution, the delivery team builds the stories into functionality based on highest business value

111

Definition of Done• Story specification by example completed

• Design and architecture modelled sufficiently to support story development

• Stories are developed at production level quality

• Code validated at story level by testing and business

Key Output

Stories ready for Hardening

Story Definition

Story Development

Story Validation

The specifications by examples are now enhanced with data to create executable test cases. The domain model is refined, and the software design is explored using Agile Modeling tools.

Practices

• Specification by Example

• Domain Driven Design

• UML

Overview

The team pulls the stories into development based on business value and builds them into working functionality using development best practices.

• Test Driven Development

• Pair Programming

• SOLID• Continuous

Integration

The developed stories are validated against the detailed specs by example to ensure that they are complete. The stories are then demoed with the Product Owner to collect feedback.

• N/A

Enhancing Specification by Example


All test cases for a scenario must pass to ensure that the Acceptance Scenario passes:

Test cases can include:1. Various ranges and data values (boundary & corner cases)2. Different business rules resulting in changes in data 3. Positive and negative conditions

User StoryAs Glenn Mendoza, I want to use my banking account for international transfersSo that I can see how much it costs (in fees) to send money through the service

ScenarioGivenI am ‘Glenn Mendoza’And I am logged into my banking accountAnd I have greater than ‘Amount’ in my ‘Account Type’ accountAnd I have ‘Contact’ as a contactWhenI select ‘Contact’ and submit ‘Amount’Then‘Fee’ is displayed

Given

Test Case User AmountAccount Type

Contact

1 GlennMendoza

$300 Chequing Sam Roche / USA

2 Linda Chan $800 Savings Yu Ling / China

When

Test Case Contact Amount

1 Sam Roche / USA

$300

2 Yu Ling / China

$800

Then

Test Case Fee

1 $30

2 $100

…

Plan








Criteria

UI Mockup

Supplementary

Business Rules


Plan








Criteria

UI Mockup

Supplementary

Business Rules

…

ExampleEconomic Profit Per Product

Note 1: All of these calculations are conducted for each target product selected for both the Test Group and Control Group (e.g., 2 target products requires these calculations to be executed 4 times)

Note 2: Year 1 assumptions apply for first year EP calculation and After Year 1 assumptions apply for second year onward EP calculations

Net Interest Income = [(Interest Income % – Interest Expense %)*(Balance)] * (12)Non-Interest Revenue = [(Transaction Fee Revenue + Service Plan Fee Revenue + Other Revenue)] * (12) + [(Ins Income

Amt % * Balance + Interchange Revenue % * Spend)] * 12 + One time Customer FeesLoan Loss Provision = (Loan loss provision amount * 12)Direct Expenses = [(Open cost + Maintenance Cost + Branch Acct Expense + Ebank Acct Expense + Other Acct Expense)]

* 12Net Income before Tax & Capital Charge = Net Interest Income + Non-Interest Revenue – Loan Loss Provision – Direct

ExpensesTaxes = Net Income before Tax & Capital Charge * Tax RateNet Income After Tax = Net Income before Tax & Capital Charge - Taxes Net Capital Cost = Net capital cost % * BalanceEconomic Profit for Target Product= Net Income After Tax - Net Capital Cost * Note 1: Half life is utilized for products with a negative net penetration between Post Migration and Pre Migration (i.e.,

For these products Economic Profitability is calculated Year 1 to half of the product’s term)

Specify additional business rules such as complex calculations, data manipulation / transformation, etc.

Given that customer 012 has a chequing account with overdraft protection at the bank

And the account has a balance of $100

When customer 012 withdraws $50 from their account

And in a separate transaction customer 012 withdraws $60 from their account

Then after the first transaction the account has a balance of

And the first transaction is

And after the second transaction the account has a balance of and is

And the second transaction is

Putting this all together

Before execution After execution

Execute

Given that customer 012 has a chequing account with overdraft protection at the bank

And the account has a balance of $100

When customer 012 withdraws $50 from their account

And in a separate transaction customer 012 withdraws $60 from their account

Then after the first transaction the account has a balance of $50

And the first transaction is successful

And after the second transaction the account has a balance of -$10 and is in overdraft

And the second transaction is successful

Execute

successful

Business user can click execute to run the test

rejected

$50

$50not in overdraft

The system is tested against the requirements

-If the test passes then the requirements go green

-If the test fails then the requirements go red.Requirements can

be written in the form of a “story” using the language

of the business

-Other formats can be supported

(i.e. use case, process, etc.)

• Be Precise and make the specification testable

• Focus on business functionality, not design

• Avoid UI details

• Avoid covering every possible combination (emphasis scenarios based on risk)

• Supplement with Exploratory & User Experience Testing to increase test coverage

• Include non-functional scenarios (e.g. performance, load, usability, etc.) as specification by example

Tips for Writing Specification By Examples

116

Quality is not something that is

sprinkled on top of a project, it must

be at its core. Quality must exist from

the start and grow with the project.

Approach the Quality

There are a number of techniques and tools that can (and should) be adopted to help ensure the quality of a product. They revolve around three key principles: Test Early, Test Well and Test Often.

Test Early1

Test Well2

Test Often3

Breakout Activity

118

Refined Specifications by Example

1. Refine your Specifications by Example to include concrete specific data to create executable test cases

2. Your example data should include:• Various ranges and data values (boundary & corner cases)• Different business rules resulting in changes in data • Positive and negative conditions

The Product Demo

119

What is a Product Demo?

• The Product Demo is the team’s opportunity to share the outcomes of the Sprint with stakeholders and the product owner

Who attends a Product Demo?

• The Product Demo is open to anyone who is interested in the outcomes of the sprint and is typically attended by the entire delivery team including the Product Owner

How long is a Product Demo and how often does it

happen?

• Product Demos are usually 2 hours in length and should be completed frequently, sometimes more than once within a Sprint

Preparing for the Product Demo

120

• Select the appropriate number of stories that will be demonstrated during the Product Demo session

• Organize the stories based on business value or priority

• Write a set of instructions that cover the following for each story or set of stories:

• Business context for the Story

• Open defects or other quality issues

• Steps to complete the demo

• Demonstrate the product to the Product Owner

• Collect feedback for each story

• Understand which stories are accepted vs. need to be re-worked

Hardening

During Hardening, the delivery team stabilizes the system and ensures that the built stories are defect-free and ready for Deployment

122

Stabilize Code

Update deployment &

transition plan

Definition of Done• Code tested and stabilized at the MMF level

• Users have validated business functionality for MMF

• Validated code passes non-functional requirements

• Production Infrastructure & Environments built and validated

Key Output

Stories ready for Deployment

Conduct Testing

Any stories that have outstanding scenarios or feedback from demo sessions are completed. Bugs are also eliminated at this time.

Practices

• TDD• Pair

Programming• SOLID• Continuous

Integration

Overview

The stories are now tested with all the other components of the system to ensure that it works end-to-end. The stories also goes through UAT to gain acceptance for deployment.

The deployment & transition plan is incrementally built and updated based on the team’s progress.

• Integration• VPT/NFR• UAT• Regression

• N/A

Qualification



using canvas




walkthrough


Kanban





on canvas



canvas

Validate financials


MMFs






using CRC


architecture




requirements




Refine Story Map


Criteria






(Planning Poker)



Story Acceptance


Execute



architecture

Story Elaboration





Sprint Planning





Driven Design



Story Development





Story Validation



Example)










Integration Testing


Testing



Testing

Go-Live


Deploy

Deploy Release

Transition



Production Support

Transition to I&O


requirements



Opportunity Canvas


to stories







Tank)



T-shirt size epics







Prioritized MMFs on

Enterprise Backlog


Regression Testing









Initial CRC model

UX / Wireframes


KPIs for MMF




Coded Stories


Unit Test Coverage



Improvement Backlog



for Sprint + 1



Blockers



Conduct Standups



Blockers





Deployment Plan

Help Desk FAQ





Blockers






backlog


environment





ROI

MMFs on Kanban





MMF Prioritization


Enterprise Kanban









progress


Identify measurable










Architecture Review


















manuals












support execution









Owner









Groomed stories



Support Guide

Triage `̀


criteria










Blockers

Conduct Standups

Small Work Ideas

Ideas

Small Work Ideas




Plan

Initiate

Small work intake

Report Metrics

Report Metrics

Report Metrics

Report Metrics


EA Context


Review architecture

assets


SAEABIM



SA

Key Roles for Plan

PM Scrum Master

Analyst / Tester

Dev lead


Scrum Master

Analyst / Tester

Dev

Business (PO)

PM


Analyst / Tester

Dev

PM Dev Lead




Change Management

Test Automation

Other



Trainer / Change

management




Change Management

Test Automation

Other



Elaborated Stories

Deploy

Teams deploy & release the solution using a consistent / predictable deployment process and seamless service transition / hand-over

124

Definition of Done

• Validated that MMF code works in production

• Support, operations, infrastructure have confirmed transition MMF ownership

• Validate MMF against business outcomes with metrics

• Verify that the MMF (release) is ready for deployment• Deploy MMF into Production• Complete business implementation activities and roll out change

management• Validate whether the MMF has achieved its business outcomes through

business metrics

Go-Live

• Update user guides and operations manuals• Transition to Help Desk and develop Help Desk FAQ• Transition to Maintenance and Production Support• Transition to I&O

Transition

Next Steps

Next steps

126

• Continue to refine the Lean/Agile SDLC as we learn through our experiments

• Continue to develop the Lean/Agile SDLC package that describes each component of the SDLC and contains templates and samples for all artifacts in the SDLC

• The Lean/Agile SDLC package will be stored in an easily accessible location and will be published soon

• Your team leaders and the Agile CoE are currently working on a plan to roll-out the SDLC to your projects

lean agile accelerated delivery complete training

Software