Teamwork created

in Scrum
Agile Training 4 grants everyone’s
Development Sprint (Scrum)
dream

MTI Confidential
Revision History

Version Date Amendment Editor

1.0.0 Oct 30, 2020 Original Issue Amamiya/Kurume
1.1.0 Jan 6, 2021 Conform “The 2020 Scrum Guide” Amamiya/Kurume
1.2.0 Feb 24, 2021 Add Acceptance Criteria description to Product Backlog (P.65-66) Amamiya/Kurume
1.2.1 Mar 29, 2021 Add types of PBI to Product Backlog, and modify the expression of each PBI in the sample of Amamiya
Product Backlog (P.63-64)
1.3.0 Apr 26, 2021 P.16 Add the title “Scrum’s Purpose”, and replace with new picture Amamiya
P.17 Add the slide “Scrum Overview”
P.21 Change the note in the slide “Self-Managing”
P.25-26 Review and change the role and responsibility of “Scrum Master”
P.60 Add the slide “Conceptual diagram of commitment perspective”
P.76 Add the slide “Examples of DoR/DoD”
1.4.0 May 12, 2021 P.19 Add and change the description of “Scrum Team” Amamiya
P.19-29 Change the order of slides in “Role” Chapter
P.76 Modify the appearance of “Examples of DoR/DoD”
1.5.0 Feb 14, 2022 P.12 Replace with new picture in the slide “Scrum’s Rules” Amamiya
P.21 Add the description in the slide “Self-Managing”
P.27 Add the slide “Responsibility of SM”
1.6.0 Feb 22, 2022 Adjust the difficulty level for each slide Amamiya

MTI Confidential 2
Revision History

Version Date Amendment Editor

1.7.0 Feb 26, 2022 P.20 Add a reference of Feature Team in the slide “Cross-Functional” Amamiya
P.25 Review the description in the slide “Scrum Master”
P.27 Add easy-to-understand expression for “Accountability for establishing the Scrum”
P.29 Review the contents in the slide “Developers Principles”
P.38 Mention the size of 1 PBI in the slide “Sprint Planning Part 1”
P.45 Review the description at third step “Generate Insights” in the slide “Steps of Sprint
Retrospective”
P.46 Add new caution to “Caution” in the slide “Sprint Retrospective Methods”
P.63 Add Exploration, Architectural task and Infrastructural task to “Product Backlog includes”
1.7.1 Mar 17, 2022 P.73 Modify some expressions in the slide “Misunderstanding of velocity” Amamiya
1.8.0 Apr 21, 2022 P.68 Add the slide “Progress Analysis in the Burndown Chart” Amamiya
P.70 Add the slide “How to create good tasks (SMART)”
1.8.1 Jun 5, 2022 P.20 Replace the figure in the slide “Cross-Functional” Amamiya
1.8.2 Dec 2, 2022 P.63 Change Japanese translation (No impact to this document) Amamiya
1.8.3 Dec 2, 2022 P.32 Mention 4 formal events in the slide “Scrum Event is” Amamiya
1.8.4 Mar 5, 2023 P.28 Delete a sentence related to responsibility of Product Increment Amamiya

MTI Confidential 3
INTRODUCTION

◼ Purpose
This document is a training material for Agile learners to equip correct
Agile (Scrum) knowledge.

◼ Target participants Recommendation

Level

Scrum Master
Low High
•
• Product Owner Low High

• Developers Low High

• Management & other stakeholder Low High

MTI Confidential 4
About this document

◼ Managed by
Technology Organization
*Not allowed to edit this document without management permission.

◼ Difficulty Level
The difficulty level is displayed on each slide.
Beginner ・・・ Level: Low. For people who learn for the first time.

Intermediate ・・・ Level: Middle. For people who have more than 3-month experience and challenge a next step.

Advanced ・・・ Level: High. For people who need to know more about applied or difficult content.

MTI Confidential 5
About this document

◼ Positioning area of this document

This document is focused on the most practical Scrum of
Development Sprint (Sprint 1-N) in Agile Training courses.
Agile
Setup Preparation Sprint Development Sprint Contents
(Sprint 0) (Sprint 1-N)
Scrum
WF
->Agile
Inception Organizing Sys tem Analysis Engineering
•
Deck Requirements a nd Design
Team Building Scrum
Practices • Roles
Agile
Business Requirement Building
- XP Release • Scrum Events
Analysis Modeling Environment
Manifesto • Artifacts
Compliance Spike Kanban
• Scaling Methods
Methodol
ogies
Quality Assurance QA2AQ Lean QMS Agile Testing

Communication Agile Communication

Communication
Interculture / Diversity
Management
Trends
Project Agile Project Agile Estimating
Scaling/Enterprise Agile
Management Management and Planning

MTI Confidential 6
About this document

◼ References
“The Scrum Guide™ November 2017”
“The Scrum Guide™ November 2020”
“The Agile Samurai”
”Agile Retrospectives: Making Good Teams Great”
https://www.scruminc.com/
https://less.works/
https://www.ryuzee.com/

MTI Confidential 7
 Scrum
Understand what is Scrum!

MTI Confidential 8
 Beginner

Scrum Intermediate
Advanced

◼ Definition
Scrum is a lightweight framework that helps people, teams
and organizations generate value through adaptive solutions
for complex problems.
Scrum is not a process, technique, or definitive method. Rather, it is a framework
within which you can employ various processes and techniques.

The Scrum framework consists of Scrum Teams and their associated roles, events,
artifacts, and rules. Each component within the framework serves a specific purpose
and is essential to Scrum’s success and usage.

MTI Confidential 9
 Beginner

Scrum Intermediate
Advanced

◼ History of Scrum
Hirotaka Takeuchi and Ikujiro Nonaka introduced the term Scrum in the
context of product development in their 1986 Harvard Business Review
article, ‘The New New Product Development Game’.
They introduced this flexible and highly flexible development method
originated in Japan as “Scrum” by analogy with the rugby scrum.

