This document provides an overview of Kanban principles and practices. It discusses how Kanban visualizes work, limits work in progress, and manages flow to establish continuous delivery. The document outlines an agenda for introducing Kanban, including discussing objectives, foundations, principles, practices, success factors, and metrics. It also provides examples of how to implement Kanban techniques like limiting work in progress, pulling work, balancing resources, and establishing cadences for meetings.

1. Kanban 101
David Hanson
Version 1.6
May 2019
1
看
板
https://www.linkedin.com/in/david-hanson/ dphanson63@yahoo.com

2. Agile 101
2 May 2019
看板
101
dphanson63@yahoo.com
Topic: Kanban 101
We all likely use elements of
Kanban, but Scrum gets all the
attention.
This session will review the basic
principles and practices of
Kanban, which can be applied to
any process to visualize work,
limit work in progress and create
continuous flow, resulting in
increased throughput and
greater agility.
This session will largely be based
on Anderson’s Kanban,
supplemented by Reinertsen’s
Flow and the presenter’s long
experience using Kanban.
Presenter: David Hanson
David has a long career
implementing Lean to transform
projects and organizations, with
his first exposure to Agile in
1999. David is an advocate of
Scrumban, incorporating the
best of Kanban, Scrum and XP.
In 2005, David developed a
unique hybrid Lean process,
which he later realized was
already documented in 2004 as
Kanban. Since then, David has
repeatedly used Kanban as an
initial step in the Agile journey,
transforming projects with an
initial focus on continuous flow
and continuous improvement.
2

3. Kanban 101
Agenda
 Objective
 Foundation
 Principles
 Practices
 Success
 Metrics
 Library
 Summary
 Appendix: Comparison, Application, Alternatives & Extensions
3

4. Objective
Kanban 101
 Introduce basic principles and practices of Kanban
 Review the most common implementation of Kanban
 Understand continuous flow is both Lean andAgile
 Suggest a path to success for Kanban andAgile
Kanban 202
 Highlight how Kanban can be integrated into any process
 Highlight alternative approaches consistent with Kanban
4

5. Lean
Foundation
Eliminate Waste
Build Quality In
Create Knowledge
Defer Commitment
Deliver Fast
Respect People
Optimize theWhole
5

6. Core Principles
StartWhereYouAre
PursueIncrementalChange
RespectProcess&Roles
DistributeLeadership
Start with what you do,
while agreeing to pursue
incremental change
Respect current process &
roles, while promoting
leadership at all levels
6

7. Core Practices
VisualizeWork
LimitWIP
Manage Flow
Explicit Process
ImproveEmpirically
EstablishCadence*
Regular Feedback*
Base
 Visualize work to improve
communication and create
transparency
 Limit work in progress to
increase focus and reduce
cycle time
 Manage flow instead of
schedule to establish
continuous flow
Extensions
 Explicit process with
consistent workflow and
common expectations
 Improve empirically with
collaborative and
incremental experiments
 Establish cadence for inputs
& outputs to create discipline
and predictability
 Regular feedback on product
& process to continuously
improve
*Anderson covered Establish Cadence under Manage Flow and added Regular Feedback in his
online blog
7

8. VisualizeWork
Process
Priority
Work
Block
Estimate
8
Backlog Analysis Development Acceptance
#2
User needs
something
Deploy
Workflow Process 
LowerPriorityHigher
#1
User needs
Something
#3
User wants
something
Rank: #1
Story:
As a <user>,
I need | want <function>,
so that <purpose>.
Lead: TBD
#4
User wants
something
Block
Defect
3

9. PO BA DB MT UI QA SM
Product
owner
Business
analyst
Database
developer
Mid-tier
developer
UI
developer
Quality
assurance
Scrum
master
VisualizeWork
Team Members
Respect Process & Roles:
Better w/ cross-functional
team
but can start w/ independent
analyst, developer, & QA teams
Better w/ product owner &
scrum master
but can start w/ project manager
9
Backlog Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
#5
User needs
something
MT, DB
#4
User needs
Something
UI, MT
#6
User wants
something
BA
#7
User wants
something
BA
#1
User needs
something
QA
#8
User needs
Something
PO
#2
User wants
something
QA
#3
User wants
something
UI , DB

10. LimitWIP
SetWIP limits
Track Doing vs. Done
10
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#5
User needs
something
MT, DB
#4
User needs
Something
UI, MT
#6
User wants
something
BA
#7
User wants
something
BA
#1
User needs
something
QA
#8
User needs
Something
PO
#2
User wants
something
QA
#3
User wants
something
UI , DB
doing done doing done doing done

