lean - agile training - basic stack (kanban, scrum, story mapping)
DESCRIPTION
2 day lean-agile trainingTRANSCRIPT
Accelerated Delivery
Basic Stack Training
Agile-Scrum Training Agenda – Day 1
2
Understanding Lean Exercise: Agree / Disagree?
The Case for Change
Introduction to Kanban Exercise: getKanban Simulation
Introduction to Agile
User Stories and Breaking Down Work User Stories
Story Mapping
Day 1 Wrap-up and Retrospective
Agile-Scrum Training Agenda – Day 2
3
Story Mapping Prioritizing Work
Estimating Work
Exercise: Relative Sizing
Scrum Running The Sprint
Exercise: Sprint Burndown
Closing The Sprint
Exercise: Simulated Scrum
Setting up Your First Kanban Board Exercise: Build Your First Board
Onboarding the Work
Operating Your Board
Exercise: Discuss concepts
Risk, Issues, Blocker Management Metrics
Classes of Service
Day 2 Wrap-up and Retrospective
Agile-Scrum Training Agenda – Day 3
4
Introduction to Lean Change
Executing Your Change
Understanding Your Role in this Transformation
Fundamentals of Coaching
Day 3 Wrap-up and Retrospective
Understanding Kanban
Outcomes
Pull Based Systems
Traditional Improvement Methods
Change in Kanban Systems
Kanban Core Properties
Kanban Example
Concepts To Be Covered
Introduction to Kanban
5
(a) D-B-R
(b) CONWIP
(c) D-B-R + CONWIP
(“CapWIP”)
(d) Kanban
Bottleneck
Increasing work efficiency in sub-processes does
not increase the flow on a system level
Bottlenecks restrict flow and build inventory
Bottlenecks are less predictable in knowledge
work than manufacturing systems due to high
variability of work products
Inventory increases liability in knowledge
work
Lean thinking uses “Pull” based approach to
minimize inventory
“Pull” systems use WIP to control flow in the
system
Work is pulled based on flow in the bottleneck
Different pull based systems exist to minimize
inventory based on bottleneck
Kanban provides a pull based system that
manages flow based on WIP
Importance of a pull based system
6
Old Performance
New Performance
“A” Agile approach
to change
“We are
waterfall”
“We are
agile”
Kanban approach to
change
Kanban is about introducing a set of small J-Curve effects to a less
disruptive path to agility
7
Kanban allows teams to apply “Lean” thinking to everydaywork and acts as an incremental change agent
Kanban allows the organization self discover their own agile
solution, at a pace that the organization can tolerate
Theory of
constraints
Systems
thinking
Lean
Manufacturing
System of
Profound
Knowledge
Visualize Work
Limit Work in Progress
Measure & Manage Flow
Make Process Policies Explicit
Enable Continuous Improvement
Kanban Core Properties
Taking inspiration from modern agile thinking, the followingproperties were derived to leverage Kanban in software development
8
- 9 -#leanchange
Kanban is about introducing a set of small J-Curve effects to a less disruptive path to agility
Kanban allows the organization self discover their own agile solution, at
a pace that the organization can tolerate
We don’t recommend a wholesale change to the project delivery approach – start by implementing the principles on top of existing foundation
Foster an environment where new ideas for improvement are rewarded and recognized
Continue to evolve as new ideas and enhancements are introduced to the process
Actively seek feedback and inputs from all key stakeholders
Continuous Improvement Culture
- 10 -#leanchange
Make a promise and keep it Deliver when we say we will When there are surprises we
will make sure we don't make the same mistake twice
Our performance will improve over time
Visualize Work Limit Work in Progress Measure and Manage Flow Make Process Policies Explicit Enable Continuous
Improvement
Kanban is a method built on “lean thinking” to help IT organizations
improve incrementally and deliver on their promises to the business
Kanban core properties
The Kanban Promise
Input Queue
(8)
Test
(3)
Analysis
(3)
UAT
(2)
IP Done IP Done IP Done IP Done
Development
(3)
- 11 -#leanchange
Making invisible work visible enables collaboration and coordination across the entire team
One the simplest ways to introduce agile thinking is to visualize your existing process “as is”
Individual units of business value are represented as tickets, colored to symbolize risk and other metadata
Columns represent individual states in the process, swim lanes represent different teams & types of work
Visible work promotes better team conversations, improves collaboration between specialists, and makes it obvious where bottlenecks, defects, and other impediments are occurring
- 12 -#leanchange
Limiting work in progress forces team members to collaborate as necessary
to complete work before starting more work
New Build
(12)
Input
Queue
(8)
Test
(3) Done
Analysis
(3)
UAT
(2)IP Done IP Done IP Done IP Done
Development
(3)
Testing has no work
Bottleneck indicated in development work is not flowing
Bottleneck indicated in analysis work is becoming blocked
Almost everyone recognizes that doing too many things at once is catastrophic for productivity, but very few organizations really do anything about it
Once work is visualized, explicit limits can be put in place that will define how much work is allowed in each state of a delivery process
Once limits are reached, teams must decide whether to ignore the limit, and continue to work in a suboptimal way, or to stop what they are doing and help their teammates resolve their issues
Work in process limits force your team to stop starting, and start finishing by having intelligent dialogue that lead to meaningful improvement
- 13 -#leanchange
Measuring and managing flow allows the entire organization to isolate and
remove variation
A lack of flow is made evident by intermittent bottlenecks in the delivery process surrounded by states with little to no work
A lack of flow is made evident by intermittent bottlenecks in the delivery process surrounded by states with little to no work
A lack of flow is made evident by intermittent bottlenecks in the delivery process surrounded by states with little to no workA lack of flow is made evident by
intermittent bottlenecks in the delivery process surrounded by states with little to no work
A lack of flow is made evident by intermittent bottlenecks in the delivery process surrounded by states with little to no work
- 14 -#leanchange
Kanban enables measuring flow of software delivery using Lean metrics
to get an end 2 end understanding of performance and problems
Delivery Lead Time
E2E Lead Time
Process Cycle Time
Project Project
Defect / Blocking Issue Cycle TimeBusiness Blocking Cycle Time
Quality Defects
MMFMMF
Feature
Feature
Feature
Feature
Feature
Ideas
Idea Intake
Feature / Solution Options Analysis
Project Planning & Analysis
Delivery Backlog
MMF Planning & Analysis
Delivery(R,D,B,T)
BAT Deploy Complete
Delivery Throughput
MMF ThroughputCapacity Load
Feature
Feature
FeatureFeature
A lack of flow is made evident by intermittent bottlenecks in the delivery process surrounded by states with little to no work
MMF
- 15 -#leanchange
Explicit process policies provide a shared understanding of what is
required to deliver value
• Using Kanban, quick, teams can create quick, sustained, and updatable policies that help themself-govern a set of processes under their control
• Different teams work together to set policies that govern how team interaction should function
• With an explicit understanding of the policies in place, it is possible to move to a more rational, empirical, objective discussion of issues
- 16 -#leanchange
Continuous improvement is a prerequisite to high performance
Kanban provides a rich set of information that informs agile style retrospectives… Metrics Based Review
Pre-planned Improvement Themes
4 Ls
4 Circles and soup
Speed Boat
Conducting a retrospective is not limited to just these types, teams are encouraged to think about creative ways to brainstorm and identify improvements for their system of work
Pre-planned Improvement
Themes
Group Brainstorming
Discuss Results and Choose
Improvements
Principles and Metrics Overview
Metrics Analysis
Summarize and Choose
Improvements
• Taking the time to reflect on problems and improve working conditions is the cornerstone of agile thinking
• Agile style improvement events such as retrospectives can be adopted independently of other practices, but is can be an afterthought for agile teams
- 17 -#leanchange
Kanban provide additional properties that are of particular benefit to large,
complex IT organizations
• Process uniquely tailored to each project/value stream
• Decoupled cadences (or “Iterationless” Development)
• Work scheduled by (opportunity) cost of delay
• Value optimized with classes of service
• Risk managed with capacity allocation
• Tolerance for process experimentation
• Quantitative management
• Viral spread (of Kanban) across the organization
• Small teams merged for more liquid labor pools
- 18 -#leanchange
we help our clients use Kanban to improve productivity across a
diverse range of fields
…from software project delivery work
…to maintenance, support and operational activities
…to a number of other software and non-software related fields
Input QueueTest
Done
Development QualityRequirements & Analysis
Rows represent the capability of the system for processing different types of work
Columns represent the phases that work goes through for processing
Install/Patch Configure Data Load Verify Deploy
Different processes are represented by separate swim lanes
New Build
Maintenance and LOS
Small work
19
A Kanban board enables organizations to model their processworkflow, limit work in-progress and visualize work items
Input QueueTest
Done
Development QualityRequirements
& Analysis
IP Done IP Done IP Done IP Done
New Build
Maintenance and LOS
Small work
Install/Patch Configure Data Load Verify Deploy
In-Progress and Done sub-columns add another layer of visibility on the board
IP Done IP Done IP Done IP Done
20
A Kanban board enables organizations to model their processworkflow, limit work in-progress and visualize work items
New Build
Maintenance and LOS
Small Work
Input QueueTest
Done
Development QualityRequirements
& Analysis
IP Done IP Done IP Done IP Done(8)(3) (4) (3) (2)
(12)
(5)
(6)
Install/Patch Configure Data Load Verify Deploy
IP Done IP Done IP Done IP Done
WIP limits are used to limit the work in progress for a particular phase
WIP limits are also used on swimlanes to limit the work in progress for a particular work type
4
5(2) (1) (3) (3)
21
A Kanban board enables organizations to model their processworkflow, limit work in-progress and visualize work items
Input QueueTest
Done
Development QualityRequirements
& Analysis
IP Done IP Done IP Done IP Done(8)(3) (4) (3) (2)
Define ticket types and their colours to visualize work tickets and obstructions
New Build
Maintenance and LOS
Small Work
Install/Patch Configure Data Load Verify Deploy
IP Done IP Done IP Done IP Done
(12)
(5)
(6)
(2) (1) (3) (3)
22
A Kanban board enables organizations to model their processworkflow, limit work in-progress and visualize work items
Work Ticket
B Blocker
D Defect
Input QueueTest
Done
Development QualityRequirements
& Analysis
IP Done IP Done IP Done IP Done(8)(3) (4) (3) (2)
Work Ticket
B Blocker
D Defect
New Build
Maintenance and LOS
Small Work
Install/Patch Configure Data Load Verify Deploy
IP Done IP Done IP Done IP Done
(12)
(5)
(6)
(2) (1) (3) (3)
23
A Kanban board enables organizations to model their processworkflow, limit work in-progress and visualize work items
Populate the board with current work in the system
Input QueueTest
Done
Development QualityRequirements
& Analysis
IP Done IP Done IP Done IP Done(8)(3) (4) (3) (2)
- Developers must put current work on-hold if a high severity defect is found in test.
- Service Now tickets must be reviewed every week
- Person making the change cannot be the testerBoard Policies
New Build
Maintenance and LOS
Small Work
Install/Patch Configure Data Load Verify Deploy
IP Done IP Done IP Done IP Done
(12)
(5)
(6)
(2) (1) (3) (3)
24
Explicit policies help in resolving issues and obstructions
Policies are set in place to govern the behaviour of the process
- Developers must put current work on-hold if a high severity defect is found in test.
- Service Now tickets must be reviewed every week.
- Person making the change cannot be the tester
New Build
Maintenance and LOS
Small Work
Install/Patch Configure Data Load Verify Deploy
IP Done IP Done IP Done IP Done
(12)
(5)
(6)
(2) (1) (3) (3)
Input QueueTest
Done
Development QualityRequirements
& Analysis
IP Done IP Done IP Done IP Done(8)(3) (4) (3) (2)
B
D
Work is blocked Bottleneck Team is idleWork is blockedWork is blocked
Board Policies
B
25
Explicit policies help in resolving issues and obstructions
26
Making it real, a Kanban system manifested as a physical card wall
27
Kanban provides a dedicated
space where both qualitative and
quantitative continuous
improvement can take place for
teams within an organization
getKanban Simulation
Background
• Your team is a leading product development company.
• You make products with a subscription-based revenue model.
• The more subscribers you can attract, the more money you will make.
• You bill your customers at the end of every third day. We call this the
billing cycle.
• Your goal is to maximize profit by attracting subscribers and therefore
growing your revenue stream.
29
As you roll dice during the game, you will strike work off the corresponding section of the ticket.You may choose to assign your team members to work in other specialties, but they are generally not as effective.
2 Analysts (Product / BA)
3 Developers2 Testers
Your Team
This is your team. You have two analysts, represented by two dice with large red numbers, three developers represented by blue dice, and two testers represented by green dice.
Developer assigned to
Analysis
30
If you choose to, you may divide the dice among the team, such that one player
is responsible for Analysis, another for Development, and another for Testing
Pro
ject M
an
ag
er
CFD
Tra
cker
Choose your Role & Divide Material Among the Team
31
Each Ticket Represents a unit of Product Functionality (Feature)
Marketing has estimated the market value of each Standard ticket as High, Medium, or Low. High value tickets
are expected to attract more subscribers. Marketing is usually right, but not always.
32
33
Rules: Dice, Work, Tickets
• Dice allocation must be done at the stand-up meeting. All dice must be
allocated before any are rolled.
• Tickets within each column should be prioritized during the stand-up
meeting. When work is struck off tickets, start with the ticket at the top
of the column, and work down (i.e. in priority order).
• Tickets may be pulled in any order, both from the backlog, and across
the board, and may be pulled into any position in the receiving column.
• Tickets must be pulled to satisfy WIP limits if possible.
• There are no additional rules to restrict how dice are rolled, how work is
struck off tickets, or how tickets are selected or pulled.
34
Let’s Get Started!
Debrief
Congratulations to the winning team!
The CFD
What stories does your CFD tell? Can you see the
impact of the events that transpired in the game?
The Team
Did you choose to divide the dice among the team?
If so:
• how did the players responsible for each
specialization interact with each other?
• what impact did the visibility of flow across the
value stream have on decision making?
What sorts of things were you discussing in your
stand-up meetings?
How did you make decisions, were you making
quantitative, objective assessments? If so, what data
were you using?
Who was participating in the analysis and decision
making, one person, or many people? How well did
this work?
The Work
Did you analyze the backlog to select which tickets
to pull, and if so, what factors did you take into
account?
The Blocker
How long did it take teams to resolve the blocker?
Was there high variability in resolution times
between the teams?
Carlos’ Testing Policies
What did you observe when Carlos arrived?
What caused this effect?
Why did the problem become manifest so quickly?
Are the effects of policy decisions always so
obvious? Why, or why not?
General Questions
Several different events took place during the
course of the game. Can you see the effects of
these on the charts? Can you see immediate
impact? Can you see longer lasting effects?
What are they?
What policies were made explicit? Did these
help to streamline discussion?
Was planning effective? What information was
used on a day-to-day basis to make decisions?
Did we see “swarming” happening in the game?
When did it happen? Was it effective?
36
Introduction to Agile
“Insanity: doing the same
thing over and over again
and expecting different
results.”`NOT Albert Einstein
38
A Replicated Survey of IT Software Project Failures,
Khaled El Emam & A. Günes Koru 2008
More than half of
software projects
are unsuccessful
39
Nearly half of all
software is never
used
40
We need to rethink
the way we deliver
software
41
“If I'd asked my
customers what
they wanted, they'd
have said a faster
horse. ”
Henry Ford
Customers
don’t know
what they want
at the start of a
project
42
What is Agile?
What is Agile?
• Agile is a re-think of the way we go about software development
• Conceptual framework for undertaking software engineering projects
• Several Agile Methods have been around since the 1990s and were
united in 2001 by the Agile Manifesto
Empirical Process Defined Process
4444
What is Agile not?
• It is not a single method
• It is not a set of tools
• It is not the opposite of waterfall, Prince2, PMIBOK or RUP
• It is not that easy
4545
Agile Manifesto
Individuals and
interactions
Process and
proceduresover
Working
software
Comprehensive
documentationover
Customer
collaboration
Contract
negotiationover
Responding to
changeFollowing a planover
We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:
People write software not tools
and processes. Pick the best tools
and processes that fit the
environment.
The first measure of any software
development project has to be the
functionality completed and
released.
How often have you just spoken
to someone rather than send an
email?
Plans are secondary; planning is
everything.
Rationale
While there is value in the items on the right, we value the items on the left
more.46
Sample set of core values and guiding principles to create a shared understanding amongst people in a modern IT organization
47
Guiding Principles:
• Manage the system not the
people
• Limit work in progress to capacity
• Deliver frequently, in small
batches, focus on flow
• Use transparency and data to
guide key decisions
• Collaboration is the key to
efficiency
• Build learning and feedback into
the process
• Set constraints to empower and
grow teams that own
commitments
• Foster a culture of continuous
improvement
User Stories and Breaking
Down Work
User Stories are the basic units of work delivered in a sprint
Few WordsHigh Level
Structure
Acceptance
Criteria
Sto
ry D
eta
il
Product Backlog Refinement
Key Scenarios
As a: Who?
I want: What?
So that: Why?Given: <Preconditions>
When: <Triggers>
Then: <Outcomes>
User Stories should be estimated just in time for the sprint that will deliver them
and have just enough detail to be estimated
Ready for
EstimationS
M
A
R
T
49
User Stories are all about the users, and supporting their needs / wants
Imagine you are building a new product – for
example, a mobile device for children
Who are the users that you should consider?50
Several guiding principles have been established for gauging the quality of a User Story – the INVEST principles
A story allows further refinement of scope to provide options around timing and
cost
A story is testable by itself and has clear acceptance criteria associated with it
A story has concrete business value or an inherent investment value
A story has sufficient scope and design definition to enable coarse estimation
A story is small enough to be completed within a sprint
A story is structured to minimize dependency on other work tickets
Negotiable
Testable
Valuable
Estimate
Small
Independent
The 3 C’s:
• A Card represents the physical capture of the user story
• A Conversation represents a “promise for a conversation” between the team and other stakeholders
• A Confirmation represents the acceptance criteria that provide clear conditions of completion
51
Acceptance Criteria provide a set of conditions that a User Story must meet to be considered done
Avoid ambiguous language
Avoid subjective/judgmental language (e.g., better, good, allowable)
Avoid generalizations (e.g., all the time, never, everyone, always)
Keep independent of implementation/technology
Keep relatively high level (not every detail needs to be in writing)
Use the following guide when writing acceptance criteria:
Include multiple perspectives when writing (e.g., business, technology)
Make acceptance criteria SMART
SPECIFIC
MEASURABLE
ACHIEVABLE
RELEVANT
TIME-BOUND
Acceptance criteria bound the story, letting developers know when to stop
developing, and testers know when to stop testing
52
User Stories can be further elaborated into key business / user scenarios that the solution must support
Given When Then
User is new
AND Self serve registration
page is loaded into the
browser
The registration page is
correctly populated with
mandatory fields
AND the registrant clicks on
"register"
New self serve account is created
AND new account is provisioned within mobile payment
system
AND User ID is associated with mobile payment system and
User's Mobile Carrier
AND User is assigned a new User ID
AND User ID is unique to the User's Mobile Carrier
AND User is set eligible for mobile payment system register &
get promotion
AND User receives a registration e-mail containing...
User is existing
AND Self serve registration
page is loaded into the
browser
The registration page is
correctly populated with
mandatory fields
AND the registrant clicks on
"register"
User is directed to an error page with the message "You
already have a Self Serve Account…"
AND User data is purged from the registration queue
User is new
AND Self serve registration
page is loaded into the
browser
The registration page is
incorrectly populated with
mandatory fields
AND the registrant clicks on
"register"
The registration page is reloaded with missing or incorrect
information flagged for User update along with a message…
As a: new Mobile Payment System Wallet
user
I want: to register for a new Self Serve
Account
So that: I can make use of the service
Acceptance Criteria:
• Existing users cannot re-register and will
receive an error message on attempt
• All mandatory fields must be entered to
successfully register
• On successful registration, a new account is
assigned and registration email is sent
53
Key Takeaways?
Writing stories is part art, part science
It takes practice to get good at writing
stories
It takes even more practice to get stories
right-sized
Technical constraints need to be balanced
against the technical solution
Writing User Stories is one of the core competencies of a Scrum Team; but
remember:
There are principles to gauge
story quality but there are few
rules to follow when writing
stories
Expect the first stories you write to
be poor and for quality to
improve with practice
Scrum Teams always struggle
getting stories that are small
enough for a sprint
It is important to probe the
feasibility of a story without
predetermining the solution
54
55
User Stories are also hierarchical
“Activities”
User actions that are meaningful within the context of
a business goal
e.g. get dressed
“User Story”
Meaningful unit of work that can be
completed by a team within a sprint, typically
one distinct functione.g. wear socks
“Epics ”
Business or Architecture goals to be realized by the
systeme.g. Get ready for work
“Themes”
Over arching business capability or long lived business
process
e.g. Go to work
“Tasks”
Reusable procedure or sub-routine which
doesn't belong on the map
e.g. Lift right leg
56
Epics come in two types: Business and Architecture
What are Business Epics?
• Represent a set of high level requirements that are typically end-to-end customer
focused outcomes
• Need to be refined into smaller discrete units of business value (User Stories)
that can be analyzed, estimated, developed and tested
• Often represent business capabilities or end-to-end business processes to
describe the high level scope and major objectives for a project
Describe a business outcome/benefit
Capture the major functionality needed
to achieve the outcome
Focused on a set of customer/user
segments
Can be decomposed into a set of stories
As a… Credit Card Holder
I want to… have a 24/7, multi-
channel, self-service portal to
my account
So that… I can view and
manage my account
57
Epics come in two types: Business and Architecture
What are Architecture Epics?
• Represent an end-to-end vertical slice of the technical solution required to realize
one or more Business Epics
• Need to be refined into smaller discrete units of business value (User Stories)
that can be analyzed, estimated, developed and tested
• Typically considered architecturally significant to help drive out key technology
decisions and identify cross cutting concerns with the systems/solutions involved
Aligned with one or more Business Epics
Can be further elaborated into a set of
solution options
Identify an architecturally significant
scenario
“Access account via multiple
channels”
• Person accesses account
online view webpage
• Person accesses account
via mobile device
• Person phones in to
access account
Story Mapping allows teams to systematically decompose a project into smaller units of business value using a structured approach
What is Story Mapping?
• A lightweight and collaborative approach to describing a product
• An arrangement of stories in a two dimensional map resulting in a sequential
narrative from left to right and a prioritization from top to bottom
• A highly visible representation of end-to-end product scope
• A site for conversation that is accessible and useful for setting context
• A practice that supports iterative delivery and product decomposition into
MMFs
58
The anatomy of a Story Map is composed of four layers: personas, epics, activities and stories
Manage Orders Manage FulfillmentEpicManage
Provisioning
Manage
Activation
and Billing
Activity
Story
Enter Order
Enter Order
Info
Submit
Order
Process Order
Update
Order Info
Save Order
Info
Add
Accessory
Add
Optional
Mobile
Features
Receive
Order
Notify
Customer
Submit
Fulfillment
Order
Process
Fulfillment Order
Receive
Fulfillment
Order
Submit to
Fulfillment
Vendor
Update
Order Info
Save
Fulfillment
Order
Transform
to Vendor
Fulfillment
Notify
Customer
Submit
Fulfillment
to Vendor
Receive
Shipping
Notificatio
n
Update
Order Info
Track Shipping
Progress
Submit
Order with
Accessory
Submit
Order with
Features
Submit
Fulfillment
to Network
Managmt
…
.
.
.
Submit
Provision
Request
Process
Shipping
Exceptions
Resend
Fulfillment
to Vendor
…
.
.
.
Time
Process
Order
Exceptions
Process
Fulfillment
Order
Exception
CustomerPersona Sales Rep Sales RepFulfillment
Vendor
Fulfillment
Clerk
View Order
Op
tio
nal
Sequential
Network
Operator
Billing
Clerk1
User personas are laid out horizontally at the top of the map. Think of
these as major categories of users that gain value from using the system.
Business/User epics are laid out next. These are major objectives that that
the system must support, with tangible business outcomes and real
business value.
Epics are then broken up into explicit user activities. User activities are
tangible, sequential events that describe what the user needs to do in
order to get value.
Finally, activities are broken up into explicit stories. These stories are laid
out directly underneath the user activity that the story realizes.
2
3
4
1
2
3
4
59
The layout of activities provides a walkthrough narrative of the Story Map
Once the order is submitted the
system processes the order by
receiving the order and
submitting a fulfillment order.
Optionally:
During receiving an order
an exception may occur
and the system will process
the order exception
After submitting the
fulfillment order the
system may notify the
customer
Manage Orders
Enter Order
Enter Order
Info
Submit
Order
Process Order
Update
Order Info
Save Order
Info
Add
Accessory
Add
Optional
Mobile
Features
Receive
Order
Notify
Customer
Submit
Fulfillment
Order
Submit
Order with
Accessory
Submit
Order with
Features
Process
Order
Exceptions
Customer Sales Rep
View Order
Customers and sales
representatives enter orders
by entering order info and
submitting the order.
Optionally:
During order entry time
the order can be viewed,
saved, updated or
modified with accessories
and optional mobile
features
Submitted orders may
have accessories or
optional mobile features
A Story Map can be read as a narrative by following the stories horizontally with optional stories that
can be realized for the activity by following the stories vertically
How to Read a Story Map
60
Stories are visually prioritized by shuffling them vertically, which forms a prioritized queue organized by activity
Once the overall narrative
of the system is understood
the Story Map can be used
to assist in prioritizing
stories.
Each set of stories for a
particular user activity are
reshuffled and stacked
vertically according to
priority.
Stories that are required
to create the first MMF
are placed at the top of
the stack, stories that
may be delivered later
(and sometimes never)
are placed lower down.
Manage Orders Manage Fulfillment
Enter Order
Enter Order
Info
Submit
Order
Process Order
Update
Order Info
Save Order
Info
Add
Accessory
Add
Optional
Mobile
Features
Receive
Order
Notify
Customer
Submit
Fulfillment
Order
Process
Fulfillment Order
Receive
Fulfillment
Order
Submit to
Fulfillment
Vendor
Update
Order Info
Save
Fulfillment
Order
Transform
to Vendor
Fulfillment
Notify
Customer
Submit
Fulfillment
to Vendor
Receive
Shipping
Notificatio
n
Update
Order Info
Track Shipping
Progress
Submit
Order with
Accessory
Submit
Order with
Features
Submit
Fulfillment
to Network
Managmt
…
.
.
.
Submit
Provision
Request
Process
Shipping
Exceptions
Resend
Fulfillment
to Vendor
Process
Order
Exceptions
Process
Fulfillment
Order
Exception
View Order
…
ShuffleShuffle
Shuffle
Pri
ori
ty
Time
61
Prioritizing User Stories
Prioritizing user stories is the primary responsibility of the Product Owner. Others
can provide guidance and support but the decision rests with the Product Owner.
The following factors should be considered when prioritizing user stories:
Factors:
• The business value of having the story
• The cost of developing the story
• The amount of knowledge and understanding of the system and future
requirements that will be gained from implementing the story
• Dependencies
• The amount of risk removed by implementing the story
62
Breakout Activity: Story Mapping
63
Objective: To learn how to build a Story Map
Activity: You are Grainger Application Co., building mobile application solutions
to assist professionals excel in their trade. Your latest project is to deliver the
HandyMan App:
For people on the road
who need to find a hardware store
the HandyMan App
is a mobile application
that assists tradesmen and the DIY handyman with locating nearby hardware
stores
Unlike other handyman applications
our product will enable store search by product
To keep in mind:
• Unknowns and assumptions
• Prioritization of epics/stories
Prioritizing Work
64
A Story Map can be leveraged to organize the project into releases or MMFs by horizontally partitioning the stories
Once overall prioritization of stories necessary
to support each user activity is understood, the
entire Story Map can be divided into planned
releases/MMFs. Horizontal lanes can be used to
divide different MMFs from each other. The
Story Map can then be used to tell a narrative
for a particular MMF. This is done by traversing
the map from left to right and only looking at
the stories within a particular lane.
Manage Orders Manage Fulfillment
Enter Order
Enter Order
Info
Submit
Order
Process Order
Update
Order Info
View Order
Add
Optional
Mobile
Features
Add
Accessory
Receive
Order
Notify
Customer
Submit
Fulfillment
Order
Process
Fulfillment Order
Receive
Fulfillment
Order
Submit to
Fulfillment
Vendor
Update
Order Info
Save
Fulfillment
Order
Transform
to Vendor
Fulfillment
Notify
Customer
Submit
Fulfillment
to Vendor
Receive
Shipping
Notificatio
n
Update
Order Info
Track Shipping
Progress
Submit
Order with
Features
Submit
Order with
Accessory
Submit
Fulfillment
to Network
Managmt
…
.
.
.
Submit
Provision
Request
Process
Shipping
Exceptions
Resend
Fulfillment
to Vendor
Process
Order
Exceptions
Process
Fulfillment
Order
Exception
Save Order
Info
…
MMF 1: Basic order entry integrated to the
fulfillment vendor with manual provisioning
and exception handling
MMF 2: Order entry with management features
supporting order tracking, automated customer
notifications and robust exception handling
MMF 3: Provide optional mobile features
(Visual Voice Mail, Premium SMS, Wi-Fi to
Wireless) to customers
MMF 4: Provide accessories and full product
catalogue to customers for ordering
Time
Pri
ori
ty
65
MMFs should be defined with the goal of realizing business benefits and/or validating key risks and assumptions
Internal Employee Trial 1
100 employees
Activate inside WAN
Manual processes
No support tooling
Internal Employee Trial 2
All employees in Major City
Partial automation of provisioning
Activate over 3G network
Support through DB views
Full Customer Rollout
High and order entry UI
3 million customers
Fully automated
Robust support tooling
Business Value:
N/A
Business Risk:
Demonstrate capability to build a viable
solution
Technical Risk:
Provisioning and activation of unproven
network elements
Business Value:
Build eager adopter community to promote
product
Business Risk:
Prove base product and partner
integration before expanding into paying
customers
Technical Risk:
Scaling the solution to meet higher volumes
and supporting the users
Business Value:
Increase revenue stream through
new service
Business Risk:
N/A
Technical Risk:
N/A
Overall Business Goal
Provide Mobile Service
To Telephone and Cable
Customers
Business Value
Business Risk
Technical Risk
MMF1 MMF2 MMF3
66
Delivery
Ideas are broken into MMFs and are further decomposed into stories to be delivered independently
Idea Discovery
Story
Elaboration
Story
ElaborationDevelopment Testing E2E Int. Test Deployment
MMF
1
MMF
2
MMF
3
S1
S2 S2 S2
S1
S2
MMF
3WAIT
MMF
3
Work scatters and reforms as follows:
1. Ideas are broken into independent packages with
market value
2. At the end of planning and prioritization, individual
stories move into analysis one at a time
3. Work cannot be promoted into E2E testing until all
stories are completed
1
2
3
Set agreements that outline the following:
What is the size of each batch?
What is the taxonomy we will use for the different
sizes?
When does work have to wait for other work in the
batch to be promoted?
How does work move? Pull, push, time, batch size?
How do we manage dependencies across the board?
MMF
1
MMF
2
Duration
1 – 3 Months
Duration
1 – 10 Days
Minimum: The smallest set of functionality
Marketable: Provides significant value to the customer (e.g. ↑ Revenue, ↓ Cost, etc.)
Feature: Demonstrable behaviour of the product / solution
Overview
2-4 Weeks Iterations1-2 Weeks Iterations 2-3 Iterations
67
Agile-Scrum Training Agenda – Day 2
68
Story Mapping Prioritizing Work
Estimating Work
Exercise: Relative Sizing
Scrum Running The Sprint
Exercise: Sprint Burndown
Closing The Sprint
Exercise: Simulated Scrum
Setting up Your First Kanban Board Exercise: Build Your First Board
Onboarding the Work
Operating Your Board
Exercise: Discuss concepts
Risk, Issues, Blocker Management Metrics
Classes of Service
Day 2 Wrap-up and Retrospective
Estimating Work
Planning Poker is a collaborative estimation technique that drives discussion and consensus on the work that needs to be done
What is Planning Poker?
• Has origins in Delphi / wideband Delphi forecasting methods
• Makes use of cross-functional expert opinion
• Much faster than traditional estimation methods
• Can achieve accuracy within 5-10% given an experienced team
• Relies on relative versus explicit sizing
What is relative sizing?
• Uses ‘story points’ as a relative measure of the size / complexity of a story
• A story estimated at 8 points will take four times as much effort as one estimated at 2
1 2 3 5 8
Consider two stacks of paper; is it easier to estimate the number of sheets in
each stack or to say how much larger the second stack is compared to the first?
70
• In addition to the numerical scale in a Planning Poker deck, you will often find the following:
Planning Poker also emphasizes smaller units of work by recognizing that with size and complexity comes greater variance in the estimate
0 1 2 3 135 8 4020 100
• The Planning Poker estimation scale is based on a modified Fibonacci sequence
• The idea is that as the size of the work increases, the accuracy of the estimate degrades, since
complexity introduces more variance into the estimate
? ∞
The item has insufficient detail for it to be estimated.
The item is too big for it to be estimated.
We need a break – estimation fatigue.
When estimating, how confident are you in assigning a 23 versus a 20? A 70 versus a 100?
71
The iterative steps of Planning Poker
Select a reference story
(this story should ideally
have been completed by
the team so that all
estimates can be relative
to an established point
value)
Before Starting
The team that will be delivering the story does the estimating!
3
Cards
played:
5
13
5
5
0
Story 1: 3pts
Story 2: 8pts
Story 3: ?
Story 4: 5pts
Simultaneously reveal cards
to prevent influence
Highest and lowest
provide justification…Track result if there
is consensus
Iterate to
achieve greater
accuracy
Discuss story and
silently estimate
12
3
4
5
End the session with a
sanity check of the final
results
Upon Ending
72
To understand the notion of relative sizing and Planning Poker
Objective:
1. Apply relative sizing using Planning Poker to the following
example:
a) Doberman
b) Chihuahua
c) German Shepherd
d) Bulldog
e) Great Dane
f) Golden Retriever
g) Poodle
h) Newfoundland
i) Austrian Guildenbaur
Activity:
Breakout Activity: Relative Sizing
73
Bulldog
Great Dane
Newfoundland German Shepherd
Poodle
Austrian Guildenbaur
?
Chihuahua
Golden Retriever
Doberman
74
Exercise: Relative Sizing
Estimation Tips
Have a facilitator time-box the discussion components to prevent them
from getting too detailed and drawn out; recommended 2-5 minutes
Revisit estimates! In fact, this should happen as more information
becomes available, assumptions are invalidated, etc
Watch out for anchoring! The idea is to get uninfluenced estimates,
which only happens if participants do not come on too strong with their
opinion or reveal their estimate before the group reveal
Take frequent breaks. Although Planning Poker may sound easy, it can
be exhausting
Estimate stories ‘just in time’ for the sprint. This ensures maximum
information when estimating and prevents estimates from going stale
(use Product Backlog Refinement sessions for this)
75
Scrum
Scrum Team Roles and Responsibilities
77
Scrum Master
Product Owner
The primary business representative
that is empowered to represent the
business in making on-the-spot
decisions, negotiating scope and
timelines.
An experienced practitioner who
exhibits Agile behaviours, can shield
the team from external factors and
provide insight and advice concerning
delivery practices, architecture and
overall approach.
Everyone needed to get the project
done (i.e. deliver business value).
E.g. Business System Analyst,
Developer, Tester, Technical Lead.
Team Members
Scrum Lifecycle
Product Owner
Inputs from Business,
Customers, Managers,
Execs
Product
Backlog
Scrum Team
Iteration
Backlog
Scrum
Master
Daily Stand-up
Meeting
Iteration end date
and scope remain
fixed
Acceptance Review
Completed Stories
(Ready for E2E Int.
Test)
Iteration
Retrospective
2–4 Week
Iteration
Story Elaboration,
Development
1
2 3
4
5
6
7
Iteration
Planning
78
The life of a Sprint
Sprint
Planning
Product
Backlog
Sprint Backlog
Burndown
Charts
Working
Product
Impediment
List
Daily Stand
ups
Sprint
ReviewsRetrospectives
Product
OwnerScrum Master Team Member
Sprint Meetings
Roles
Scrum Artifacts
79
Running the Sprint
The Sprint
• Sprint durations are 2-4 weeks in length
• Short Sprint cadences have the following advantages:
• Fast feedback on completed work – a short Sprint permits teams and stakeholders
to share progress, impediments, and actual results more frequently
• Changes to the Product Backlog and team direction can be made more quickly and
align better to changing business conditions and priorities
• Two week Sprint cadence is recommended with published schedule
42 31 5 9876 10
AM
PM
Sprint
Planning
We Th Fr Mo Tu We Th Fr Mo Tu
Product
Backlog
Refinement
Product
Backlog
Refinement
Sprint
Review
Sprint
Retro
Daily Stand-up meeting
81
The Sprint Boundary
• All Scrum Team activities happen inside a Sprint
• Think of the Sprint as a period of time that is “boxed”, within which all activities occur
Two week time box
All Scrum Team activities occur inside the time-box
• Sprint lengths are the same; this permits the Product Owner and the team to use the
velocity of the team for release planning
• When a Sprint is shortened because of a holiday, continue to start and stop Sprints
on the same cadence
• Sprints for multiple teams should start and stop on the same days; this permits the
business to establish a regular and consistent cadence of delivery
82
Sprint Planning
What is Sprint
Planning?• Sprint Planning is a team-level working meeting to
plan the activities of a Sprint
Who attends Sprint
Planning?• Sprint Planning is attended by the entire Scrum
Team including the Product Owner
How long is Sprint
Planning?
• Sprint Planning is 4 hours long for a 2 week
Sprint, and scaled down depending on the Sprint
duration
• Plan for 2 hours of Sprint Planning for every week
in the Sprint
83
Sprint Planning
Sprint Planning
• The Scrum Master is accountable and responsible for ensuring this meeting takes place and facilitating
• Sprint Planning can be divided into two sessions:
• Sprint Planning – First Half
• Product Owner and Scrum Team work together to establish sprint goals
• Product Owner and Scrum Team select User Stories from Product Backlog based on priority
and sprint goals
• Product Owner provides clarification on selected User Stories
• Sprint Planning – Second Half
• Scrum Team decomposes User Stories into tasks
• Scrum Team estimates the effort to complete each task in hours
• Review Scrum Team capacity
Inputs
• Team Capacity
• Velocity (Estimated or Actual)
• Product Backlog
• Sprint Goal
• Story Map
• Idea or Product Canvas
• Definition of Done
Participants
• Scrum Master
• Product Owner
• Scrum Team
Outputs
• The Sprint Goal
• The User Stories selected for
implementation in the Sprint
• Identification of other User
Stories to be done in the
Sprint
84
Product Backlog Refinement (PBR)
What is PBR?
• PBR is a working meeting with an objective of
preparing User Stories for future Sprints
• It is sometimes referred to as Product Backlog
Grooming
Who attends PBR?
• PBR is attended by any team members required to
refine or create User Stories; typical attendees are
Business System Analysts, POs, Tech leads,
Architects, and Test leads
• The entire team attends if the intent of the PBR is to
estimate or re-estimate User Stories
How long is PBR?
• Limit PBR to 2 hours with a break
• During a Sprint, a Scrum Team can have more
than 1 PBR; the rule of thumb is to invest 5-10%
of the Sprint capacity on PBR (new Scrum Teams
usually need more than 10%)
85
Product Backlog Refinement (Contd..)
Product Backlog
Refinement
• One team member leads and facilitates PBR; it does not have to be the Scrum Master
(consider rotating to build facilitation skills across team)
• The PBR begins with an overview of the objectives, e.g. “Today we are going to refine 5
new User Stories from our Admin Sync Epic. Our goal is to clarify the User Stories and add
the acceptance criteria.”
Inputs
• User Stories
• Epics
• Product Backlog
• Story Map
• Idea or Product Canvas
• Definition of Done
Participants
• Product Owner
• Scrum Team members
• SMEs (e.g. Test Lead,
Tech Lead, BSA,
Architect)
Outputs
• Refined User Stories
• Epics decomposed into User
Stories
• Refined Story Map and
Product Canvas
• Estimated User Stories
86
Product Backlog Refinement (Contd..)
• PBR is a recommended practice to ensure that the Product Backlog is always
being refined ahead of the Scrum Teams who will pull work from it
• The PBR is planned on a fixed schedule throughout the Sprint
• When you have a new product being created for the first time, the amount
of time you will invest in PBR will be greater than if you are making
enhancements to an existing product
• For a two week Sprint, we recommend a minimum of 4 hours for PBR
• BA/BSAs and other SMEs may spend a significant amount of time outside
the PBR meeting working on developing Epics and User Stories, and use the
PBR as a review with the broader team
• Attendance may vary, but before Sprint Planning, the entire team should
have previewed the User Stories and estimated them
87
Sprint Burndown
• A Sprint Burndown is a Scrum artifact used to provide a visual indicator of progress
during the Sprint
• Progress is measured by work completed, day over day, measured in Story Points or
hours of effort
• The Sprint Burndown compares a team’s estimate to its actual progress
Tue Wed Thu Fri Mon Tue Wed Thu Fri Mon510152025303540455055606570758085
Sto
ry P
oin
ts o
r H
ou
rs o
f Eff
ort
Days in Sprint
Estimated ideal burndown
Actuals plotted day-over-
day, of work completed
At the end of day 4 we have
burned 35 Story Points of
work
88
Why we use Sprint Burndowns
The Sprint Burndown:
• Is easy to read
• Provides a fast visual indicator of progress
• Immediately calls out deviations from expected results
• Reminds the team and stakeholders of the deadline and the expectations for delivery
• Allows everyone to see “at-a-glance” the actual results being achieved
89
What can you infer from these Spring Burndowns?
A B C
D E F
90
What if you experience an anomalous Sprint Burndown?
• If there is something out of the ordinary seems to be going on, use the Lean principle
of “go and see” to find out
• Do not rely only on the graph alone to understand what is happening; go and talk with
the team to get firsthand knowledge
• Record observations about your Sprint directly on the Burndown for use in the
retrospective
Tips for Managers and Leaders:
• Review the Sprint Burndowns by walking by the Kanban Board daily
• Attend the Daily Stand-ups and listen
• After the Daily Stand-up has concluded, ask about the Burndown and other
artifacts on the Task board
91
The Daily Stand-up
What is the
Daily Stand-up?
• The Daily Stand-up is a meeting that occurs on each day
of the Sprint, except for the first and last days of the
Sprint
• It is used to synchronize Scrum Team members and their
work
Who attends the
Daily Stand-up?
• The Daily Stand-up is attended by all team members
• Others may attend the Daily Stand-up but only the team
members are permitted to speak
• Others may listen only
How long is the
Daily Stand-up?
• The Daily Stand-up is 15 minutes or less in duration
• Experienced co-located Scrum Teams can complete
their Stand-up meetings in 5-10 minutes
• Distributed teams usually need more time, but also
conclude their Daily Stand-ups in under 15 minutes
92
The Daily Stand-up
• The Daily Stand-up is held in front of the team’s Kanban Board
• Team members stand in a semi-circle facing their Kanban Board - no chairs are used
• Team members must update their tasks on the Kanban Board prior to the start of the daily Stand-
up
• Each team member explains their accomplishments since the last Daily Stand-up, their planned
activities until the next Daily Stand-up, and any blockers or impediments that are either
preventing them from completing their work, or slowing down their work
• Impediments/blockers are tagged against the Task on the Kanban Board
• Impediments/blockers are documented on the Impediment List by the Scrum Master
• Any impediments that can be removed by the team members are pulled from the Impediment List
• Detailed discussions are deferred to outside the Daily Stand-up meeting
• For remote team members, set up dial in or video access, and remote participants have their tasks
updated on the Kanban Board by a teammate
Daily Stand-ups promote self-organization, focus, individual
accountability, and teamwork
Tip: Focus on sharing accomplishments versus activities in the Daily Stand-ups; this encourages
you and your team members to focus on completion of existing work rather than on starting
new work
93
Closing the Sprint
Sprint Review
What is Sprint Review?• Sprint Review is a meeting to share the outcomes
of the Sprint with people outside the Scrum Team
Who attends a Sprint
Review?
• Sprint Review is attended by the entire Scrum
Team including the Product Owner
• The meeting is open to anyone who is interested
in the outcomes of the Sprint
• Managers and executives are frequent attendees
How long is a Sprint
Review?• Sprint Review meetings are normally between 1
and 2 hours in length
95
Sprint Review Agenda
We recommend the following Sprint Review agenda for a 60 minute Sprint Review:
Agenda Item DescriptionRecommended
Time
Introductions Introduce new team members or attendees 2m
Recap of the
Sprint GoalProvide a short verbal description of the key planned deliverables of the Sprint. 3m
Recap of the
Sprint Backlog
Summarize the key User Stories, total number of User Stories, Story Points and
effort that were committed by the team.5m
Delivery
Summary
Recap total points of work delivered compared to the estimate and open the
meeting for Q&A5m
ChallengesSummarize the top risks, impediments and issues that the Scrum Team faced
during the Sprint and the actions taken to manage these.5m
Unplanned WorkList the unplanned work that entered the Sprint, including estimate changes that
occurred on planned work5m
DemoExecute a live demo of the working software delivered by the team. Focus on the
highest value items as sometimes it is not possible to demonstrate all work.20m
Q&AThis is the opportunity to get feedback and to have a brief open discussion on
Sprint activities.15m
96
Sprint Review Facilitation
• Any team member can facilitate the Sprint Review
• Schedule the Sprint Reviews on a recurring calendar invitation at the same time every two weeks
• When holidays or other events occur, reschedule the Sprint Review as close as possible to the
recurring date
• Sprint Reviews can be facilitated by a pair of team members, or more team members if this
contributes to a more effective review
• The team can decide the best and most effective review delivery method
• The Scrum Master is accountable for ensuring that the review is scheduled and executed on time,
however, the Scrum Team as a whole is responsible for ensuring that the review content is
prepared and delivered effectively
Tip: Set up a Sprint Review rotation so that each team member has the opportunity to chair the
Sprint Review. Over time, all team members improve their presentation skills.
97
What is Sprint
Retrospective?
• The Sprint Retrospective is a closed team meeting
to identify and launch continuous improvement
activities
• A Joint Sprint Retrospective involves two or more
teams in a collaborative retrospective activity
Who attends a Sprint
Retrospective?
• The Scrum Team is the only participant
• This is the only Scrum ceremony that is closed to
individuals outside the team
• Managers and other stakeholders are excluded
How long is a Sprint
Retrospective?
• Sprint Retrospective meetings are normally 1 hour
in length
• From time to time, the duration can be adjusted
as needed. (e.g. new Scrum Teams may need
more time)
98
Sprint Retrospective
Sprint Retrospective
• Any team member can facilitate the Sprint Retrospective
• Schedule the Sprint Retrospective in a quiet location away from distractions
• The Sprint Retrospective is the Scrum Team’s opportunity to discuss openly without fear of judgment
• There are many methods for running a Sprint Retrospective; teams are encouraged to use a variety of
different methods to keep the ceremony fresh and productive
• The goal of the Sprint Retrospective is to come out of the meeting with improvement experiments
that will be tested in the upcoming Sprint. Following are some examples:
• Reviewing and selecting new Reference Stories to improve estimation accuracy
• Testing new collaboration tools to improve meeting effectiveness with remote team members
• Adjusting reserved team bandwidth limits to better reflect team member availability during the
Sprint. (e.g. not enough time was set aside for supporting incoming urgent bugs)
• Improving the effectiveness of Product Backlog Refinement
Tip: Set up a Sprint Retrospective rotation so that each team member has the opportunity to
chair the Sprint Retrospective. Over time, all team members improve their facilitation skills.
99
Sprint Retrospective
• A Retrospective is a team meeting where the team reflects on how they are
working together at the end of each sprint
• The Retrospective is a chance for the team to act like a team, hearing every
voice, integrating their perspective, and reaching consensus on how to
move forward in a better way
The objective of a retrospective is to gather data about what happened since the last
retrospective, generate insights from that data, and generate improvement initiatives
Like
Things that you have
enjoyed
Lack
Things you have
seen the team doing,
but consider that
could be done better
Learn
Things you have
learned that the
team should be
aware of
Long For
Something you
desire or hope for
from either a team
or personal/role
perspective
The 4 L Retrospective Approach
100
• Allows the team to take a step back and identify strengths and issues within the
current delivery system
• The main focus is to determine potential improvements for the identified issues
• Identify key actions (e.g. behaviour changes, process improvements, policies, etc..) to
improve future delivery
Purpose
The following should be considered when planning a retrospective:
1. Scope and cadence of the retrospective
2. Participants attending. They should represent different areas of the delivery
process
3. Information required during retrospective (data, value stream maps, metrics,
A3s..)
4. Team exercises to enable collaborative analysis and resolution (5 whys, group
analysis and presentations)
Strategies
Retrospectives enable teams to analyze delivery processesand to identify potential areas of improvement
101
Retrospectives
• Allows the team to take a step back, analyze performance and seek
improvement opportunities
Scrum Simulation Exercise: Ball Point Game
103
Objective: Get as many balls through the
system
• Organize into 2 groups
• Ball must have air-time
• No ball to your direct neighbour
• Start Point = End Point
• Iteration = 2 min
• In between = 1 min (retrospective)
• Provide an estimate before each iteration
• 2 min preparation time at start of game
• We play 5 iterations
Ball Point Debrief
104
• What happened?
• Which iteration was best?
• What were the bottlenecks? How did you
find them?
• How well did the team organize
• Did you experience a rhythm?
How does this activity relate to Scrum?
105
• Basics of scrum…
– Estimate vs actual results
– Time boxing
• Team
– Self-organizing team is the nature of an Agile team
– Cross functional nature of an Agile team
– Team focused on same goal
– Each team member could be touching tasks from a user story, just like team member touches the
tennis balls
• Velocity
– The process has a natural velocity
– Changes in process and removing impediments can increase velocity
– The work is meaningful to the team
– The team was not interrupted you have better results
• Continuous Improvement
– Not found by working harder or faster but rather by working on the process and communication
– Benefit of face to face communication, leveraging experiences of others
– Opportunity to reflect after each iteration and then do it again
– Learning from experience of previous iteration
Setting Up Your First
Kanban Board
Input Boundary
called “Next”
Output Boundary
called “RFC”
Defining Input / Output boundaries (cont’d)
107
Create an initial board
Enable visualization of the team’s current process
Limit the team’s work in progress
Create columns and swim lanes
Outcomes
Input / Output Boundaries
Setting-Up Columns / Phases
Identifying WIP Limits
Adding Sub-Columns
Concepts To Be Covered
Horizontal Swim lanes
Modeling Parallel Work
Exercise: Creating a Kanban board
Setting up your first Kanban board
108
Input Boundary: Identifies where /
who the team receives work from
Output Boundary: Identifies where
/ who the team gives the work to
once the team completes
Required to set up the boundaries
of the Kanban board
Purpose
Start Done
Business
Identifies /
Prioritizes
Features
Provide to
Production Release
Team
Input Boundary (recall VSM):
When does work come under the team’s control?
Who does the work come from?
What types of work is received?
Does the work need to be transformed before it’s
understood by the team? Who does this
transformation?
Output Boundary:
When does the team complete its work?
Who does the team handoff the work to?
Key Questions
Work comes under the
control of the team
Work dependent on
the team is completed
Defining Input / Output boundaries
109
Start Req’ts Design Code QA UAT Deploy Done
Business
Identifies /
Prioritizes
Features
Provide to
Production Release
Team
Identifies the phases that work
goes through that the team
would like to visualize
Purpose
Use the Value Stream Mapping technique
For a given work type, identify the overall stages of
work travels through and select the stages that the
team would like to visualize
Steps
Setting up the phases (columns) of the Kanban Board
110
Phases that work
goes through that
the team would like
to visualize
Visualizes the overall process.
In this case this identifies the
process under the team’s
control (Delivery) and the
process in another group’s
control (UAT)
Setting up the phases (columns) of the Kanban board (cont’d)
111
To limit the amount that can be in progress at any given time for a particular phase
Purpose
1. Determine a policy for identifying a WIP limit (e.g. 1 resource can be assigned only 1
work ticket)
Can resources share work tickets (e.g. pair programming – 1 WIP per 2 developer)?
What is the typical pace of change that can occur in the group (i.e. X1, X2, X3)
The policies associated with identifying are more important than the WIP limits
2. Identify the number of resources allocated to completing the activities in each phase
3. Are resources dedicated to that phase, span multiple phases or only part time on the
project
The “Base” WIP limit can be equal to the # of dedicated resources (if the policy states 1
resources can take on 1 WIP)
The “Base” WIP limit for part time employees can be identified based on their % allocation
to the project
Steps
If in doubt, make a best case estimate and empirically adjust. A WIP limit is not
meant to be set in stone, it is a policy that is set to provoke a conversation
Setting WIP Limits for Each Phase
112
Start Req’ts Design Code QA Quality Deploy Done
10 2 1 2 1 1 1--
Business
Identifies /
Prioritizes Features
Provide to
Production Release
Team
Team comprises of the following
1 dedicated Project Manager
2 dedicated Business Analysts / UAT
1 part-time Solution Designer
2 dedicated Developers
1 Tester
1 part-time Deployment Manager
Setting WIP Limits for Each Phase: Example
113
WIP limits for each
phase of work
Setting WIP Limits for Each Phase: Example (cont’d)
114
In Progress (IP) signifies the activity required to complete the phase is still in
progress
Done represents a queue from which the subsequent phase can pull
Work that is done still counts towards the WIP limit for the phase that it sits
inside
Input
Queue
(8)
Test
(3) Done
Development
(4)Analysis
(3)
Quality
(2)
IP Done IP Done IP Done IP Done
Phase
Sub-Phase
Notice total
WIP is still 3 for
both columns
Phase with sub-
columns
Analyst would
move the ticket
from IP to Done
upcoming
completion of
his/her work
Developer would
“pull” the work
ticket into their IP
column when their
work begins
In-Progress (IP) and Done Sub-Columns add a layer of visibilityto the board
115
New Build
(12)
Maintenance
(2)
Defect Fix
(6)
Allocation
Total = 20
Input
Queue
(8)
Test
(3)
DoneDevelopment
(4)
Req’ts
(3)
Release
(3)
As a Kanban board evolves teams may model different work ticket types with
different processes
Analysis
(3)
The workflow for a
Defect Fix does not
require a stage to
identify
requirements
One method to visualize work ticket types on the Kanbanboard is to use horizontal swim lanes
116
Standard
Development
Break Fix
Horizontal swim lanes allow teams to model different types ofwork the comes in from its external clients
117
Visualizing hierarchical requirements
• Often times there are multiple levels of requirements (e.g., business requirements
and product requirements)
• As discussed previously the team may want to model multiple levels of work coming
in including
• Minimal Marketable Features
• Features
• Work Tickets
• Generally two levels of
requirements is
sufficient to model most
projects (sometimes 3)
• This type of board is
called a two tier board
with WIP limits being
set at both levels
Project
Project
Minimum
Marketable
Features
(MMF)
Work
Ticket
118
Hierarchical requirements add a layer of visibility to the Kanban board
New Build
(12)
Maintenance
(2)
Defect Fix
(6)
Input
Queue
(8)
Test
(3) Done
Development
(4)
Analysis
(3)
UAT
(2)
Dev
Ready
(3)IP Done IP Done
Test
Ready
(3) IP Done
UAT
Ready
(3) IP Done
MMF /
Feature
(3)
Input
Queue
(4)
DoneIn Progress
(2)
The MMF trails behind its
last feature
An MMF/Feature maps to
one or more work tickets
Not all work ticket
types need to map to
MMF/Feature
Delivery
(2)
IP DoneAs these is till a work
ticket in Done the
MMF/Feature cannot
move forward
119
Hierarchical requirements add a layer of visibility to the Kanban board
Business
Requirements
Work Tickets
120
Sometimes multiple individuals / groups work on a work ticket at the same
time
Two readily available methods to visualize this
Scatter-merge patterns: Create a horizontal swim lane and split the work
ticket for the particular phase
New
Features
(12)
Input
Queue
(8)
Done
Analysis
(3)
UAT
(2)
IP Done In Progress IP Done
Persistence
Dev (3)Dev
Ready
(3)
UAT
Ready
(3)
UI Dev
(3)
Done
In Progress
Split the
work tickets
Combine
once
completed
Visualizing parallel work
121
Two readily available methods to visualize this (cont’d)
Create horizontal swim lanes for each concurrent activity and add the
activity completion to the work ticket itself
New
Features
(12)
Input
Queue
(8)
Done
Analysis
(3)
UAT
(2)
IP Done In Progress IP Done
Persistence
Dev (3)Dev
Ready
(3)
UAT
Ready
(3)
UI Dev
(3)
Done
In Progress
Middleware
Dev (3)
In Progress
Work Ticket
21
Persistence
UI
Middleware
Visualizing parallel work (cont’d)
122
This is an example of a Kanban Board for new projects
Delivery: Plan - Build
Back
log
Discovery
Current NextFuture
USUS
US
US
US
US
US
US
US
Iteration Planning Story Def
IPReady to
Estimate
Arch Def
IP Done
Testing
IP Done
Ready for
Acceptance
Ready for
DeliveryCurrent NextFuture
USUS
US
US
US
US
US
US
Iteration Planning Story Elaboration
Accept
Analys
Fxn
Analys
Ready
for
Design
US
US
US
US
US
US
US
Review
Design / Build
Task
IP
Done
Delivery: Test
Test
Accept
TestFxn Test
Ready for
Acceptance
Ready for
Integration
Test
SIT
IP Done
UAT
IP Done
USUS
USUS
USUS
USUS
Performance
IP Done
Ready for
Deploy
Deploy
Done Done US IP
USUS
USUSMMF
USUS
USUSMMF
Enterprise Release Test Go-Live Deployment
Transition
MMF MMF
KT
USUS
USUSMMF
123
Using the following concepts, create a first iteration of the Kanban board leveraging the
VS mapping exercise
Input / Output Boundaries – What are the points in the system for receiving the
work and sending the work once completed?
Phases / Columns – What are the phases that work goes through between the
input and output boundaries?
WIP Limits – What is the maximum amount of work for each of the phases /
columns?
In Progress and Done Sub-Columns – What are the columns that should have in
progress and done sub-columns?
Horizontal Swim Lanes – Model additional work ticket types on the board with
additional swim lanes
Parallel Work – Is there any parallel work that needs to be visualized?
Exercise: Set up your first Kanban board
Consider incorporating elements of Scrum when developing your Kanban Board.
124
Onboarding the Work
Kanban
Evolve the Kanban board
Work ticket design
Work ticket type
Outcomes
• Work ticket types
• Work Ticket Design
• Visualizing Ownership
• Visualizing Obstructions
• Exercise: Onboarding work
Concepts To Be Covered
Improving the Kanban board
126
• Fine-grained pieces of work that
technology understands
• Similarly sized work
• Used to understand the
application delivery group’s
capacity
• Has a type, and a profile of size,
risk, value, and duration
• Can move independently
through the application delivery
group
Change Requests
Service Requests
Production Fix
PoC
Application Features
Generic Work Types Include
• Knowledge creation work is inherently variable
• A multitude of factors can make work different, obscuring meaningful analysis
• One approach is to measure each work item according to a unique combination of “work
categorization” factors
• While resulting in accurate measurements, this approach does not scale, and doesn’t support
comparative analysis
Value Type
Cost of Delay
Work Item
Size
Market Risk
Customer
Solution
MNR
MAF
MFR
MAGFDifferentiator
Spoiler
Defend
Commodity
Emergency
Fixed DateIncremental
Investment
Java Web
GIS Massive
MediumSmall
Large
DefectCR
BusinessTechnical
Integration
Defining work according to a finite set of standardized work
types will allow management to manage & improve highly variable work
127
The design of a ticket visualizes information specific to
the work ticket
Provides a quick summary on the work that is required
Different work ticket colours represent different types
of work; Application features, Maintenance Release,
Post Production Support
Date information is recorded on the other side of a
work ticket
The information tracks specific dates as the work
moves through the various phases
This allows the team to understand when the work
moved and helps to generate various metrics e.g.
Throughput, Lead Time, Cumulative flow (to be
discussed later)
Work Ticket Design
128
The front of a work ticket
The back of a work ticket
Work Ticket Details: Front
Each work ticket contains pertinent information related the project to provide
the viewer with a better understanding of the scope of the work being
completed
MMF Release Date:
Indicates when the agreed
upon release date is
User Story Name:
A short description for the
work being done to deliver
value
User Story ID #:
User Story Ticket
Identification #
MMF#:
The agreed upon MMF
number
Size:
Estimated size of the User
Story based on story points
or relative sizing (Small,
Medium, Large)
Specialists:
The number and type of
Specialists required for the
work ticket
129
Work Ticket Details: Back
130
The back of each work ticket contains the detailed record of when the ticket
passes through the sub columns
Dates are populated as the ticket traverses through the Kanban and informs the
team’s metrics
Phases:
Indicates phases a Work
Ticket traverses through
Done:
Records the date the
ticket enters the done
column
In Progress (IP):
Records the date the
ticket is pulled in to be
worked on
A useful feature of the Kanban board is to use avatars to visually indicate the
owner / owners) of the work item in its current phase
There are a number of online free sites
that allow you to create an avatar for
yourself
An alternative means of visualizing
ownership is to place the person’s initials
beside the work ticket
Exercise: Go to
http://www.southparkstudios.com/avatar
/ and create your own Avatar
Visualizing Ownership of Work Tickets
131
Teams can visualize many types of obstructions, in general the two
obstructions occur often in practice:
• Blockers: Visualize an obstruction (internal or external to the team) that
prevent a work ticket from completing its current activities
• Defects: Visualize an error in a completed work ticket that must be
corrected before getting pulled in
New Build
(12)
Maintenance
(2)
Defect Fix
(6)
Input
Queue
(8)
Test
(3)
DoneDevelopment
(4)
Analysis
(3)
UAT
(3)
Visualizing obstructions
132
Add a “Defect” ticket as a sticky buddy to the work ticket with a defect
Assign a team member to work on fixing the defect
Follow the defect work policy to fix (generally 1 of 2 options)
1. Immediately fix the defect and continue to let the work ticket move
forward
2. Move the work ticket back to the source of the problem and fix (as an
escalated item)
Measure the lifecycle of defects as part of the metrics tracking
New
Build
(12)
Input
Queue
(8)
Test
(3)
DoneDevelopment
(4)
Analysis
(3)
UAT
(3)
Defect
Defect Tracking #
May 24 May 31
Discovered
Date
Start
Date
Finish
Date
1
Defect
Fix
Place a sticky buddy,
leave the ticket as is
and assign a team
member(s) to fix
Record the date
discovered, the start
date and the date
finished for tracking
and continuous
improvement
purposes
Once the defect is
fixed record the date
and remove the defect
ticket
2
Place a defect ticket
on the work ticket Once the defect is
fixed record the date
and remove the defect
ticket
The work ticket
continues to follow
its original workflow
Tracking defects across all stages in the system of workpromote quality throughout the process
133
Add a “Blocker” ticket as a sticky buddy to the blocked work ticket
Assign a team member (typically a manager) to unblock the ticket
Track the lifecycle of the blocker (Blocked Date, Resolved Date, etc.)
New
Build
(12)
Blocker
Block Tracking #
May 24
Blocked
Date
Resolved
Date
Input
Queue
(8)
Test
(3)
DoneDevelopment
(4)
Analysis
(3)
UAT
(3)
Card is in test and
single tester goes on
vacation
Add a Blocker to
signify the card is
blocked and to begin
looking for a strategy
to unblock
Another tester is
found to take over
remove the blocker
May 31
Add the date the
blocked was
unblocked
Blockers visualize issues preventing work from progressing
134
Visual Obstructions: Example
135
Using the discussed concepts, in your team:
• Step 1: What information should be included on a work ticket for your board
• Step 2: Select the project/ task your are currently working on
• Step 3: Identify the tasks and deliverables you are currently working on
• Step 4: Place your work tickets on the board
• Blocker Visualization: What information would need to be visualized on a
blocker and / or defect?
Exercise: Identify Work Ticket Types applicable to your projects
136
Operating Your Board
Understand how to use the board on a day-to-day basis
Outcomes
• Setting up Policies
• The Daily Stand up
• Prepping the board
• Tagging the board to indicate changes
• Exercise: Mocking the daily standup
• Exercise: Creating board policies
Concepts To Be Covered
Operating your Kanban board
138
Setting up policies for the team
• Policies are set in place to govern the behavior of a set process
• With an explicit understanding of the policies in place, it is possible to
move to a more rational, empirical, objective discussion of issues
The team has set a policy for each phase that represents a set of conditions
before a subsequent phase can pull a work ticket
Setting up policies for the team
Policies can be associated with the phases of the workflow
Only one work
ticket can be
assigned to a
tester at any given
time
Developers must
put current work
on hold if a high
severity defect is
found in Test
Specification must
be signed off
before moving
into Dev Ready
• Policies can be created by any member of the team,
• Policies affecting multiple groups should be brought up and
discussed at the daily stand-up
Sample Policies Created by a Project Team
Policies give team members the confidence to pull work,discuss issues and remove bottlenecks
141
Running the Daily Stand-up
Daily standup meeting becomes a central enabler of a Kaizen culture
In this example more than 20 people attend a standup for a large project with members from
Business, Requirements, Architecture, Development , Testing and Deployment. The meeting is usually
completed in approximately 15 minutes. Never more than 30.
Running the Daily Stand-up
Walk the board from Right to Left
Maturity of the Daily Stand-up Over Time
• Level 1 Maturity: Discuss each work ticket on the board and have the assigned team
member provide a quick update
• Level 2 Maturity: Focus the stand-up on only the defects and blocking issues
preventing work from flowing and either assign an owner or obtain an update from the
assigned owner
Spontaneous Quality Circles form after the standup to
focus on immediate process issues, blockers and defects
Kanban board gives visibility into process issues – ragged flow, transaction costs of releases or transfers through stages in process, bottlenecks
Daily standup provides forum for spontaneous association to attack process issues affecting productivity and lead time
Allows team members who represent the different areas to collaborate to resolve a pressing issues, defects or blockers (in manufacturing this is synonymous with “stopping the line”)
How are we resolving the blocker that is
preventing this work ticket from being
pulled into Analysis?
A business requirement defect was
found, who is working to resolve the
defect and when will it be completed?
Lead time is unusually
high, why?
Walk the board from Right to Left
New Build
(12)
Maintenance
(2)
Defect Fix
(6)
Input
Queue
(8)
Test
(3) Done
Development
(4)Analysis
(3)
Delivery
(2)
Dev
Ready
(3)IP Done IP Done
Test
Ready
(4) IP Done
Delivery
Ready
(3) IP Done
Why does Testing look
under utilized (i.e. under
capacity)
WIP has been
exceeded! Why?
12
The team member leading the stand-up should spend 10minutes prior marking down discussion areas for the group
145
• Marking a work ticket allows the team to ask themselves• Has this work ticket come into the queue for my domain?
• If so, can I pull this work ticket and begin working on it?
New Build
(12)
Maintenance
(2)
Defect Fix
(6)
Input
Queue
(8)
Test
(3) Done
Development
(4)Analysis
(3)
Delivery
(2)
Dev
Ready
(3)IP Done IP Done
Test
Ready
(3) IP Done
Delivery
Ready
(3) IP Done
A common indicator of a change is
to mark the work ticket with a blue
sticker
34
Work Ticket
34
In Progress Done
Analysis May 10 May 12
Dev Ready May 16
Dev May 16 May 24
Test Ready May 25
Test May 26 May 31
May 31Delivery Ready
Delivery June 1
Add the date the
day the work ticket
is moved
Marking a work ticket allows the team to quickly understand what moved to support metric tracking
146
New Build
(12)
Maintenance
(2)
Defect Fix
(6)
Input
Queue
(8)
Test
(3) Done
Development
(4)
Analysis
(3)
Delivery
(2)
Dev
Ready
(3)IP Done IP Done
Test
Ready
(4) IP Done
Delivery
Ready
(3) IP Done
9
Take the board below and in your groups prep the board for the daily
standup
3
Exercise: Mock Daily Stand-up run-through
147
New Build
(12)
Maintenance
(2)
Defect Fix
(6)
Input
Queue
(8)
Test
(3) Done
Development
(4)
Analysis
(3)
Delivery
(2)
Dev
Ready
(3)IP Done IP Done
Test
Ready
(4) IP Done
Delivery
Ready
(3) IP Done
9
Take the board below and in your groups prep the board for the daily
standup
3
Exercise: Mock Daily Stand-up run-through
148
Using the discussed concepts, in your groups add column specific and global policies to
your board:
• Acceptance criteria/ definition of done
• Notification across knowledge workers
• Handling blockers and defects
• How team members will communicate with each other changes on the board
• What is the smallest ticket size that the team wants to visualize
Exercise: Apply the discussed concepts on your Kanban board
149
Risk, Issues, Blocker
Management
150
Teams are empowered to raise any risk, issue or blocker thatimpedes the delivery of work
• A complimentary Kanban board is used
to manage risks, issues and blockers for
the scrum team
• This board visualizes and tracks flow of
impediments and improvement
opportunities as first class citizens on
the board
• Useful visual tool for escalating,
discussing and quickly resolving
problems in a team
• Focuses on collaboration on key
problems impeding flow
Project Aligned Scrum Teams
PM
BA
Dev
Test
Kanban
Daily Stand-up
Sprints
Issue BlockerRisk
PMResolution or
Escalation
151
Visualizing Impediments within a Kanban System
Project Kanban Board
Risk/Issue Escalation Kanban Board
Legend
152
DiscoveryIntake
Backlog
Delivery
Opportunity
Analysis
Approved
Team 1
Team 2
POD 1
Capability
Type:
Tech Lead:
# Dev:
# Designers:
IPCommitted
for
Discovery
MMF’s /
Themes
Ready
for
DeliveryJun JulMay Aug Sep Oct Nov Dec
POD 2
Capability
Type:
Tech Lead:
# Dev:
# Designers:
Teams can visualize many types of obstructions, in general these three
obstructions occur often in practice:
• Risks: The visualization of a project risk of a work ticket that must be addressed during a stand-up in
order to assign a mitigation approach
• Issues: The visualization of a current project problem (or a risk that has materialized) which needs to be
resolved before impeding work in progress or jeopardizing the project
• Blockers: The visualization of an obstruction (internal or external to the team) that prevents a work
ticket from completing its current activities
Visualizing obstructions
B BlockersI IssuesR Risks
153
I
A Risk/Issue/Blocker Board visualizes the state of obstructed work tickets by representing the stage
of resolution the obstruction currently resides
Risks, Issues, and Blockers
Backlog Resolution Escalate Resolved
< Day
< Week
< Month
Backlog:
Obstruction tickets
that have been
identified and are
awaiting action
Resolved:
Obstruction tickets
that have been
resolved and work
on the EKB has
continued
Resolution In
Progress
(<1 Day, <1 Week,
<Month):
Obstruction tickets
that are in progress
and are expected to
be resolved within
one (1) day
Watch:
After a ticket has
been resolved it is
placed in a watched
state to monitor that
the obstruction does
not return
Escalate:
Obstruction tickets
that have not been
resolved at the local
team level and
require escalation for
resolution purposes
Watch
BRRR
I I
R
R
R
B I R BRR
R
R
RR
R
Technical
Resourcing
Administrative
Any Risk, Issue or Blocker raised on the Kanban board is tracked through the different
stages of the resolution process
I
R
I
R
R I
R
B BlockersI IssuesR Risks
154
In the same manner a work ticket provides information on theEKB, an obstruction ticket provides key details to achieve resolution
Issue TicketRelease Date:
Indicates the release date of
the work ticket that has the
issue
MMF#:
The associated MMF the Issue
Ticket is related to
Issue:
A description of why the issue
was originated
Identified:
Indicates the date that
the obstruction has been
identified
MMF Release Date:
The release date for the MMF
associated to the issue ticket
Impact:
Level of impact associated
to the issue ticket (Low,
Medium, High)
ID #:
Issue identification
number. Prefixes can be
applied by ticket type E.g.,
R22, I8, B3 for Risks,
Issues or Blockers
Severity:
Level of severity associated to
the issue ticket (Low, Medium,
High)
Resolved:
Indicates the date the
issue was resolved
Release Date:
Identified: YYYY-MM-DD
MMF#:
MMF# Release Date:
Impact:
Severity:
Issue:
ID #:Story ID #:
Resolved: YYYY-MM-DD
Story ID:
Links the Issue Ticket to the
Story that the issue impacts
155
Sample Risk/Issue/Blocker Board
Risk / Issue / Blocker Board
156
Metrics
Measure the Kanban System
Use Quantitative Measurements to Improve the System
Outcomes
• Basic Tracking Metrics
• Cumulative Flow Diagram
• Statistical Process Control Charts
Concepts To Be Covered
• Work Time Distribution
• Variability Analysis
Metrics & Service Delivery Promise
158
Kanban supports lean metrics by measuring flow of software delivery to get an end to end understanding of performance and problems
Delivery Lead Time
E2E Lead Time
Process Cycle Time
Project Project
Defect / Blocking Issue Cycle TimeBusiness Blocking Cycle Time
Quality Defects
MMFMMF
Feature
Feature
Feature
Feature
Feature
Ideas
Idea Intake
Feature / Solution Options Analysis
Project Planning & Analysis
Delivery Backlog
MMF Planning & Analysis
Delivery(R,D,B,T)
BAT Deploy Complete
Delivery Throughput
MMF ThroughputCapacity Load
Feature
Feature
FeatureFeature
A lack of flow is made evident by intermittent bottlenecks in the
delivery process surrounded by states with little to no work
MMF
159
Metric Description Value Provided Measurement
Delivery Lead Time The time between the request for a work ticket and
the delivery of that work ticket, including time
waiting for higher priority work to complete
Provide the business with a delivery promise
for each work ticket type
Delivery Promise
Delivery
Throughput
The number of work tickets released per period of
time / release
Provide data for release planning and
replenishment meetings with the client
Release Planning
Engineering Cycle
Time
Elapsed time that a work ticket spent under
analysis/design, build, and testing
Identify variability within the engineering
activities to drive process improvement and
appropriate standardization
Process Improvement
Non-Engineering
Cycle Time
Elapsed time that a work ticket spent in non-
engineering processes which are requirements,
UAT, RFC and RTP
Identify improvement opportunities outside of
the teams span of control and can be used to
drive escalation with the client, partners and
management
Process Improvement
Process Cycle Times Elapsed time that a work ticket spent in a specific
process area (ex: analysis/design)
Provide insight into root cause analysis
activities to determine if appropriate time is
being spent for a specific activity
Process Improvement
Capacity Load The ratio of individual work tickets being worked
on by a particular team to actual team members,
typically broken up by process
Quantify WIP limits based on available capacity
and can help the team determine WIP limits
and serve as a leading indicator for cycle
times
Performance Measure
Work Ticket Target
Conformance
The percentage of work tickets that were
completed within the agreed upon delivery lead
time
Identify whether the service delivery promise
needs to be refined, missing work ticket types
or motivate a call for process improvement
Performance Measure
Defect / Blocking
Issue Cycle Time
The amount of time it takes to resolve a defect or
an non-business issue that is preventing work from
being completed
Provide insight into root cause analysis
activities to determine if long cycle times are due
to defects / blockers
Performance Measure
Process Improvement
Business Blocking
Cycle Time
The amount of time it takes to resolve a business
issue that is preventing work from being completed
Provide insight into root cause analysis
activities to determine if the business is a
bottleneck to the process
Process Improvement
Quality Defects Amount of Work Ticket forward vs. backward over a
set time period
How often can a downstream process consume
work without returning it upstream
Quality Improvement
Track the following set of Work Ticket Performance Metrics to
establish a delivery promise, release planning and continuous improvement
Cumulative Flow Diagram
0
5
10
15
20
25
31-Jan-11 14-Feb-11 28-Feb-11 14-Mar-11 28-Mar-11 11-Apr-11 25-Apr-11 9-May-11
Tota
l Sto
rie
s
Week Ending
Requirements
Design
Build Wait Time
Code
Test Promotion
QA Wait Time
QA
UAT Wait Time
UAT
RFC
RFC Wait Time
RTP Wait Time
RTP
Done
Lower WIP = > Shorter Cycle Times
Higher WIP = > Longer Cycle Times
Work in progress (WIP is a leading indicator of cycle times
Little’s Law: Throughput = WIP / Cycle Time
By monitoring and controlling the teams WIP you can predict and speed up
cycle times for current and future work items
0
5
10
15
20
25
30
35
31-Jan-11 14-Feb-11 28-Feb-11 14-Mar-11 28-Mar-11 11-Apr-11 25-Apr-11 9-May-11
Tota
l Sto
rie
s
Week Ending
Defect Discovery
Defect Fixing Started
Defect Resolved
Cumulative flow diagrams are also
used to monitor how much WIP in
defects and blocking issues is in the
system
Cumulative Flow Diagrams (CFD) help a team to monitor WIPlevels and predict future cycle time trends
161
Engineering SPC – Release 1, 2, 3, 4 and Ad-hoc Work Tickets
Delivery SPC - Release 1 Work Tickets
0.00
10.00
20.00
30.00
40.00
50.00
60.00
70.00
80.00
28-Mar-11 7-Apr-11 17-Apr-11 27-Apr-11 7-May-11 17-May-11 27-May-11
Day
s
Delivery Lead Time SPC
3 work
tickets
4 work
tickets
0.005.00
10.0015.0020.0025.0030.0035.0040.0045.0050.00
26-Feb-11 8-Mar-11 18-Mar-11 28-Mar-11 7-Apr-11 17-Apr-11 27-Apr-11 7-May-11 17-May-11
Day
s
Engineering Cycle Time SPC
3 work
tickets
Work tickets appear to be
significant outliers compared to
the overall populationAverage
2nd Std Sigma
Service Delivery Promise
Average
Above average work
ticket delivery
Exceeds Service
Delivery Promise
Statistical process control charts help in identifying outliers forthe team to conduct root cause analysis and understand variability
162
Things to look for:
Low work time (typically below 70%
work time)
Higher than normal work time
High % of
defect rework time
work that is waiting to be worked
on
work that is blocked by the
business
After some analysis…
Wait times is skewed
due to the RFP & RTP
processes which are
adding 7% to the
average
IP is exhibiting
significant outliers in
business blockers and
defects/blockers along
with higher than normal
work times
Aggregate Work Time Distribution
8%
18%
3%
71%
Total Days spent on Defects
Total Days spent Waiting
Total Days - Business Blockers
Total Days spent on Work
0
50
100
150
200
250
300
350
400
Ad-Hoc IP Release 1 Release 2 Release 3 Release 4 Release 5
Wo
rk T
ime
Dis
trib
uti
on
Work Time Distribution - Requirements to RTP - Trend Wait Time
Business Blockers
Defects/Blockers
Work Time
0
50
100
150
200
250
300
350
400
Ad-Hoc IP Release 1 Release 2 Release 3 Release 4 Release 5
Wo
rk T
ime
Dis
trib
uti
on
Work Time Distribution - Requirements to RTP - Trend Wait Time
Business Blockers
Defects/Blockers
Work Time 14 Work Tickets In Progress
37 days Requirements – Toxics Inspection
Form – 12 days due to business blocker
50 days Requirements – VAMA Part 3 – No
defects / blockers identified
30 days - Order 63782 WP4 - Coding -
Common component blocker
14 days – Order 47286 WP2 - Design -
Requirements Clarity
13 days – Order 43261 WP3 - Design -
Defect in Requirements
~40% of the wait
time is due to
RFP and RTP
Visualizing waiting vs. working vs. blocking time helps toquickly identify improvement opportunities
163
Classes of Service
Understand the different classes of service
Identify classes of service
Outcomes
Common Classes of Service
Visualizing Classes of Service
Concepts To Be Covered
Classes of Service
165
4 Common Classes of Service
High and immediate impact to business (very significant cost of delay)
Break-fix type of work that needs immediate attention. Automatically jumps queues
Requires specialist resources to immediately stop other work in progress and begin work on the
expedite class item
Release dates may be adjusted to accommodate required delivery date
Shallow but immediate impact to business (medium cost of delay)
Most work ticket types needed with some urgency should be treated as standard class items
Processed on a first in first out basis
Low impact to business.
No tangible cost of delay associated with this type of work in the near future
Will be pulled through the system in an ad-hoc fashion.
Can be displaced by all other classes of work
Medium/High impact to business (high cost of delay after delivery date)
Delivery date constrained by legal commitment with customer or supplier, or regulatory/legislative
requirement, or ministerial promise
Estimate and move from input queue close to estimated days away from due date
Selected for work over standard class. May be promoted to ‘Expedite’ if late
Expedite Class
Standard
Class
Investment/
Maintenance
Class
Fixed Date
A Class of Service enables a level of service to be applied to awork ticket type
166
Generally speaking class of service should be defined according to opportunity cost of delay function
CoS
Expedite Class
Typical Cost of Delay Functions CoS
Standard
Class
Typical Cost of Delay Functions
Fixed Class
Investment /
Maintenance
Class
Policies and the Cost of Delay function associated with a Class of Service
enables easier and automated work prioritization
167
New Build
(12)
Maintenance
(2)
Defect Fix
(6)
Input
Queue
(8)
Test
(3) Done
Development
(4)Analysis
(3)
Delivery
(2)
Dev
Ready
(3)IP Done IP Done
Test
Ready
(3) IP Done
Delivery
Ready
(3) IP Done
The Class of Service work tickets is a discussion item during the replenishment
cadence meetings
• Each Work Ticket type / CoS has
an SLA associated with it
• Limits are set on the WP Type /
CoS to ensure SLAs can be met(1) (4) (10
)
(2)
Classes of Service can be modeled on the Kanban boardusing different colored post-it notes
168
Classes of Service can be modeled on the Kanban board using different colored post-it notes
Cost of Delay Profiles Work tickets are categorized by
their cost of delay
169