MTI Confidential 10
 Beginner

Scrum Intermediate
Advanced

◼ Features
- Lightweight
- Simple to understand
- Difficult to master

◼ Uses of Scrum
• Used in new system development and existing system maintenance.
• Applicable to various field from software to hardware, automobile
development, academic, government, marketing, and organization
management.

MTI Confidential 11
 Beginner

Scrum Intermediate
Advanced

◼ Scrum’s Rules

https://www.scruminc.com/the-3-5-3-of-scrum/

MTI Confidential 12
 Beginner

Scrum Intermediate
Advanced

◼ Scrum Theory
• Scrum is founded on empiricism and lean thinking. Empiricism
asserts that knowledge comes from experience and making decisions
based on what is observed. Lean thinking reduces waste and focuses
on the essentials.

• Scrum employs an iterative, incremental approach to optimize

predictability and control risk.

• Three pillars uphold every implementation of empirical process

control: transparency, inspection, and adaptation.

MTI Confidential 13
 Beginner

Scrum Intermediate
Advanced

◼ 3 Pillars of Scrum

• Be visible to those responsible for the outcome. - Set a clear goal

Transparency • Have a common understanding with people - Visualize progress and results
involved. - Share a definition of “Done”

• Inspect Scrum artifacts and progress frequently, - Inspect frequently

and detect undesirable variances.
Inspection • Their inspection should not be so frequent that
- Detect variances
- Fail with safety
inspection gets in the way of the work.

• If the process is flawed, it must be adjusted - Adjust quickly

Adaptation quickly. - Prevent deviation
• An adjustment must be made within the Scrum - Adapt within the event
events.

MTI Confidential 14
 Beginner

Scrum Intermediate
Advanced

◼ Scrum Values

The Scrum Team members learn and

explore those 5 values as they work
with the Scrum roles, events, and
artifacts.
MTI Confidential 15
 Beginner

Scrum Intermediate
Advanced

◼ Scrum’s Purpose

3-5-3 Rules TRANSPARENCY To proceed the work as a team

ADAPTATION
INSPECTION
To optimize predictability
3 Pillars
and control risk

COURAGE
FOCUS
5 Values COMMITMENT To build the trust relationship
RESPECT
OPENNESS
MTI Confidential 16
 Beginner

Scrum Intermediate
Advanced

◼ Scrum’s Overview

MTI Confidential 17
 Roles
Learn 3 roles in Scrum Team!

MTI Confidential 18
 Beginner

Roles Intermediate
Advanced

◼ Scrum Team
• The Scrum Team consists of one Product Owner, one Scrum Master, and Developers. (Total
10 members or fewer)
• A Scrum Team is a cohesive unit of professionals focused on one objective at a time, the
Product Goal.
• A Scrum Team is cross-functional and self-managing.

Product Owner Scrum Master Developers

Focus on WHY/WHAT Focus on PROCESS Focus on HOW

https://www.visual-paradigm.com/scrum/how-scrum-team-works/

MTI Confidential 19
 Beginner

Characteristic of Scrum Team Intermediate

Advanced

- Cross-Functional -

• Teams have all competencies needed to accomplish the work without depending on others
not part of the team.
• Not only develop, but also cover all tasks of business analysis, testing, UI/UX designing as a
team
※ A team that covers across system components such as front-end and back-end is called “Feature Team”.

https://www.thoughtworks.com/insights/blog/why-product-objectives-are-your-best-guide-team-design

MTI Confidential 20
 Beginner

Characteristic of Scrum Team Intermediate

Advanced

- Self-Managing -

• Teams internally decide who does what, when, and how to accomplish their work,
rather than being directed by others outside the team.
• Tasks should not be assigned and should be pulled by oneself
• Creates an orderly team as a result of individual autonomous behavior.

In "Scrum Guide 2020", ‘Self-Management of the Scrum Team’ is more emphasized than ‘Self-Organization of Developers’.
MTI Confidential 21
 Beginner

Each Role of Scrum Team Intermediate

Advanced

◼ Product Owner (PO) PO

The PO is the owner of product and representative of customer intent.

PO leads the Scrum Team in the right direction to make the product
successful. PO is accountable for maximizing the value of the product.
• Create product vision, manage roadmap, and Product Goal
• Understand customer problems and needs
• Act as primary liaison between the stakeholders and the developers
• Create a release plan and manage releases until delivery
• Creating, maintaining, and ensuring that the product backlog is transparent,
visible and understood.
• Prioritize work based on value
• Review and accept a product created by the developers
• Manage product budget MTI Confidential 22
 Beginner

Each Role of Scrum Team Intermediate

Advanced

◼ PO Principles PO

➢ One PO manages one Product in one Product Backlog