11. ManageFlow
PullWork
Float Resources
Balance Resources
Swarm Blocks
12
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#5
User needs
something
MT, DB
#4
User needs
Something
UI, MT, DB
#6
User wants
something
UI
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
PO
#2
User wants
something
QA
#3
User wants
something
QA
doing done doing done doing done
2nd
1st
3rd

12. ManageFlow
PullWork
Float Resources
Balance Resources
Swarm Blocks
13
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#5
User needs
something
MT, DB
#4
User needs
Something
UI, MT, DB
#6
User wants
something
UI
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
PO
#2
User wants
something
QA
#3
User wants
something
QA
doing done doing done doing done
2nd
1st
3rd

13. ManageFlow
PullWork
Float Resources
Balance Resources
Swarm Blocks
14
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
UI, MT, DB
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
QA
doing done doing done doing done

14. Add QA
resource?
ManageFlow
PullWork
Float Resources
Balance Resources
Swarm Blocks
15
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
UI, MT, DB
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
QA
doing done doing done doing done

15. Team
Composition
Traditional:
PM : 2 BA : 3 Dev : QA
Agile:
SM : PO : 3 coder : 2 tester
16
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
UI, MT, DB
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
QA
doing done doing done doing done
PO DB MT UI TE QA SM
Product
owner
Database
developer
Mid-tier
developer
UI
developer
Test
engineer
Quality
assurance
Scrum
master

16. ManageFlow
PullWork
Float Resources
Balance Resources
Swarm Blocks
17
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
UI, MT, DB
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
QA
doing done doing done doing done
block
?

17. ManageFlow
Queueing
Developers need QA to pull
work from done queue to
stay belowWIP limit
Starving
Developers need BA to get
analysis to done before work
available to pull
18
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
UI, MT, DB
#7
User wants
something
BA
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
QA
doing done doing done doing done

18. Explicit Process
Define Ready
Define Done
Define Accepted
19
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
something
BA
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
QA
#7
User wants
something
UI, DB
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
PO
doing done doing done doing done
Ready:
Who, what, why
Acceptance criteria
Reviewed w/ team
Done:
Unit tests pass
Code reviewed
Refactor if req’d
Accepted:
Passes acceptance
Passes regression
Reviewed w/ users

19. Establish
Cadence
Daily,Weekly, Monthly
Plan, Demo,Retro
ReleaseCadence
Establish Cadence
Set recurring cadence for key
meetings; consider:
 Daily Standup
 Weekly Planning
 Monthly Retro
 Quarterly Roadmap
ReleaseCadence
Release on set cadence
 Deploy what’s ready and
waiting
 Dates don’t slip, but stories
may
 Creates discipline; becomes
routine; establishes rhythm
20
Anderson recommends daily standup w/ after meeting, weekly prioritization, monthly release
planning, plus triage and issues meetings

20. Grooming and
ReviewCadence
Ideal
Wheneverstorydone,team
reviewsstorywithPO&
users
Wheneverpullnewstory,
POgroomsstorywithteam
Suggestion
After Meeting
• Groom or review story after
the Daily Scrum with
required participants
• Always scheduled, honor
timebox, sometimes
cancelled, some participants
optional
Alternative
Weekly Meeting
• Schedule meetings similar to
weekly sprint
• Review whatever stories are
done
• Groom enough stories toWIP
limit
21

21. Establish
Cadence
Daily Scrum
Weekly Planning*
Monthly Release
* Consider adopting Reverse Scrum, a lightweight planning meeting, replacing sprint review and
planning, discussed in Appendix, using Walk the Board approach with weekly timeframe
22
Backlog
Analysis Development Acceptance
#10
User wants
something
BA
Deploy
#9
User wants
something
BA
#13
User wants
something
PO
#14
User wants
something
PO
2 3 2
#6
User wants
something
QA
#3
User needs
Something
QA
#4
User needs
something
QA
#7
User needs
something
UI, DB
#1
User needs
something
PO
#8
User needs
Something
UI, MT, DB
#5
User wants
something
UI
#2
User needs
something
PO
doing done doing done doing done
Ready:
Who, what, why
Acceptance criteria
Reviewed w/ team
Done:
Unit tests pass
Code reviewed
Refactor if req’d
Accepted:
Passes acceptance
Passes regression
Reviewed w/ users
Release:
Monthly
w/ Retro
 production
Ranked:
Daily
Review:
Weekly
#11
User needs
something
PO
#12
User needs
something
PO

