Training Script:

Lean Scrum

www.iLeanGO.com

1
 Introduction

Note

• The discussion of Scrum presented in this module has been modified

by LeanX to tailor it to the specific needs faced by Lean
Manufacturing projects

• The underlying assumption is to produce an increment in added value

through agile implementation of the project based on its theme. The
increment of added value is automatically translated into reduced
losses and is fundamental to continuous improvement

Scrum

• This is not a methodology!

• Rather, it is a framework of practices – a set of tools and processes

used to implement the Agile Manifesto

• It means working on small tasks within the framework of the so-called

Sprints and collecting feedback instead of closely following a
schedule established during project planning

• Download Scrum Guide: http://www.scrumguides.org/index.html

2
The Pillars of Scrum

TRANSPARENCY + INSPECTION + ADAPTATION

• Transparency provides the Scrum Team and everybody else in the

organization with access to all the work, as well as a common
understanding of each element of the Scrum. This leaves no room for
misunderstandings and ambiguities

• Inspection makes it possible to continuously monitor and verify the

work of the Team as to its substance and the working practices

• Adaptation should be the outcome of Inspection and should bring

about changes to navigate the Team into proper working track

The Roles in Scrum

3
Product Owner

• In charge of the project

• Defines expectations
• Manages the Project Backlog
• Sets priorities
• Reviews deliverables of the project team
• Communicates / negotiates with stakeholders
• The only person who can stop the Sprint

Scrum Master

• Educates in Scrum and Lean

• Manages communication in the team
• Removes obstacles on the way to project success

Project Team (3 to 9 individuals)

• Implements the project through Sprints

• Determines the goals of the Sprint in agreement with PO
• Chooses feasible Stories
• Breaks down Stories into tasks
• Monitors process in Daily Scrums
• Presents the results in a Scrum summary

4
Roles in a traditional organization

Example:

• Client = Plant Director

• Product Owner = Head of Production Department
• Scrum Master = Lean Coordinator
• Project Team = Cross-functional Team
• Users: Production Staff

Events in Scrum

• Sprint – an event taking place every 1 - 4 weeks in which the issues

identified during Sprint planning are addressed

• Sprint Planning – the issues which are most valuable and are classified
as “to-dos” in the given Sprint should be determined at the beginning
of each Sprint

• Daily Scrum – daily meetings of the project team to discuss the

progress of work, tasks to complete, and problems to solve

• Sprint Review – on Sprint closure, the increment of the project /product

and of the added value should be checked, along with feedback
collected from the stakeholders concerning the work accomplished;
also, further scheduled activities should be discussed

• Retrospective – a Sprint should be closed with an analysis of what was

successfully accomplished and what needs to be improved. Change
implementation plan should be prepared

5
Artefacts in Scrum

• Product Backlog – a list of to-dos (Epics or User Stories) as part of the

project / product. This is the only place where tasks are delegated in
the project team

• Sprint Backlog – a list of to-dos (stories, tasks) in a Sprint

• Added value / project / product increment – finished, tested / verified

increment of added value which is generated in the framework of the
project

Scrum – diagram

6
Scrum characteristics

• Empirical approach – effectiveness of the actions taken is verified

through experience / experiments

• Self-organizing teams – work on a project given over to professionals.

In order to fully tap into their potential, they should be given the
freedom to organize work themselves

• Retrospectives – to review whether the actions taken are effective; to

find what can be improved and changed during the next Sprint

• Increment-based – in order the loop to work, you need a measurable

increment of the added value at the check point, delivered after
each Sprint

Why to use Scrum in Lean projects?

• Flexibility – no frequent schedule updates in response to unexpected

developments

• Effectiveness – specific goals for Sprints

• Specific roles and work practices

7
Traditional Approach vs. Agile Approach

Traditional Approach

A disciplined way to implement a project based on a schedule which needs

to be amended with each new development

8
Agile Approach

• Based on a flexible approach to work on a project