➢ PO is the key-person of the business unit and must be empowered
➢ It's more important to see the big picture than the details
➢ Convey product policy and goal to the Scrum team regularly
➢ Communicate with stakeholders frequently
➢ Assign the person who knows the most in specification definition or acceptance test (PO
does not always do it)
➢ Better to have familiarity with marketing, user experience, promotion, and compliance.
➢ Accept Developers’ proposals positively and improve products continuously (automation,
technical debt reduction, etc.)
➢ Trust Developers without any extra interference with them
➢ "Don't be a good person" (Don't accept half-finished deliverables in Sprint Review)

MTI Confidential 23
 Beginner

2 Types of PO Roles Intermediate

Advanced

Stakeholder Scrum Team

Internal Scrum Master

(Sales Rep, General
Manager)

Product Owner

External
(Customer, User) Developers

<- External Internal ->

Understand the business deeply, identify issues Decide what and in what order, communicate
and needs, indicate the direction, and clarify the specification and acceptance testing, and deliver
purpose and requirements. value by release.
https://fullvirtue.com/poac20151201/
MTI Confidential 24
 Beginner

Each Role of Scrum Team Intermediate

Advanced

◼ Scrum Master (SM) SM

The SM is a true leader who serves the Scrum Team and the larger
organization. SM is accountable for establishing Scrum (archivement of
commitment). SM ensures that the Scrum process work properly.
• Build and maintain the Scrum process
• Facilitate events and meetings (Other members may also facilitate them)
• Cause the removal of impediments to the Scrum Team’s progress
• Visualize the situation of product and team
• Encourage the Developers for continuous improvement
• Coach the Scrum Team and the organization to understand and practice the Scrum
• Support the introduction of Scrum in the organization

MTI Confidential 25
 Beginner

Each Role of Scrum Team Intermediate

Advanced

◼ SM Principles SM

➢ Support 1 to 3 teams (3 teams are the limit even for experienced people)
➢ Not a Project Manager
➢ Work full-time as a SM (can’t work as other roles as well)
➢ Coaching the team members in self-management and cross-functionality
➢ Support the Scrum Team creating high-value Increments that meet the Definition of Done
➢ Improve transparency of products and teams (promote visualization)
➢ Support inspection and adaptation thru Scrum Events
➢ Provide what Developers needs to improve their performance
➢ Help PO to find techniques for effective Product Goal definition and Product Backlog
management
➢ Support team building to build trust
➢ Should not become the police who just makes the scrum team comply with the rules.

MTI Confidential 26
 Beginner

Responsibility of SM Intermediate
Advanced

Accountability for establishing the Scrum Approaches of Scrum Master

(= Team building effective teams that can achieve results)

Structure Relationship

Trainer/Teacher Mentor/Coｎsultant

Contents

• Deliver value
• Grow as a team
• Individuals learn
Moderator Coach

Neutrality

Effective Teams

MTI Confidential 27
 Beginner

Each Role of Scrum Team Intermediate

Advanced

◼ Developers Developers

The Developers consists of professionals who do the work of delivering

a potentially releasable Product Increment* of “Done” at the end of
each Sprint.
* Product Increment …The sum of all the Product Backlog items completed during a
Sprint and the value of the increments of all previous Sprints.

• The center and the core of the product development

• Decide how to achieve potentially releasable increments.
• They do not only implementation, but also requirements analysis, design, testing,
operation, etc.
• Each person is autonomous and self-managed without any instruction

※Not consists with only engineers. No sub-teams or dedicated roles within the team.
MTI Confidential 28
 Beginner

Each Role of Scrum Team Intermediate

Advanced

◼ Developers Principles Developers

➢ Each person does self-management (acts autonomously)

➢ Don't blame others (responsibility lies with the team, not the individual)
➢ Cover all the work as a cross-functional team. Cooperation is essential
➢ Have a product perspective and a customer perspective (proposal to business
divisions, etc.)
➢ Share work with team members daily to achieve Sprint goals
➢ Developers coordinate with other teams by themselves (if you have multiple teams)
➢ Define the "Done" for a Product Backlog item, Sprint and Release to build in quality
➢ Challenge new areas and work processes, and acquire new skills gradually (=
extension of "Done" definition)
➢ Have curiosity and aspirations for technology
➢ If you can outcome properly, you can act freely
MTI Confidential 29
 Scrum Events
Learn 5 events held during the
Sprint!

MTI Confidential 30
 Beginner

Scrum Process Intermediate

Advanced

https://blog.4geeks.io/scrum-for-digital-product-development/

MTI Confidential 31
 Beginner

Scrum Event Intermediate

Advanced

◼ Scrum Event is
• The 5-meeting held during the Sprint period
(Spring Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Product Backlog Refinement)

• Known as “Scrum Ceremony”

• Prescribed events are used in Scrum to create regularity and to
minimize the need for meetings not defined in Scrum.
• A formal opportunity to inspect and adapt Scrum artifacts
*4 events other than Product Backlog Refinement are official.

MTI Confidential 32
 Beginner

Scrum Event Intermediate

Advanced

1 2
Product Sprint
Backlog
Planning
Refinement

5 3
Sprint
Sprint Daily Scrum
Retrospective

4
Sprint
Review

MTI Confidential 33
 Beginner

1. Sprint Intermediate
Advanced

◼ Sprint is
• A time-box of Scrum Events and development work.
• Known as “Iteration”

◼ Rules of Sprint
• The length of the Sprint is set between 1 to 4 weeks. (2-week is common）
• Sprints have consistent durations throughout a development and repeat it
until released.
• Set a goal and deliver a product increment in each Sprint
• No changes that would endanger the Sprint Goal (Such as additional Product
Backlog item during the Sprint)
• Do not lower quality goals
MTI Confidential 34
 Beginner

1. Sprint Intermediate
Advanced

◼ Reason of the Sprint limited to one calendar month

When a Sprint is too long, the definition of what is being built may
change, complexity may rise, and risk may increase.

Limiting Sprint length…

• Sprints enable predictability by ensuring inspection and adaptation of

progress toward a Product Goal at least every calendar month.
• Sprints also limit risk to one calendar month of cost. (Reduce the risk)

MTI Confidential 35
 Beginner

1. Sprint Intermediate
Advanced

◼ Cancelling a Sprint
• PO has the authority to cancel the Sprint before the Sprint time-box is
over.
• A Sprint would be cancelled if the Sprint Goal becomes obsolete
⁃ If the company or business division changes its direction
⁃ If the market conditions change drastically
⁃ If the technology conditions change drastically
• When a Sprint is cancelled, any completed and “Done” Product
Backlog items are reviewed.
• All incomplete Product Backlog items (PBI) are re-estimated and put
back on the Product Backlog item due to the work done on them
depreciates.

MTI Confidential 36
 Beginner

2. Sprint Planning Intermediate

Advanced

◼ Sprint Planning is
• The event that plans the work to be performed in the Sprint
• Holds on the first day of the Sprint
• Two parts in Sprint Planning (Explained on following pages)
⁃ Part 1：What can be done?
⁃ Part 2：How will the chosen work get done?

• Input Information
✓ Product Backlog
✓ The latest Product Increment
✓ Definition of “Done” (=DoD)
✓ Retrospective commitments (=Kaizen Actions)
*1 Capacity…Time available to complete tasks by team
✓ Projected capacity*1 and velocity*2 of the *2 Velocity…Team’s development speed.
Developers Total number of PBI points completed in one Sprint
MTI Confidential 37
 Beginner

2. Sprint Planning Intermediate

Advanced

◼ Sprint Planning Part 1

• “What can be done?”
⁃ Set the Sprint Goal (What value can be delivered with the Increment as a result of Sprint?)
⁃ Forecast the functionality that will be developed during the Sprint
• PO explains the objective that Sprint should achieve, and the Product
Backlog items (PBI), then Developers review, and they mutually agree.
• Work time for 1 PBI should be within 1 sprint
• Select high-prioritized and Ready(ready-to-work) PBI*
* Ready PBI: An appropriately sized PBI that has clear acceptance criteria, is as independent
as possible, and can be estimated. The specifications are well considered.

[Caution]
• The event to re-recognize business goals as well
• Check if team can proceed smoothly to the release
MTI Confidential 38
 Beginner

2. Sprint Planning Intermediate

Advanced

◼ Sprint Planning Part 2

• “How will the chosen work get done?”
⁃ Developers decide how to build selected PBI to product increment
⁃ Create Sprint Backlog (=Planning to deliver selected PBI)
• Identify tasks to meet Done conditions
• Work time for 1 task should be within 1 day
• May invite other people to attend to provide technical or domain advice

[Caution]
• PO helps to answer any Developers’ question at any time even if PO doesn’t join Part 2.
• By the end of the Sprint Planning, Developers should be able to explain to the PO and SM
how it intends to accomplish the Sprint Goal and create the anticipated Increment.

MTI Confidential 39
 Beginner

3. Daily Scrum Intermediate

Advanced

◼ Daily Scrum is
• The event for Developers to plan work for coming working day
⁻ They can select the way (promote focus and self-management)
⁻ Improve communication and give a quick decision-making opportunity
• Also called stand-up meeting or morning meeting
• Held at the same time and place each day (within 15 mins)
• An opportunity to inspect progress toward the Sprint Goal and adapt the Sprint
Backlog for re-planning as necessary
• Each member may answer following 3 questions to participants
⁻ What did I do yesterday (that helped the Developers meet the Sprint Goal)
⁻ What will I do today (to help the Developers meet the Sprint Goal)
⁻ Do I see any impediment (that prevents me or the Developers from meeting the Sprint Goal)

* Above 3 Daily Scrum questions have been removed from ”Scrum Guide 2020”
MTI Confidential 40
 Beginner

3. Daily Scrum Intermediate

Advanced

◼ Notes on Daily Scrum

• Time limit
Do not talk for more than 15 mins. If an impediment that hinders the Developers’
progress and unable to make a decision right away, the Developers meet immediately
after the Daily Scrum for detailed discussions, or to adapt, or re-plan (including
specification consideration).
• Participation outside of the Developers
If SM, PO, Manager, and other stakeholder participate, ensures that they do not disrupt
the Developers. (Avoid instructing a task or making developers report to management)

MTI Confidential 41
 Beginner

4. Sprint Review Intermediate

Advanced

◼ Sprint Review is
• An event to inspect the Increment and adapt the Product Backlog
-> The presentation of the Increment is intended to elicit feedback and foster collaboration
• Held at the end of the Sprint (the last day)
• The Scrum Team and stakeholders review what was done in the Sprint (=Sprint Goal)
• Based on Sprint achievements, attendees collaborate on the next things that could be done
• Discuss progress toward the Product Goal

MTI Confidential 42
 Beginner

4. Sprint Review Intermediate

Advanced

◼ Noted on Sprint Review

Make sure NOT to have following Sprint Review!
✓ PO does not invite stakeholder (key person and requester related to developed PBI)
✓ Takes time to prepare a test account, test data, and start the screen after the sprint review starts
✓ Not explain the problems or how they were resolved of which the Developers faced during the Sprint
✓ Although PO has not confirmed operations, PO judges its completion only by hearing stories from the
Developers
✓ Although it is not 100% completed (although there are minor corrections and confirmations), it is
considered to be finished and included in velocity
✓ PO does not update product backlog immediately after reviewing increment
✓ Not discuss what to do next and provide valuable input to the next Sprint Planning
✓ PO does not update release plan or predict delivery date after Sprint Review
✓ Limiting it to a presentation(demonstration), and not a working session

MTI Confidential 43
 Beginner

5. Sprint Retrospective Intermediate

Advanced

◼ Sprint Retrospective is
• The opportunity to plan ways to increase quality and effectiveness
• The last event in the Sprint that is held after the Sprint Review
• The most important event for the Scrum Master who is responsible to encourage the
Scrum Team for improvement
• To ensure the meeting is positive and productive
• To build team culture as well

◼ Purpose of Sprint Retrospective

• Inspect how the last Sprint went with regards to individuals, interactions, processes, tools,
and their Definition of Done
• Identify and organize items that worked and items that need improvement in the future, and
create improvement action plan for Scrum Team’s work
• Problems (Assumptions) that led them astray are identified and their origins explored

MTI Confidential 44
 Beginner

5. Sprint Retrospective Intermediate

Advanced

◼ Steps of Sprint Retrospective

No Step Description
1 Set the Stage After confirming goal and agenda, it’s better to prepare something for session. SM makes good mood so that
everyone can join easily.
2 Gather Data After confirming objective and subjective information, have a common understanding between team members.
3 Generate Insights Consider and discuss a common understanding of team from a variety of perspective, and then bring ideas
together through activities.
4 Decide What to Do Prioritize ideas of team. Choose improvement and trial to bring a change to team.
5 Close the Perspective Summarize how team executes plan and commitment, thank to attendees, and close the retrospective.

MTI Confidential 45
 Beginner

5. Sprint Retrospective Intermediate

Advanced

◼ Sprint Retrospective Methods

Representative retrospective *Details of each method will be described later
• KPT (Keep, Problem, Try)
• 4Ls (Liked, Learned, Lacked, Longed for)
• FDL (Fun, Done, Learn)
• SSC (Start, Stop, Continue)

[Caution]
• Check the result of previous actions in the beginning
• Do not blame and complain (Do not blame a specific individual)
• Problems should not be biased (Focus on not only implementation, but also process, tool and people, etc.)
• Do not try to solve all the problems at once (Vote to choose problems to be solved)
• Solve small problems that happens every day, in the Daily Scrum or daily work

MTI Confidential 46
 Beginner

5. Sprint Retrospective Intermediate

Advanced

◼ KPT
A framework that accelerates work and project improvement. KPT is
an acronym for Keep, Problem, Try, and is also pronounced as "képt”.
In Japan, KPT is often used as a retrospective method to focus on
improvement.
Good events during the sprint, what you want to continue (=Keep),
problems that occurred during the sprint, points to be improved
(=Problem), and what you want to try to improve in the problems
(=Try). Discuss each of them.

If these improvements are implemented and effective, they will be added to Keep at the next Retrospective.
*There are various rules, but please refer to the example procedure below.

1. Review result of previous Try Move good result of Try to Keep, and poor result of Try to Problem (5-min)
2. Run the KPT for the Sprint Post Keep (5-min)->Share Keep each other (5-min)->Post Problem (5-
min)->Share Problem each other (5-min)->Narrow down focused Problem
by voting (5-min)->Post Try (5-min)->Choose the best Try (10-min)

MTI Confidential 47
 Beginner

5. Sprint Retrospective Intermediate

Advanced

◼ 4Ls
The method to classify ideas into 4 quadrants: Liked, Learned, Lacked, Longed for. This
retrospective leads to the next improvement.
Liked: What was good in the Sprint? What was favored with team?
Learned: What have you learned? (Lessons, Learning)
Lacked: What was lacked within the team?
Longed for: What do you want to promote?
(Future expectations and hopes)

[Step]
1. Split board (canvas) into 4 areas
2. Participants bring ideas individually and place them to each area (10-15min)
3. Explain ideas and group them. (10-15min)
4. Vote to prioritize (5-10min)
5. Discuss according to priority (20-40min)

MTI Confidential 48
 Beginner

5. Sprint Retrospective Intermediate

Advanced

◼ FDL
An abbreviation of Fun(What have enjoyed), Done(What have done), Learn(What have learned).
Unlike general retrospective, it is a retrospective that focuses on positive thing. Review how 3
areas overlap and discuss the bias or the area you aim for next.
[Step]
1. Draw circles for Fun/Done/Learn area on whiteboard or a big paper. Make sure
to have sufficient overlap area.
2. Each member writes what he/she did on sticky note.
3. Share and discuss your content on sticky note and place it on suitable area.
4. Place marks on areas that the previous Sprint or the project was applied to.
5. Review the board and discuss which area team should aim for the next sprint
or the next project.
[How to select area (sample)]
➢ “Played a game with everyone” -> Place it on upper area of “Fun”
➢ “Shared skills by mob programming, but progress was slow” -> Gained motivation by mob programming brought Fun and
shared skill led Learn, place it on “Fun-Learn” area.
➢ “Newly learned Vue.js realize the function” -> It was Fun, Learned Vue.js, and delivered new feature, place it on
Fun/Done/Learn area.
MTI Confidential 49
 Beginner

5. Sprint Retrospective Intermediate

Advanced

◼ SSC
An abbreviation of Start(what we newly start), Stop(what we stop), Continue(What we continue).
SSC is a framework used to review work, instead of trying new things, it also decides to stop. It
is useful not only for project feedback but also for 1-on-1 meetings because it is used in situations
to eliminate waste or clarify priorities. It can also reduce overwork.

[Step]
1. Make columns for Start, Stop, Continue on whiteboard
2. Each member writes what he/she has done on sticky note
3. Group sticky notes in each column, and each person casts 3
votes for grouped notes.
4. Select top 3 notes and start a discussion
5. Write action items after discussion, and assign actions to person
in charge

MTI Confidential 50
 Beginner

6. Product Backlog Refinement Intermediate

Advanced

◼ Product Backlog Refinement is

• Reviewing and maintaining the Product Backlog for next Sprint and future Sprint
• Adding detail, sizing, and ordering to PBI
• The input for next Sprint Planning (To have Ready PBI)
• Known as “Backlog Grooming” *Not recommended recently
• Held in the middle of previous Sprint
• Usually consuming no more than 10% of the capacity of Developers

[Caution]
• No refinement will impact to Sprint Planning due to lack of preparation.
“The Product Backlog isn't "Ready-Ready" and the Sprint cannot continue. The team Goes to
the Beach.” by Jim Coplien
• PO is responsible for maintaining and prioritizing the product backlog, but the refinement
needs to be done by the developers in cooperation with PO.

MTI Confidential 51
 Beginner

6. Product Backlog Refinement Intermediate

Advanced

◼ What to do in Refinement
• Add, revise, and delete PBI
• Divide and adjust granularity of PBI (Create story based on INVEST*)
• Clarify and detail PBI (Create specifications)
• Order and prioritize PBI
• Define Ready/Done
• Create Acceptance Criteria Preparation determines
everything
• Estimate PBI

* INVEST: A simple set of rules used in creating well-formed user stories.

Acronym of Independent, Negotiable, Valuable, Estimable, Sized Right(Small), Testable.

MTI Confidential 52
 Beginner

Scrum Event Intermediate

Advanced

◼ Event Time-box
• Scrum events are time-boxed events with a time limit.
• Most events have fixed-times. Product Backlog Refinement should be
less than 10% (5-10%) of the total Sprint.

(Example) Meeting time of the Scrum Event for each Sprint period. ※Applied if 1day=8 working hours
Scrum Event 4 Weeks 3 Weeks 2 Weeks 1 Week
Sprint Planning 8h 6h 4h 2h
Daily Scrum 15 min / day
Sprint Review 4h 3h 2h 1h
Sprint Retrospective 3h 2 h 15 min 1.5 h 45 min
Product Backlog Refinement 8 - 16 h 6 – 12 h 4–8h 2–4h

MTI Confidential 53
 Beginner

Scrum Events Intermediate

Advanced

◼ Participants

Event PO SM Developers Stakeholder

Sprint Planning Part 1
◎ ○ ◎ △
Part 2
△ ○ ◎ △
Daily Scrum
○ ○ ◎ △
Sprint Review
◎ ○ ◎ ○
Sprint Retrospective
○ ◎ ◎ △
Product Backlog Refinement
◎ ○ ◎ ○
◎ Mandatory ○ Recommended △ Optional × Unnecessary

MTI Confidential 54
 Beginner

Scrum Events Intermediate

Advanced

◼ Opportunity to Inspect and Adapt

Event Inspection Adaptation

Sprint Planning • Product Backlog • Sprint Goal
• Velocity • Forecast
• Capacity • Sprint Backlog
• Retrospective Commitment

Daily Scrum • Progress towards the Sprint Goal • Sprint Backlog

• Daily Plan
Sprint Review • Product Increment • Product Backlog

Sprint Retrospective • Sprint • Actionable Improvements

• Definition of ”DONE” • Definition of “DONE”

Product Backlog Refinement • Product Backlog • Product Backlog

MTI Confidential 55
 Beginner
Intermediate
Advanced

MTI Confidential 56
 Artifacts
Learn Artifacts of Scrum!

MTI Confidential 57
 Beginner

Artifacts Intermediate
Advanced

◼ Scrum Artifacts
Scrum’s artifacts represent work or value to provide transparency and opportunities for
inspection and adaptation. Artifacts defined by Scrum are specifically designed to
maximize transparency of key information so that everybody has the same
understanding of the artifact.

Product Backlog Sprint Backlog Product Increment

A list of PBIs needed A list of PBIs selected The previous product

to create a product in the Sprint and and the increment of
tasks that subdivide PBI completed in
those items current Sprint

MTI Confidential 58
 Beginner

Artifacts Intermediate
Advanced

◼ Commitment in each artifact

Each artifact contains a commitment to ensure it provides information that enhances
transparency and focus against which progress can be measured

• For the Product Backlog it is the Product Goal

• For the Sprint Backlog it is the Sprint Goal
• For the Increment it is the Definition of Done

These commitments exist to reinforce empiricism and the Scrum values for the Scrum
Team and their stakeholders

MTI Confidential 59
 Beginner

Artifacts Intermediate
Advanced

◼ Conceptual diagram of commitment perspective

MTI Confidential 60
 Beginner

Product Backlog Intermediate

Advanced

◼ Product Backlog
• A Product Goal and an ordered list of functional/non-functional requirements that are
needed to implement for the product. It is the single source of work undertaken by
the Scrum Team
• The PO is the owner of Product Backlog and is responsible for the Product Backlog,
including its content, availability, and ordering.

◼ Product Goal
• A future state of the product which can serve as a target for the Scrum Team to plan
against
• The long-term objective for the Scrum Team. And they must fulfill (or abandon) one
objective before taking on the next.

MTI Confidential 61
 Beginner

Product Backlog Intermediate

Advanced

◼ Product Backlog Item (PBI)

• Each requirements managed in the Product Backlog is called “Product Backlog Item”
• Often abbreviated and called PBI.
• Have the attributes of a description, order, size, value, Definition of Ready, Definition
of Done, and acceptance criteria in PBI.
• PBI≒Writing User Story (which represents what user wants to achieve)
• Make the size of PBI fit in one Sprint.

MTI Confidential 62
 Beginner

Product Backlog Intermediate

Advanced

◼ Type of PBI
• User Story (Functional requirement)
• Technical Story (Non-Functional requirement)
• Exploration (Hypothesis verification)
• Architectural task
• Infrastructural task
• Spike (Feasibility Verification)
• Release task
• Bug fix
• Retrospective Commitment (Improvement Action)

◼ How to Manage Product Backlog

• See the figure on the right

MTI Confidential 63
 Beginner

Product Backlog Intermediate

Advanced
It’s important to write PBI must be ready to The PO accepts PBIs based on
start developing. The Developers refers to
a primary benefit. Why the acceptance criteria. Relative estimates are
success or failure of Definition of Done
does this PBI need to Detailed test cases should be often used. Estimate
Sprint depends on when creating Sprint
be accomplished? managed separately.
- Sample of Product Backlog - preparation. Backlog tasks. scale, not time.

ID Priority User Title Benefit/Value Ready Done Acceptance Criteria Effort

/Story Point

1165 1 Member Prepare meal data Improve • Specification • Create/Update DB • Prepare meal data ordered by what 5pt
ordered by what performance document is prepared. document members ate the most in advance (Data
members ate the most for data • estimation to backlog. • Verify that data input within one month)
in advance referral • Decide how to realize inserted into table is • Data is generated once a month.
correct • Processing must be completed within 30
Divide a big PBI
• All acceptance criteria minutes.
into small ones
have been met.
1164 2 Member See meal data ordered To save the • Specification • Create/Update API • Search results are displayed by search 3pt
by what members ate time to select document is prepared. document words and categories.
the most meal menu • UI design document • Execute UT • The number of meal menu search results
is prepared. • Automate UT on CI should be the same as before.
• The method of effect env • Foods are ordered by frequency of using,
measure ment is clear. • Execute IT if they have the same this ordering, they
• All acceptance criteria are ordered by food-code.
have been met
1160 3 Admin / Contact with supporter Easy to inquire • Clarify the rule how • Execute UT • The following procedures can be 2pt
Staff by chat form (chat bot) how to use to inquire in chat • Automate UT on CI performed
form env 1. User: Chat icon > Message input>
• Execute IT Send message
• All acceptance criteria 2. Service side: Message receive>
have been met Message input > Message reply
3. User: Receive message > Close chat

• Questions set by service side are

displayed on the user side.
• Can answer questions set by service side

↑Prioritized order One PBI (Product Backlog Item) MTI Confidential 64

 Beginner

Product Backlog Intermediate

Advanced

◼ Acceptance Criteria (AC)

• Criteria/conditions to check when testing from the user's point of view
• Test scenarios and rules that can be judged quantitatively or objectively
• Not depending on the solution
• Used when PO or requesters to conduct acceptance tests with Yes/No judgement.
• Created by PO or requesters, but preferable to have developers involved.
• One or more criteria for one PBI (User Story)

◼ PBI/Acceptance Criteria/Test case Relation

PBI (US) Acceptance Criteria１ Test case１
Acceptance Criteria２ Test case２
Test case３
MTI Confidential 65
 Beginner

Product Backlog Intermediate

Advanced

◼ How to create Acceptance Criteria

Case）・After entering name, date of birth, and phone number on the profile screen, user can check
the entered contents in the preview screen.
・The verification code is displayed in the email user received.

Example Mapping ＝ Practice for creating acceptance criteria and test cases, as introduced in Agile Testing

PBI (US) Display numbers of

users in graph nicely

① Set one rule (Acceptance Criteria)

Rules Scale Data stays The max value is adjusted
Spike ② List multiple examples (Test Cases) related to
shows 4 inside of to larger than the second
(Acceptance Criteria) lines. area from the top of the scale
the rule
③ If a new rule is found from the arranged
If 1000: If 1500: If 600: If 2: examples, add the second, third, and so
250, 500 400, 800 200, 400 0.5, 1 Display decimal
Example 750, 1000 1200, 1600 600, 800 1.5, 2 point scale? on… to rules
(Test Cases) How to handle if
④ Questions about the specifications are
If 800: If 1050: If 150:
250, 500 250, 500 40, 80 the max value is subject to verify as Spike
750, 1000 750, 1000 120, 160 0 in the scale?

MTI Confidential 66
 Beginner

Product Backlog Intermediate

Advanced

◼ Monitoring Progress Toward Product Goal

• Sum the total of remaining work to release in every Sprint (Sprint Review)
• PO evaluates whether the product goal will be reached by the deadline based
on the total remaining work and the velocity
• The following practices may be used to track progress
Release Burndown Chart Release Burnup Chart

MTI Confidential 67
 Beginner

Product Backlog Intermediate

Advanced

◼ Progress Analysis in the Burndown Chart

If there is a gap between the Planned Line and the Actual Line, you
will find and address the problem. Examples of analysis are as follows.

The Actual Line is below the Planned Line（Ahead of schedule）

• Someone is speeding up work schedule by overtime etc.
• Estimated points excessively, but when we tried, the work content was easy
• Completed tasks earlier because already experienced similar function

The Actual Line is above the Planned Line（Behind the

schedule）
• Tasks have been added in the middle
• Gave priority to an urgent task (such as system incident)
• When working, implementation was difficult and delayed than expected.
• Proceeding task was delayed due to unplanned absence

The analysis method is the same for both Release Burndown Chart
and Sprint Burndown Chart.

💡 The advantages of paper burndown chart are that all team

members are more aware of progress than with an online tool,
and analytical comments can be posted on the chart.

MTI Confidential 68
 Beginner

Sprint Backlog Intermediate

Advanced

◼ Sprint Backlog
• The set of Product Backlog items selected for the Sprint, plus a plan for delivering the product
Increment and realizing the Sprint Goal.
• Developers are the owner of Sprint Backlog. Only Developers can change Sprint Backlog.
• The tasks required to achieve the sprint goal have been identified.
• The task is detailed enough to be understood in Daily Scrum.

◼ Task Rules
• The task is visualized
• Identify tasks based on Definition of Done(=DoD)
• The time for one task does not exceed one day
• Must include at least one high priority process improvement identified in the previous
Retrospective meeting
• As new work is required, Developers adds it to the Sprint Backlog
MTI Confidential 69
 Beginner

Sprint Backlog Intermediate

Advanced

◼ How to create good tasks (SMART)

-> Is it clear what to do?

-> How to complete the task?

-> Can it be achieved really?

-> Is it for developers?

-> By when must it be completed?

MTI Confidential 70
 Beginner

Sprint Backlog Intermediate

Advanced

◼ How to manage Sprint Backlog

• Tasks are often managed by using the Task Board (Kanban)
• Manage PBI-related tasks in 3-status
⁃ To Do：New waiting task
⁃ In Progress / Doing：Work-in-progress task
⁃ Done：Completed task
• If all tasks associated with a PBI are completed, then that PBI
is also completed
• The Task Board (Kanban) may be customized by adding
status such as Review or Block

MTI Confidential 71
 Beginner

Sprint Backlog Intermediate

Advanced

◼ Monitoring Sprint Goal Progress

• Sum the total remaining work of Sprint Backlog everyday
• Developers track the total amount of work remaining in the Daily Scrum and
track their progress to forecast their Sprint goals.
• The following practices may be used to track progress
Sprint Burndown Chart Sprint Burnup Chart

MTI Confidential 72
 Beginner

Sprint Backlog Intermediate

Advanced

◼ Velocity
• Team’s development speed. Velocity is useful to plan and predict releases
• Total PBI story points “completed” in one Sprint
• The average value of the last 3-4 Sprint is often used as velocity
• Forecast release schedule: Total PBI Points Required for Release / Velocity
= Number of Sprints
• As the improvement progresses, the velocity of the Developers increases

◼ Misunderstanding of velocity
× Velocity is productivity -> Story Point represents development scale, not business value
× Velocity can be standardized -> It is calculated in a specific context for a specific team during a
specific period, and non-sense for comparison between teams
× Can convert velocity to person-hours -> The delivered quantity will be fixed if converted. If the
technology or business domain changes, the delivered quantity will also change
https://www.ryuzee.com/contents/blog/4802
MTI Confidential 73
 Beginner

Product Increment Intermediate

Advanced

◼ Product Increment
• The sum of all the PBIs completed during a Sprint and the value of the
increments of all previous Sprints
• Meeting the definition of “Done” and acceptance criteria, and being a
potentially shippable at any time (however, PO decides to release it)
• If multiple teams develop, the output of all the teams must be integrated

MTI Confidential 74
 Beginner

Product Increment Intermediate

Advanced

◼ Definition of Done (DoD)

• A formal description of the state of the Increment when it meets the quality measures
required for the product
• The DoD creates transparency by providing everyone a shared understanding of what
work was completed as part of the Increment
• If a Product Backlog item does not meet the DoD, it cannot be released
• If there are multiple Scrum Teams working together on a product, they must align the
common DoD between teams
• The DoD can be set for each granularity of PBI, Sprint and Release

Completion Condition = DoD (Definition of DONE)

Start Condition = DoR (Definition of READY)

MTI Confidential 75
 Beginner

Product Increment Intermediate

Advanced

◼ Examples of DoR/DoD
DoR for PBI
• Problems in development are
solved (Verification /
Investigation is done)
• Specification is fixed
• UI design is prepared
• Ready / Done is defined
• Acceptance Criteria are
created
• Relative estimation for PBIs is
done
• Dependencies with other
teams’ tasks are clear
• Target PBIs are added on ADO
DoD for PBI DoD for Sprint
• All codes are checked-in, • DoD for all PBIs is met
including test code and • Design documents are updated
production code • All bugs are solved, or due
• Codes are reviewed date to solve them is decided
• No modification required by • Code coverage of UT is more
static analysis. than 80%
• All UT is passed • Automated test like UT and RT
• All RT is passed is executed, and any error is
• All tasks related to the PBI are not occurred
done • All IT is passed
• Technical debt doesn’t
increase compared to the
previous sprint
DoD for Internal Release
• Milestones are created on
ADO
• DoD for all Sprints is met
• All bugs are solved
• Rehearsal is done on RC
environment
• UAT by mobile devices is
passed
• Load test is done
• Security assessment is done
• Recovery plan in case of
system incident is updated
DoD for External Release
• Milestones are created on
ADO
• DoD for Internal Release is met
• Recovery plan in case of
system incident is tested
• Manual is updated
• Release on production
environment is approved
• Release is done on production
environment
• Operation check is done right
after release

➢ Define concretely what to do and when to do in order to complete

➢ Above “DoR/DoD for PBI” is common definition, and definition of each PBI on Product Backlog could increase
or decrease
➢ If there is difference between the sprint completion and release completion, time for end-game could get
longer
MTI Confidential 76
 Beginner

Impediment List Intermediate

Advanced

◼ Impediment List
• A list of obstacles to development (optional artifacts)
• SM tries to manage impediments in the early time
• Ask a higher-level management or team members for a solution as needed

Impediment List (Sample)

Due
No Priority Impediment Solution PIC
Date
1 1 Developer’s PC performance is poor, and work Procure Developer’s PC SM (Tanaka) 5/23
efficiency is low
2 2 PO’s requests come late (It cannot be finished in Have PO to provide requests in advance for Product PO (Sato) 5/30
this Sprint since it is shared in Sprint Planning) Backlog Refinement
3 5 The auto test process is slow dues to the low Ask manager to get an approval for procuring a CI server SM (Tanaka) 6/10
spec of the CI environment.
4 3 Takes long time to investigate every time because Set time for refactoring in each Sprint to reduce technical SM (Tanaka) 5/30
the code is complicated and hard to read. debt as much as possible ->create rules first
5 4 Velocity does not increase since one of engineers Senior engineer trains the person while using pair Dev (Watabe) 5/30
has just skill-converted. programming

MTI Confidential 77
 Scaling Method
How do we form teams and work
together when the number of
members increases?

MTI Confidential 78
 Beginner

Scaling Method Intermediate

Advanced

◼ Scrum of Scrums (SoS)

• One of scaled agile methods that used to collaborate between teams and
coordinate work
• For teams of more than 10 people, divide into multiple teams (less than
10 members in each team) for each feature* and use the same practices
as Scrum
• A Scrum of Scrums Master (SoSM) may
be assigned when multiple Scrum Masters
gather at the SoS. And also a Chief
Product Owner (CPO) may be assigned to
supervise multiple Product Owners.

*feature…Product functions and features as seen by the user. There is no distinction between front-end and back-end. cf. component.

MTI Confidential 79
 Beginner

Scaling Method Intermediate

Advanced

◼ Scrum of Scrums (SoS) Meetings

• Scale Daily Stand-up Meetings and hold Scrum of Scrum (SoS)
• After each team's daily stand-up meeting is over, representatives of each team
(Scrum Master, etc.) will gather and hold an SoS meeting
• No need to have SoS every day, but need to communicate regularly (Every other
day, etc.)
• Share the following 4 points in a 15-minute timebox
1. What team has done since the last SoS meeting
2. What team will do by the next SoS meeting
3. What are the issues that hinder progress
4. Work related to other teams that team is trying to do (check dependencies)

MTI Confidential 80
 Beginner

Scaling Method Intermediate

Advanced

◼ Limits of Scrum of Scrums (SoS)

The Scrum of Scrum (SoS) expands the Scrum team, where Scrum Masters get
together to share situations and solve common problems. This method has existed
for a long time, but it brings the problem to how-to promote interaction and
communication based on a common goal when the number of teams increases, and
so the principles/rules/practices are not enough. As a result, Agile research has
progressed over the last decade, and new agile scaling methods have emerged.

◼ Scaling Agile / Enterprise Agile

➢ Scrum@Scale <- Scaling SoS

➢ LeSS (Large-Scale Scrum)

➢ SAFe (Scaled Agile Framework)
➢ Nexus
➢ Spotify Model
➢ DA (Disciplined Agile)
MTI Confidential 81