22. Improve
Empirically
Metrics:
• LeadTime
• CycleTime
Backlog
Analysis Development Acceptance
#10
User wants
something
BA
Deploy
#9
User wants
something
BA
#13
User wants
something
PO
#14
User wants
something
PO
2 3 2
#6
User wants
something
QA
#5
User wants
Something
QA
#4
User needs
something
PO
#7
User needs
something
UI
#1
User needs
something
PO
#8
User needs
Something
UI, MT, DB
#3
User needs
something
UI, DB
#2
User needs
something
PO
doing done doing done doing done
Ready:
Who, what, why
Acceptance criteria
Reviewed w/ team
Done:
Unit tests pass
Code reviewed
Refactor if req’d
Accepted:
Passes acceptance
Passes regression
Reviewed w/ users
Cadence:
Monthly
w/ Retro
Ranked:
Daily
Review:
Weekly
#11
User needs
something
PO
#12
User needs
something
PO
CycleTime
LeadTime

23. Improve
Empirically
Collaboratively
Experimentally
Collaborate
Regular Feedback
On product from users (and
team)
On process from team (and
users)
Leverage process feedback for
continuous improvement
opportunities
Experiment
Experiment and measure
impact on lead & cycle time:
• Lower or raiseWIP limits
• Adjust resource skill mix
• Split stories smaller
• Modify workflow steps
• Adjust done definitions
• Reset cadence
Test ideas generated from
regular feedback
24Experiments implemented from product feedback might be tested against Growth and Value metrics

24. CFD
0
4
8
12
16
20
24
Start Jan Feb Mar Apr Jun Jul Aug Sep Oct Nov Dec Finish
WorkCount
Cumulative Flow Diagram
Deployed Acceptance (2) Development (4>3) Analysis (2) Backlog
Tracks LeadTime and Cycle
Time
Tracks Backlog Size,Work In
Progress, and Completed
Work
Goals:
• Even Flow
• Increasing Slope
25
Backlog > Analysis > Development > Acceptance > Deploy
WIP limit changed from 4 to 3 for Development
CycleTime
LeadTime
WIP
BacklogSize
InProduction
CycleTime

25. Recipe for
Success
1. Focus on Quality: technical focus for solid foundation
2. LimitWork in Progress: reduces cycle time for delivery
3. Deliver Frequently: builds trust with clients
4. Balance Demand vs.Throughput: leave some buffer for
contingency and improvement
5. Prioritize*: influence to deliver highest business value
6. AttackVariability: standardizing leads to predictability
Follow these steps in order to
maximize chances for success
*Prioritize Ruthlessly is my viewpoint on prioritizing; not everything can or will be accomplished
My additions: Restructure Organization; Leverage Failure
26

26. KanbanLibrary
Lean: Mary&TomPoppendieck
www.poppendieck.com
Kanban: DavidAnderson
www.djaa.com
Flow: DonaldReinertsen
Kanban &Scrum:HenrikKniberg
blog.crisp.se/author/henrikkniberg
27

27. Kanban 101
Summary
• VisualizeWork
• LimitWork in Progress
• Manage Flow
Goal: continuous flow with
improving throughput
28
Backlog
Analysis Development Acceptance
#10
User wants
something
BA
Deploy
#9
User wants
something
BA
#13
User wants
something
PO
#14
User wants
something
PO
2 3 2
#6
User wants
something
UI
#5
User wants
Something
PO
#4
User needs
something
PO
#7
User needs
something
UI, DB
#1
User needs
something
PO
#8
User needs
Something
UI, MT, DB
#3
User needs
something
QA
#2
User needs
something
PO
doing done doing done doing done
Ready:
Who, what, why
Acceptance criteria
Reviewed w/ team
Done:
Unit tests pass
Code reviewed
Refactor if req’d
Accepted:
Passes acceptance
Passes regression
Reviewed w/ users
Release:
Monthly
w/ Retro
Ranked:
Daily
Review:
Weekly
#11
User needs
something
PO
#12
User needs
something
PO
pull
pull
block
 production
CycleTime
LeadTime
David Hanson: dphanson63@yahoo.com, https://www.linkedin.com/in/david-hanson/

28. Kanban 202
Comparison & Application
Extensions & Alternatives
29

29. Kanban vs.
Scrum
Differences
 Can be applied to waterfall to
create continuous flow
 Development and QA can be
independent
 Product owner and Scrum
master not mandatory
 Works even with traditional
specifications
 No estimates, no pointing
 Work can flow week to week,
no timeboxes
 Can change priority anytime
