169
Accelerated Delivery Basic Stack Training

Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Embed Size (px)

DESCRIPTION

2 day lean-agile training

Citation preview

Page 1: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Accelerated Delivery

Basic Stack Training

Page 2: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 3: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 4: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 5: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 6: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

(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

Page 7: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 8: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 9: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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

Page 10: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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)

Page 11: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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

Page 12: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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

Page 13: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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

Page 14: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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

Page 15: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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

Page 16: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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

Page 17: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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

Page 18: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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

Page 19: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 20: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 21: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 22: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 23: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 24: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 25: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

- 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

Page 26: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

26

Making it real, a Kanban system manifested as a physical card wall

Page 27: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

27

Kanban provides a dedicated

space where both qualitative and

quantitative continuous

improvement can take place for

teams within an organization

Page 28: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

getKanban Simulation

Page 29: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 30: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 31: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 32: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 33: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

33

Page 34: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 35: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Let’s Get Started!

Page 36: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 37: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Introduction to Agile

Page 38: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

“Insanity: doing the same

thing over and over again

and expecting different

results.”`NOT Albert Einstein

38

Page 39: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 40: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Nearly half of all

software is never

used

40

Page 41: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

We need to rethink

the way we deliver

software

41

Page 42: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

“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

Page 43: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

What is Agile?

Page 44: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 45: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 46: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 47: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 48: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

User Stories and Breaking

Down Work

Page 49: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 50: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 51: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 52: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 53: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 54: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 55: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 56: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 57: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 58: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 59: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 60: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 61: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 62: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 63: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 64: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Prioritizing Work

64

Page 65: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 66: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 67: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 68: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 69: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Estimating Work

Page 70: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 71: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

• 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

Page 72: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 73: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 74: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Bulldog

Great Dane

Newfoundland German Shepherd

Poodle

Austrian Guildenbaur

?

Chihuahua

Golden Retriever

Doberman

74

Exercise: Relative Sizing

Page 75: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 76: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Scrum

Page 77: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 78: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 79: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 80: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Running the Sprint

Page 81: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 82: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 83: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 84: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 85: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 86: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 87: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 88: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 89: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 90: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

What can you infer from these Spring Burndowns?

A B C

D E F

90

Page 91: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 92: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 93: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 94: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Closing the Sprint

Page 95: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 96: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 97: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 98: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 99: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 100: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 101: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

• 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

Page 102: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Retrospectives

• Allows the team to take a step back, analyze performance and seek

improvement opportunities

Page 103: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 104: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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?

Page 105: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 106: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Setting Up Your First

Kanban Board

Page 107: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Input Boundary

called “Next”

Output Boundary

called “RFC”

Defining Input / Output boundaries (cont’d)

107

Page 108: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 109: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 110: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 111: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 112: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 113: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 114: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

WIP limits for each

phase of work

Setting WIP Limits for Each Phase: Example (cont’d)

114

Page 115: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 116: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 117: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Standard

Development

Break Fix

Horizontal swim lanes allow teams to model different types ofwork the comes in from its external clients

117

Page 118: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 119: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 120: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Hierarchical requirements add a layer of visibility to the Kanban board

Business

Requirements

Work Tickets

120

Page 121: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 122: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 123: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 124: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 125: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Onboarding the Work

Kanban

Page 126: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 127: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

• 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

Page 128: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 129: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 130: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 131: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 132: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 133: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 134: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 135: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Visual Obstructions: Example

135

Page 136: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 137: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Operating Your Board

Page 138: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 139: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 140: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 141: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

• 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

Page 142: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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.

Page 143: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 144: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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”)

Page 145: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 146: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

• 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

Page 147: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 148: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 149: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 150: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Risk, Issues, Blocker

Management

150

Page 151: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 152: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Visualizing Impediments within a Kanban System

Project Kanban Board

Risk/Issue Escalation Kanban Board

Legend

152

Page 153: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 154: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 155: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 156: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Sample Risk/Issue/Blocker Board

Risk / Issue / Blocker Board

156

Page 157: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Metrics

Page 158: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 159: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 160: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 161: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 162: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 163: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 164: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

Classes of Service

Page 165: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 166: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 167: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 168: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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

Page 169: Lean - Agile Training - Basic Stack (Kanban, Scrum, Story Mapping)

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