• Instead of Gannt’s chart, tasks are worked on based on a Road Map

• Ability to respond to changes is more important than working

according to the established plan

• Ability to work at various levels, e.g. in a production area, production

line, or plant

• Smaller and shorter implementations as part of Sprints which generate

added value for clients (from 1 to 4 weeks, the shorter, the better), for
example:

9
Conclusions

• Agile approach is more flexible and resistant to changeable

environments

• The scope of the project is managed by compiling User Stories

(discussed later) into Sprints

• Implementations in the agile approach are extremely flexible (e.g. if

containers to implement 2S – systematics are not delivered on time,
another action can be planned within a Sprint instead of postposing
the project for 2 weeks

• In a changing environment, Sprints (or shirt-distance running races) are

more flexible and effective than long-term operations

10
 Scrum Process

Let’s start with a client

• Before the project begins, client expectations should be closely

examined

• Product Owner collects and forwards client requirements to the Scrum

Manager and the established project team

Scrum – diagram (reminder)

11
Theme of the Project

• Defines the project

• Describes what to do / accomplish over a definite period in the given

area (refer to “Road Map” section)

• Road Map defines how to work on and implement the project

• The progress of work should be monitored using a Burndown chart or a

Burnup chart for the project theme, e.g.:

• OEE Increment – Burnup chart (upward trend)

• Defects – Burndown chart (downward trend)

Product Backlog

• A wish-list composed of Stories or Epics

• All of its components are referred to as PBI – Product Backlog Items

• The moment a Story becomes the subject of a Sprint, it is broken down

into tasks, which are a part of Sprint Backlog and should be moved
from “Product Backlog” section to “To-Do” section on a Kanban Board

• NOTE: It should be created with Product Owner and Client (if possible)

12
Scope of the Project
• Refers to the Theme of the project

• The project scope can de developed during the first Sprints and may
evolve throughout the Project, however, if a project is to be
completed in 6 months, Sprints are taking place every 2 weeks on
average and include around 50 Story Points, which makes 600 Story
Points to work on during the project

• Release Burndown is a diagram to illustrate how much work is left to be

done throughout the Project

• The diagram will be updated after each Sprint

• Road Map is another form of visualization to present as-is indicators, to-

dos (mainly Epics, or Stories), and the outcomes to be delivered (to-
be)

• All modifications of the diagram should be monitored (what has been

added / removed and why)

Scope of the Project

13
Release Burndown

• Combustion diagram for the whole scope of the project - updated

after each Sprint

Epic Backlog

• Functionality Epics to be implemented, more complex than Stories

• They do not fit into 1 Sprint and are broken down into smaller User
Stories, and then into tasks

• Road Map is mainly made of Epics

14
User Stories

Example:

As... Operator working in a bottleneck

I want.... to process only semi-finished

products that comply with quality criteria

Because... I spend too much time

repairing, which affects my productivity

Tasks

• Specific tasks based on Stories to be worked on in a Sprint

15
Road Map – how to create it?

• First create Project Theme by defining:

• Work on a Road Map with the Team

• Focus on what’s important. The Road Map should not include too
many details; rather, it should feature general and key Epics and,
where necessary, Stories from the Product Backlog

• Regularly update and adjust it (every 1-3 months)

• After defining the Product Backlog and translating it into a Road Map,
begin the first Sprint with small and easy functionalities. Do not seek to
achieve a high increment in the added value. Focus more on the
Retrospective to create the best setting for communication and
cooperation in the Team

Road Map – how to create it?

16
Road Map – visualization

Decomposition

17
Decomposition – example

Sprint

Sprint is dedicated to working on tasks which originate from the

decomposition of Stories in order to generate an increment in added value
and project / product.

18
Team Velocity

Team velocity is the mean number of Story Points and Ideal Hours that the
Team is able to work during a Sprint.

Example:

• Sprint 1 = 50 Story Points

• Sprint 2 = 40 Story Points
• Sprint 3 = 45 Story Points

Velocity = (50+40+45) / 3 = 45

Velocity Diagram

19
Sprint Planning

• Product Owner and the team determine the goals for the next Sprint
based on Product Backlog

• Epics / Stories are decomposed into specific tasks to form Sprint

Backlog

• Based on Team Velocity, the elements of Sprint Backlog should not

exceed the value calculated as Velocity

Sprint Goals

20
Prioritizing the Product Backlog

Burndown Chart

• Burndown chart is referred to as the “combustion diagram” and shows

the progress of work in a Sprint

• If a Sprint is planned for 50 Points and a week (5 working days), there

should be 10 Story Points per day implemented

21
 • The diagram illustrates how many Story Points remain to be done and
the estimated time before completion

• Ideal Hours can be used instead of Story Points

Definition of Done

• The definition of Done determines work quality standards for the

project team

• Team members work in various departments and may have a different

understanding of the term “Done”. Hence, it should be clarified using
a checklist featuring points to check before a functionality is
considered to be done

Examples:

• All products delivered to a bottleneck

on an assembly line are 100% correct
owing to quality control before the
operation

• A Water Spider only moves across

designated routes and feeds the work
stations with production materials on
time

• Monitoring Board is updated on an

ongoing basis, and if the goal fails to
be accomplished – Team Leader
identifies the causes and writes them
down on the board

22
Kanban Boards – diagram

Kanban Boards – example

23
Estimation Techniques

• Planning Poker
• Ideal Hours

Planning Poker

• During Sprint planning, Stories are assessed according to Story Points

• The number of Story Points is reflected on the Planning Poker sheets

available for download

• Members of the project team estimate the labor intensity by selecting

a sheet, for example no. 8, and all show the sheets they have selected
on Scrum Master’s signal

• Estimation is repeated until a consensus is reached

24
Planning Poker

Ideal Hours
• Calculation of productive working time

• A standard 8-hour working day includes 4-6 hours of productive work

• Ideal hours in a Sprint = number of team members multiplied by

productive hours and number of days in a Sprint

Example:

• Ideal Hours = 6 (individuals) * 6 (productive hours) * 10 ( 2-week

Sprint) = 360

• The time dedicated to Daily Scrums, Sprint Planning,

Retrospectives is deducted from 360 hours

25
Daily Scrum

• Calculation of productive working time

• Daily Scrums are staged at the same location (next to a Kanban

Board) and time (e.g. 9:00 a.m.)

• Discussion of issues concerning work progress, problems, and a work

plan for the next 24 hours

• Usually led by Scrum Manager

26
Sprint Review

• At the end of each Sprint

• Led by Product Owner

• The whole team verifies the Sprint Goals implementation status

• Discussion of feedback from stakeholders invited to the Review

• Joint discussion with stakeholders on how to increase added value

while implementing the Project and how to produce increment

Retrospective

• A meeting to verify whether we have accomplished what we have

planned

• Evaluation of work from the last Sprint

• Writing down advantages and disadvantages of the last Sprint,

accomplishments, and things to improve

• A cause-and-effect analysis of events that were considered

unsuccessful (5xWhy, Ishikawa Diagram) as a starting point to
generate action

• Duration depends on the length of the Sprint – from 45 minutes to 4

hours

• Note that the Retrospective is designed to analyze work of the whole

Team, whereas Review is intended to implement goals of the Sprint to
generate an increment

27
 Summary

• Lean Scrum offers flexible implementation of projects based on events,

artifacts, and roles

• It is based on planning and execution of short-term Sprints composed

of Project Backlog Stories, which are decomposed into specific tasks.
This is an interesting alternative to the cascade approach, which relies
on the implementation of consecutive stages strictly according to a
schedule which is subject to frequent modifications in a dynamic
environment

• Lean Scrum approach is made more effective by drawing on the

conclusions from Retrospectives, thereby producing a greater chance
of success of the next Sprints

28