for anything not started
Compatibilities
 Can be applied to Scrum to get
stories to ready and get stories
through acceptance & release
 Works even better with cross-
functional team and Scrum
roles
 Desirable to break work into
stories for predictable flow
 Swarming blocks and floating
resources drives collaboration
 Pulling work based on priority
empowers self-management
 Both based on Lean and Agile
principles
30

30. Kanban
Workflows
Startbyapplyingtowaterfall
FinishbyadoptingScrumban
Applied to Waterfall
Activity States Wait States
Planning > Planned >
Analyzing > Analyzed >
Designing > Designed >
Coding > Coded >
Testing > Tested >
Accepting > Accepted >
Deploying > Deployed
Combining with Scrum
Ready States Active States Done States
Not Ready > Readying > Ready >
To Do > Doing > Done >
UAT Ready > UAT > UAT Done >
Staged > Deploy > Verified
31Start where you are and continuously improve…

31. Agile
Journey
Start with Kanban
Migrate to Scrum
Refine with XP
32
XP
Feedback: Pair Programming, Planning
Games*,Test First,WholeTeam
Process: Continuous Integration,
Refactor Complexity, Small Releases
Understanding: Coding Standards,
Collective Ownership, Simple Design,
System Metaphor
Welfare: Sustainable Pace
Kanban
Principles:
Start w/WhatYou Do, Pursue
Incremental Change, Respect Process
& Roles, Distribute Leadership
Practices:
VisualizeWork, LimitWIP, Manage
Flow, Explicit Policies, Establish
Cadence, Regular Feedback, Improve
Empirically
Scrum
Roles: PO, SM,Team
Events: Sprint, Planning, Scrum,
Review, Retrospective
Artifacts: Backlog Items*, Product
Backlog, Sprint Backlog, Increment
Agreements: Ready, Done, Norms
Tracking: Burnup/down,Velocity
*User Stories most popular Backlog Item, generally credited as derived from XP Planning Games

32. Team
Composition
Respect Process & Roles
Distributed Leadership
TraditionalTeam
PM : 2 BA : 3 developers : QA
AgileTeam
PO : 3 coders : 2 testers : SM
33
PO UI MT DB TE QA SM
Product
owner
UI
developer
Mid-tier
developer
DB
developer
Test
engineer
Quality
assurance
Scrum
master
PO SA UI MT DB QA SM
Product
owner
Systems
analyst
UI
developer
Mid-tier
developer
Database
developer
Quality
assurance
Scrum
master
PM BA SA UI MT DB QA
Project
manager
Business
analyst
Systems
analyst
UI
developer
Mid-tier
developer
Database
developer
Quality
assurance

33. Distributed
Leadership
Leadership atAll
Levels
Goals
 Distribute leadership across
multiple dimensions for every
team member
 Ensure every dimension has
recognized lead and grooms
backup within team
 Every team member aims to
be generalizing specialist
with goal to add skills
Dimensions
 Technical: BA, UI, middle tier,
DB, QA or .NET, Java, SQL
 Domain: data, content, usage
 Process: source control,
continuous integration,
release & deploy, scheduler
 Management: tasks, process,
priorities
34

34. VisualizeWork
Story BA DB MT UI QA UAT Date Issue
User needs… x x x x x x Apr
User needs… x x * * _ Apr defect
User wants… x x x x x o Apr
User needs… x x x x o May
User needs… o x _ o o May block
User wants… x o o May
User needs… x Jun
User needs… o Jun
User wants… Jun
Alternative approach
Allows tracking work in multiple states
Color code to highlight WIP or rework
Example:
• QA preparing test cases
• UI, MT, DB coding in progress
• BA addressing issue
35
Doing Done Rework Wait
o x * _

35. WIP Limit
Alternative
Pros & Cons
Pro: easy to implement and
controls multi-tasking
Con: promotes less teamwork
and less swarming
36
Each person has primary task
and backup task
Focus on primary task until
done or block requiring wait
Backup task will be next task
Primary & Backup

36. ReverseScrum
Whyreverse?
InDailyScrummember identifies
story
InReverseScrumstoryidentifies
member
Weekly Planning
Weekly meeting in place of the
day’s daily Scrum
Effectively replaces sprint review
and planning
Reviews the last week and plans
the next week
Review each story from highest
to lowest priority, or backwards
through workflow
Target 45 minutes, if demo and
groom stories outside of
meeting
Target 1.5 hours, if also covers
demo and grooming
Walk the Board
Start by reviewing production
issues and release readiness
Then for each story:
• Who is leading this story?
• What was accomplished for
this story in the last week?
• What will be accomplished for
this story in the next week?
• What obstacles delayed or risk
delaying this story?
End by asking if anything else in
progress not being tracked
37

37. ManageFlow
Managing Defects
If found in production then
may be added to backlog as
new requirement
If found during acceptance
then may or may not
require analysis
May exceed WIP limit
38
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
BA
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
UI
#5
User needs
Something
MT, DB
#4
User wants
something
QA
#7
User wants
something
UI, DB,
#1
User needs
something
PO
#8
User needs
Something
BA
#3
User wants
something
QA
#2
User wants
something
PO
doing done doing done doing done
defect
defect
defect

38. ManageFlow
Expedited Swimlane
• Production support
• Managing defects
For unplanned, urgent &
critical work
Subject to ownWIP limit of 1
39
Backlog
Analysis Development Acceptance
#10
User needs
something
PO
Deploy
#9
User needs
Something
PO
#11
User wants
something
PO
#12
User wants
something
PO
2 3 2
#6
User needs
something
QA
#5
User needs
Something
MT, DB
#4
User wants
something
QA
#7
User wants
something
UI, MT
#1
User needs
something
PO
#8
User needs
Something
UI, MT, DB
#3
User wants
something
UI, DB
#2
User wants
something
PO
doing done doing done doing done
defect defect
Support
Issue
QA
pull

39. Manage Flow
Blocks
Defects
Suspended
Manage Flow
Track blocks as hard, soft or
risk of block
Track rework as BA issue,
developer defect, QA retest
Visually track suspended tasks;
start and stop very inefficient
Types of Blocks
Hard: full block preventing all
work
Soft: partial block allowing
some work
Risk: risk of block in near term
worth managing
40

40. Extensions
Establish Cadence
Regular Feedback
Establish Cadence and Regular
Feedback related
Neither explicitly called out as
core practice by Anderson
Anderson has two chapters on
Cadence for inputs and outputs
Anderson suggests Feedback
as extension in online blogs
StandardizeWork
Small Batch Size
Standardize work to reduce
variation
Work in small batches to speed
feedback
Example:
• Standardize on 2-3-5 point
stories
• Standardize on ½-1 day tasks
41

41. Standardize
Work
Tasking:
Replace tasks with
story checklists
Status:
notrequired
notstarted
inprogress
completed
Development Checklist
 Analysis
 Coding
 UnitTesting
 Refactoring
 UI
 Middle-tier
 Database
 Batch
Acceptance Checklist
 Planning
 Manual
 Automation
 Maintenance
 Integration
 Acceptance
 Regression
 Performance
42

42. Metrics
LeadTime and CycleTime
LeadTime:
Time from idea to delivery
Time from entering product
backlog to exiting deployment
queue
CycleTime:
Time actively being worked
Time from entering to exiting
development queue
ActivityTime andWaitTime
Extension leveragingValue
Stream Mapping
Track ActivityTime andWait
Time
ActivityTime: time in doing
WaitTime: time in done
MinimizeWaitTime
Optimize ActivityTime
43
Jeff Sutherland emphasizes Process Efficiency, calculated as Activity Time / Lead Time, with goal of
25%, assuming Activity Time is also Value Added Time.

43. The
Principles of
Product
Development
Flow
Major
Themes
 Economics: prioritize based
primarily on cost of delay
 Queues: process inventory,
often unmeasured, is waste
 Variability: leverage risk for
better economic outcomes
 Batch Size: reducing batch
size positively impacts above
 WIP Constraints: simple
control to learn and delay
 Flow: control flow with
cadence & synchronization
 Fast Feedback: learn and
react fast for better outcome
 Decentralized Control:
empower with alignment
44

44. Economics:
Cost of Delay
Cost of Delay example:
 DeliverableA takes 3 months and will return one time benefit of
$250K if early to market else $200K if late to market; cost of delay
$50K
 Deliverable B takes 3 months and will return recurring benefit of
$25K/month; cost of delay recurring $25K/month
Options for delivery:
 Option 1 (equally important): work concurrently, delivering both in
6 months; at end of 1 year return is $350K
 Option 2 (early return): deliverable A in 3 months, followed by
deliverable B in 6 months; at end of 1 year return is $400K
 Option 3 (cost of delay): deliverable B in 3 months, followed by
deliverable A in 6 months; at end of 1 year return is $425K
Cost of Delay impacted by all factors: queues, variability, batch size,
WIP, cadence & flow, feedback, and control
45