Sie sind auf Seite 1von 164

Professional

SCRUM FOUNDATIONS
Hiren Doshi | hirendoshi@practiceagile.com | (+91) 96193 22001 @ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 1
“If you haven’t found it yet, keep looking. Don’t settle.
As with all matters of the heart, you’ll know when you
find it.”
- Steve Jobs

1
Introductions

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 2


Why Are You In This Class?

• Introduce yourself
• Have you used Scrum before?
• What’s your background:
• Development?
• IT?
• Other?

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 3


Agenda

• Introductions • Mastering Scrum


• Fundamentals of Scrum • Planning with Scrum
• The Scrum Framework • Getting Started

With joyful exercises and actual


Sprints along the way!

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 4


Exercise

Make roughly even-sized, multi-disciplinary teams of 5


Team Start-Up members, or less.
• Ensure these Scrum Teams have a mixture of skills
• Technical and non-technical skills will matter

Post for all to see:


• An animal mascot for your team
• The added value of working as teams
• 3 Things you want to learn in this class

10
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 5


It’s Your Experience. Own it.

Guidelines for how to work during this class:

This course is • Day timing


collaborative. • Lunch, break times and exercises
Talk to me, talk to • Electronics such as phones, tablets, and
each other. laptops
• Off-track discussions

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 7


Professional Scrum at Scrum.org

For everyone Scrum Masters Product Owners Teams Development Managers


Managers Product Managers Architects Leads Leaders
Advanced Advanced Business Analysts Managers
Practitioners Practitioners DB Specialists Scrum Masters
Designers Product Managers
Developers Advanced
Practitioners
Testers

www.scrum.org/courses
v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 8
Professional Scrum Foundations Course

PURPOSE AUDIENCE

• Provide practical insights in the • People new to Scrum or


mechanics and practices of starting with Scrum, having
Scrum so students can use it to limited or no practical
build complex products. experience.
• Build releasable software in • Ideally, attendees have read
teams with a mix of discussion the Scrum Guide and have
and exercise to understand passed the Scrum Open
empirical decision making. assessment.

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 9


“A man who carries a cat by the tail learns something
he can learn in no other way.”
- Mark Twain

2
Kickoff

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 10


Case Study – Animal Website

I am a passionate fan of ________________ (animal name)


Animal Website
Introduction Which is why I have hired your team to build a website
dedicated to this animal. The site will present facts about the
animal, pictures, statistics, etc.

• A list of my wants and needs is available in the handout.


• I have budget for a maximum of 4 iterations.
• The site may be made in any language the team chooses.
English, Klingon, Estonian, Japanese, or whatever is
appropriate to the classroom.
• During the review, the site must be shown from a single
team-member's machine or the instructor's machine.

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 11


Case Study – Animal Website

Kickoff You have 30 minutes to review your requirements,


determine how to best meet them and turn them
into a website.
After the time-box, each team will demonstrate its
website (15 min) and reflect on how the work went
(15 min).

60
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 12


3
Fundamentals of Scrum

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 14


The Complexity of Software Development

• Simple
everything is known
Scrum

• Complicated
Thrives Here

more is known than unknown

• Complex
more is unknown than known

• Chaotic
very little is known
Source: Ralph Stacey, University of Hertfordshire

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 15


Situation Dictates The Type of Process

PREDICTIVE EMPIRICAL

• Given a well-defined set of inputs, • Frequent inspection and adaptation


the same outputs are generated occurs as work proceeds
every time • Outputs are often unpredictable
• Follow the pre-determined steps to and unrepeatable
get known results

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 16


Exercise

Situation Dictates • Which process control model fits software


development, predictive or empirical?
the Type of
Process • Which model do you apply today?

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 17


Scrum Implements the Empirical Process

We all know what


is going on.
Transparency

OK to change Check your work


tactical direction. as you do it.

Adaptation Inspection

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 18


Definition of Scrum

Scrum (noun):
A framework within which people can
address complex adaptive problems, while
productively and creatively delivering
products of the highest possible value.

www.scrumguides.org

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 19


Scrum: What’s in a Name?

“…as in Rugby, the ball gets passed within the team as


it moves as a unit up the field.”
- Takeuchi-Nonaka – The New New Product Development Game (1986)

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 20


Scrum for complex work

• Not just for software!


• Research and identify markets
• Hardware
• Government
• Process development
• Managing organizational operations
• Marketing
• Release products and enhancements,
as frequently as many times per day
• Support the entire product, through
its entire lifecycle
v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 21
Scrum in a Nutshell

1.The team plans to deliver working software in 30 days or less


2.The team creates the software
3.The team offers their work for inspection to gather feedback
4.The team adapts the plan, based on the feedback, for the next
cycle
Repeat…

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 22


Exercise

Where is the value of the Scrum Values for your daily work?
Scrum Values

10
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 23


Empirical Processes Require Courage

Trust & Inspection


Transparency Goal
Courage & Adaptation

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 24


Scrum Delivers Frequently

Traditional Development
Plan Analyze Design Code Test Release Review

Scrum
Analyze Analyze Analyze Analyze Analyze
Review/Reflect

Review/Reflect

Review/Reflect

Review/Reflect

Review/Reflect
Design Design Design Design Design
Plan

Plan

Plan

Plan

Plan
Code Code Code Code Code
Test Test Test Test Test
Release Release Release Release Release

Working software is available.

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 25


Comparing Evolutions Waterfall Scrum

Visibility Ability to Change

Business Value Risk

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 26


TAKE • Software development resides in the complex
domain.
AWAY • The right process produces the right results; the
best fit for complexity is the empirical process.
Fundamentals of
Scrum • The 3 legs of empiricism are inspection,
adaptation and transparency.
• Transparency requires trust and courage.

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 27


4
The Scrum Framework (1)

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 28


Exercise

Do you know the elements of the Scrum framework?


What is Needed
For Scrum?

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 29


Roles, Artifacts and Events in the Scrum Framework
Roles

• Product Owner
• Development Team
• Scrum Master

Artifacts

• Product Backlog
• Sprint Backlog
• Increment

Events

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 30


Roles: Each One Has A Specific Accountability
Scrum Team

Maximizing the value of the Product


Managing the Product Backlog
Creating “Done” Increments
Product Development Quality of the Increment
Owner Team

Scrum Master
Promote and support Scrum
Removing impediments

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 31


Product Owner
• Maximizes the value of the Product
• Manages the Product Backlog
Ideally Product • Chooses what and when to release
Owners have • Represents stakeholders and customers to the
Profit & Loss Development Team
accountability for
the product.

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 32


Exercise

Identify Your Who will be the Product Owner in your team?


Product Owner What qualities are you looking for?

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 33


The Development Team
• Creates the product Increment
• Operates in a series of Sprints
• Organizes itself and its work
Self-organizing • Collaborates with Product Owner to maximize value
rarely means
self-managing

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 34


The Development Team

Must have all the skills it needs to deliver a


done Increment – Ideally more than one
team member has the competency

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 35


Scrum Master
• Promotes and supports Scrum as
defined in the Scrum Guide
• Helps everyone understand Scrum
Personifies agility theory, values, practices, and
rules
and
• Provides guidance and support for the
professionalism Scrum Team and organization

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 36


Exercise

Identify Your Who will be the Scrum Master in your team?


Scrum Master What qualities are you looking for?

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 37


Scrum Roles Review

May Select
(hire) Product Owner

Development Team

Scrum Master Service


Provision Flows

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 38


Artifacts: Each One Contains Specific Information

•Holds the requirements for the product


Product Backlog
•Managed by the Product Owner

•Holds all work for the Sprint Goal


Sprint Backlog
•Managed by the Development Team

•Working addition to the product


Increment
•Potentially releasable

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 39


Product Backlog Holds the Plan for Future Sprints

• An inventory of work for the Development Team


• Minimal but sufficient
• An ordered list of potential features of the product
• The single source of truth for what is planned
in the product
• Owned and managed by the Product Owner
• Public, available and transparent

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 40


Product Backlog Item (PBI)

• Transparent unit of deliverable work


• Contains clear acceptance criteria
• Criteria for successful completion
• Answering what will be true when this works
• May reference other artifacts like:
• Specifications, Mockups, Architecture Models
• Sized appropriately
• May be completed within a single Sprint
• Typically with a few other PBIs

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 41


Valid Product Backlog Items

Feature
Constraints Behaviors
Definitions

User Actions Bugs /


Use Cases
or Stories Defects

Non-
Desirements functional
Requirements
v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 42
Sprint Backlog Holds the Plan for the Current Sprint

• Progress within the Sprint must be transparent


• Owned and managed by the Development Team
• Process improvements may affect the whole Scrum
Team and should be jointly owned
• Adapted by the Development Team throughout the
Sprint when work emerges

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 43


What Goes in a Sprint Backlog?

• The selected Product Backlog items (“forecast”)


for the Sprint by the Development Team in
collaboration with the Product Owner
• A plan, often a list of tasks, to deliver the Product
Backlog items against the Sprint Goal
• At least one high priority process improvement
identified in the previous Retrospective

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 44


Exercise

Scrum boards are often used for Sprint Backlog visualization


Visualize your
• Only work for the current Sprint is shown
Sprint Backlog • ‘PBI’ column isn’t a place to store your Product Backlog
• Change the design as you see fit
• Include a way of tracking your high priority process
improvement

10
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 45


Increment

• The Increment is the sum of all the Product


Backlog items completed during the Sprint
• The product is the sum of all Increments
• Is usable and it works
• Is potentially releasable
• Must be DONE
• As per Scrum Team standards
• With no work remaining

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 46


Events: Each One Has a Specific Purpose

• From: Product Backlog


Sprint Planning • To: Forecast, Sprint Goal, Sprint Backlog

• From: Daily Progress


Daily Scrum • To: Updated Daily Plan

• From: Sprint, Increment


Sprint Review • To: Updated Product Backlog

• From: Past Sprint


Sprint Retrospective • Improvements For Next Sprint

• Container Event
Sprint • 30 Days, or less, in duration

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 47


Sprint

• A container for all activities and the


other Scrum events
• Focus is on developing activities
• Starts with Sprint Planning
• Ends with Sprint Retrospective
• 30 days or less to enable regular
feedback

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 48


Sprint Planning

• Product Backlog is inspected


• A Sprint Goal is created (Why)
• Sprint Backlog is created (What and How)
• The entire Scrum Team attends

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 49


Sprint Goal

An objective to be • Through the implementation of the PBIs selected in Sprint


Planning
met in the Sprint • Providing guidance to the Development Team

Allows flexibility in
delivering the • Allows wiggle room for exact implementation of PBIs
Increment

Is fixed throughout • As the Development Team works, it keeps this goal in mind
• The Development Team inspects and adapts their plan to
the Sprint meet the Sprint Goal in every Daily Scrum

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 50


Some Sprint Goals

Make the application run Automatically clear a


on SQL Server in addition default insurance case
to Oracle using the new OCR system

Deliver a minimal set of Increase find accuracy of


administration features misspelled search terms

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 51


Daily Scrum
• An opportunity for the
By the Development Team to:
• Inspect progress toward the Sprint
Development Goal
Team, • Inspect how progress is trending
toward completing work in the
for the Sprint Backlog
Development • Create a plan for the next 24 hours
• Optimize collaboration and
Team performance
• 15 minute daily meeting
• Same time and place
v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 52
Sprint Review

• The product Increment is inspected with the


stakeholders (customer, marketing, sales, …)
• Stakeholders are encouraged to provide feedback
and to collaborate
• The Product Backlog is updated upon the new insights

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 53


Exercise

What Work is Part In addition to creating software, what other


of Product kinds of work are included in product
Development? development?

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 54


Exercise

Defining Done Only completed features may be shown at Sprint


Review. How will your team know what may be
shown in the next Sprint Review here in class?

Post a simple definition of “Done” for your


team so that all items shown in Sprint Review
are known to meet a baseline expectation of
quality and completeness.

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 55


Sprint Retrospective

• The Scrum Team discusses


• What went well in the Sprint
• What could be improved
• What will we commit to improve in the next Sprint

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 56


TAKE • Scrum implements empiricism in software
development
AWAY • Every Scrum role (3) has a clear
The Scrum accountability
Framework (1)
• The Scrum artifacts (3) provide transparent
information
• All Scrum events (5) serve inspection,
adaptation and transparency

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 57


Suggested Reading

“The Scrum Guide” (Ken “Scrum – A Pocket Guide” • “Scrum and XP from the
Schwaber, Jeff Sutherland) (Gunther Verheyen) trenches” (Henrik Kniberg)

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 58


“There is nothing so annoying as to have two people
talking when you’re busy interrupting.”
- Mark Twain

5
Sprint Two

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 59


The PO has collected the new requirements.
Sprint 2
• Plan the Sprint (10 min)
• Build an Increment of product (30 min)
• Review the Increment (15 min)
• Hold a retrospective on how the work went (10 min)
Case Study – Animal Website
• Debrief with the class (5 min)

70
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 60


6
The Scrum Framework (2)

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 63


Who the Product Owner is

• Defines features and functionality


• The level of detail provided will vary
• Some Product Owners will work closer to implementation details than
others
• Has the final word on the content and the ordering of the Product
Backlog
• Not the Development Team’s assistant
• May have the Development Team manage Product Backlog items
• Needs to spend as much time with the Development Team as needed

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 64


The Development Team

• Composition is constant throughout a Sprint


• Typically has 3-9 members with the sweet spot around 6
• May have partially allocated members
• Often considered an impediment
• E.g. Database Administrators, User Interface Design experts,
Technical Writers

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 65


The Development Team

• Non sequential execution is key


• Everyone pitches in regardless of individual skill specialty
• The Development Team is held to account as a unit

Requirements

Design

Code

Test

Sprint n-1 Sprint n Sprint n+1

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 66


The Scrum Master – A Servant-leader, Management Position

• Managing the use and adoption of Scrum by the Scrum Team and
within the organization
• Serving and coaching the Scrum Team
• Embodying agility for all to see

As possible within the culture of the


organization and within the Scrum Master’s
organizational and political skills, and patience.

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 67


Scrum Master

• Guides and cares for the Scrum Team


• Understanding of Scrum Values, theory,
practices, and rules
• Facilitates self-organization
• Does NOT “drive” the team by giving
tasks or by telling what to do
• Removes impediments to the
Development Team’s success that
they are unable to remove themselves

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 68


Product Backlog Items

• Each Product Backlog item is executable within a Sprint


• Best to have several in a Sprint
• Each one is ideally discrete without dependencies

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 69


Exercise

Events: Each One Event Inspection Adaptation


Has A Specific Sprint Planning A?
Sprint Goal, Forecast,
Sprint Backlog
Purpose
Progress toward Sprint
Daily Scrum B?
Goal
PURPOSE Increment, Sprint,
Explore the role of the Scrum Sprint Review C?
Product Backlog
elements in empiricism

Actionable and committed


Sprint Retrospective D?
improvements

5
minutes
Question: What is missing? How is it transparent? Who
should attend? What’s the time-box?

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 70


The Sprint

• Best to have consistent durations


• Starts right after the previous one
• Scope is reviewed constantly throughout
• Between Development Team and Product Owner
• This recognizes uncertainty even within the Sprint
• There are no special Sprints
• No Sprint 0, Design Sprints, Testing Sprints, Hardening or Planning
Sprints

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 71


Time-boxes

• A time-box is the maximum


amount of time allotted to
achieving the purpose of an event
• Helps maintain focus
• Helps reduce waste

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 72


Scrum Event Time-boxes (at most)

Event 30 Days 3 Weeks 2 Weeks 1 Week

Less than 8 hours Less than 8 hours Less than 8 hours


Sprint Planning 8 hours
(~6 hours) (~4 hours) (~2 hours)

Daily Scrum 15 minutes

Less than 4 hours Less than 4 hours Less than 4 hours


Sprint Review 4 hours
(~3 hours) (~2 hours) (~1 hour)

Sprint Less than 3 hours Less than 3 hours Less than 3 hours
3 hours
Retrospective (~2 hours 15 mins) (~1 hour 30 mins) (~45 mins)

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 73


Exercise

Sprint Planning List the activities and responsibilities for


each Scrum role during the Sprint
Planning event:

• Product Owner
• Development Team
• Scrum Master

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 74


Sprint Planning Event Flow

Definition of Development Team Retrospective


Product Backlog
“Done” (Velocity + Capacity) Commitments

1 What
Analyze, evaluate and select
Product Backlog Items for Sprint.
Sprint Goal gives direction
2 How
Decompose into actionable plan
Enough work is decomposed

Sprint Goal + Sprint Backlog (Forecast + Plan)

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 75


Why a Daily Scrum?

• Share commitments
• Identify impediments
• Create focus
• Increase and maintain
situational awareness

Development Teams may


have many ways of
conducting a Daily Scrum to A Daily Scrum in Microsoft Patterns and Practices
increase collaboration
v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 76
Sprint Review Event

• A collaborative working session


• Not a demo
• The Scrum Team shows the Increment
• Feedback is heard from all present
• Feedback used to guide the next Increment
• Working software, no slides
• The full Scrum Team participates
• Complemented by the stakeholders

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 77


Mechanics of Sprint Review

Development Team
Product Owner Shares Everyone
Shares
•What was done •The actual Increment •Provides and hears
•What wasn’t done of software feedback
•State of the Product •What happened in
Backlog the Sprint
•Projections of likely •How problems were
release targets addressed and the
effect on the
Increment

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 78


Flow of the Sprint Review Event

This is a
collaborative Product Current Business
Sprint Backlog Increment Conditions
working session,
not a
demonstration. Review, discover & rearrange info

Updated Product Backlog


v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 79
Sprint Retrospective

• A discussion of:
• The Scrum process
• Scrum Team member behaviors
• Tools used and needed
• Expanding the definition of “Done”
• To find actionable improvements
• The Scrum Team can enact next Sprint
• To adapt common practices and techniques
• To increase the DoD

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 80


The Sprint Retrospective
Kaizen –
Continuous • The Scrum Team’s opportunity to improve
Improvement • After every Sprint Review
• Full Scrum Team participates
• Scrum Master
• Product Owner
• Development Team

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 81


The Retrospective Prime Directive

“Regardless of what we discover, we understand and truly believe


that everyone did the best job they could, given what they knew at
the time, their skills and abilities, the resources available, and the
situation at hand.”

- Norm Kerth,
Project Retrospectives: A Handbook for Team Reviews

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 82


Anti-Pattern: Poor Use of Retrospectives

Beware gripe sessions


rather than learning
sessions

What worked?
What didn’t work?
What will we commit to
do in the next Sprint?

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 83


A Typical Sprint Retrospective Model

What worked well? What could be improved?

What will we commit to


doing in the next Sprint?

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 84


Retrospective Commitments for the Next Sprint

Answer: What we committed to for the


Sprint #
next Sprint
What will your team do in the
next Sprint? All Increments shown in Sprint
3
Review build via automated build
• Keep these visible to all
• Keep a growing list of them New features will have
4
corresponding unit tests
• Watch DoD grow over time
Tests will run as part of the
5
automated build process

All increments release with a


6
functional installer

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 85


Ask Questions Like These Regularly

• Is our DoD increasing in scope?


• Is our quality improving?
• Are we learning more from each other?
• Are we hiding or ignoring anything?

These questions make a


And for each answer
nice addendum discussion
why or why not.
to Sprint Retrospectives

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 86


Product Backlog Refinement

• Refining means
• Planning the PBL to an actionable level of detail
• Maintaining a Rolling Backlog Projection
• Plan 10% of the Sprint capacity of the Development Team to be
spent on refining the Product Backlog
• Top ordered Product Backlog items are well understood and easily
selected in Sprint Planning
➔They are ‘Ready’

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 87


Definition of the Definition of Done (DoD)

• The definition of “Done” is a


shared understanding of
completeness
• Must be universally understood
and agreed upon for
transparency
• The common denominator of
quality for the product

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 88


DoD Tips

• In general the DoD is for the Increment and all Product Backlog
items
• Checklists for definition of “Done” at various levels and
checkpoints can be helpful
• Visit definition of “Done” in each Retrospective

If the development organization does not have a common definition


of “Done” for that product, product family, or system (to reflect
product fit for purpose), it defaults to the Development Team to
define and own.

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 89


Monitoring Sprint Progress

• Measurement is for the Development Team


• No one else
• Part of self-managing the Sprint’s work
• Measurement is an indication of:
• Progress in the Sprint
• When scope should be reviewed with the Product Owner

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 90


Sprint Burndown Chart

140

120

100

80

60

40

20

0
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 91


Sprint Progress Monitoring Cautions

• Can be easily misused


• To micromanage the Development Team
• To demonstrate false progress
• May change abruptly when
• New work is added or removed during the Sprint
• Scope is reviewed with the Product Owner
• New things are learned about the work of the Sprint

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 92


Velocity

A measure of Product Backlog items delivered per Sprint


• Used by the Development Team to gauge how much work to pull in
a Sprint Planning event
• Used by the Product Owner to provide forecasts on Product Backlog
level

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 93


Velocity

30

25
Functionality Delivered

20

15

10

0
1 2 3 4 5 6 7 8 9
Sprint

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 94


Exercise

Considering the A Development Team’s velocity may vary


Nature of Velocity dramatically from one Sprint to the next.

In your team determine whether this


is good or bad

3
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 95


Exercise

What Will The Development Team has been together for


several months. You are the Scrum Master. Velocity
You Do? is fairly stable.
The CTO asks why, “What are you doing to help the
team improve their velocity?”

What is your response?

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 96


TAKE • The Scrum artifacts provide transparent
information
AWAY • All Scrum events are an opportunity for inspection
and adaptation
The Scrum
Framework (2)

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 97


Suggested Reading
“Agile Project Management with Scrum” (Ken Schwaber)

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 98


7
Mastering Scrum

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 99


Self-Organization

• A structure or pattern appears in a system


without a central authority or external
The skill is using element imposing it through planning
self-organizing • It is a primal behavior in nature
teams to the • Swarms
organization’s • Flocks
advantage • Herds
• Scrum exploits this
• You have seen it in this class

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 100


Productive Self-Organization

• Requires skill
• In the domain at hand
• In the constraints of the framework
• In the software development craft
• Skills needed in software teams using Scrum
• Scrum itself • Levels of testing
• The business domain • Mastery of development tools
• Useful technologies • Build and deploy automation
• Practices of software craftsmanship • Emerging architecture or design
• The science of user experience • Many, many more
• Languages and frameworks

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 101


Exercise

Self-Organization Each team consider:


What does it mean for a
Development Team to be self-
organizing?

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 102


Self-Organizing Scrum Development Teams

• Select the work to complete


• Determine how best to meet requirements
• Get help with external disruptions (Impediments)
• Select their own Scrum Master

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 103


Exercise

What Does A Development Team new to Scrum is trying to


create their first definition of “Done” and create a
Scrum Require? loose plan for their first Sprint. Many topics are
being discussed.

They want to know which of these Scrum


requires? What is your guidance?
• TDD • Backlog Refinement
• Continuous Integration • Planning Poker
• Daily Scrum • Sprint Retrospective

3
minutes


Loose Coupling
User Acceptance Testing


Demo to customer
Dedicated QA resources
• Sprint Planning • Product Backlog

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 104


2 Parts of the Scrum Discussion

PEOPLE PRACTICES ENGINEERING PRACTICES

• Planning • Design
• Empiricism • Coding
• Collaboration • Testing
• Self-Organization • Automation
• Leadership • Deploying
• Communication • User Experience
• Transparency • Emergent Architecture

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 105


Using Self-Organizing Teams Well

• Provide a clear goal and


Purpose
desired outcomes (Sprint
Goal)
• Provide a framework within
which the team operates
• Scrum rules
• Engineering practices
Self-
• Team-evolved principles, norms,
Organizing
and culture Principles
Team Challenge,
Pressure
(Scrum
• Sprint challenge and pressure rules)
(Sprint
time-box)

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 106


Self-Organizing Development Teams

The Development Team determines


• Who does what & when
• Who is needed on the team and not
• When it needs help resolving impediments
• Needed process improvements
• Technology practices
• Release and maintenance practices
• Their own Scrum Master

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 107


Cross-Functional People

• In a multi-disciplinary
Development Team of
appropriate size, people need
to move beyond their areas of
specialization
• Task pairing and sharing grows
everyone
• Focus shifts from fulfillment of
individual duties to the overall
success of the team

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 108


Exercise

Handling You are the Scrum Master. The Development


Impediments Team reports having 2 impediments:
• Network operations is late delivering a
needed server
• One of the developers refuses to attend the
Daily Scrum

What do you do?

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 109


Impediments

Anything that:
• Impedes or slows a team’s progress
And
The Scrum
Master’s bread • Cannot be resolved by the team internally
and butter

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 110


Always Be Ready to Release

• The only requirement is that at the end of the Sprint there is an


increment that is “Done” and must be in useable condition
regardless of whether the Product Owner decides to actually
release it
• Can release whenever a Product Backlog item is “Done”
• Practices such as Continuous Delivery can be used with Scrum
• Utilizing DevOps practices and principles will help

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 111


TAKE • Self-organization, what it is and how it is
employed in Scrum
AWAY
Mastering Scrum

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 112


Suggested Reading

“The New New Product Development Game”


(Takeuchi, Nonaka)

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 113


8
Sprint Three

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 114


The PO has collected the new requirements.
Sprint 3
• Plan the Sprint (10 min)
• Build an Increment of product (30 min)
• Review the Increment (15 min)
• Hold a retrospective on how the work went (10 min)
Case Study – Animal Website
• Debrief the class (5 min)

70
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 115


Anti-Pattern: The Hero Developer

• High functioning organizations do


not need heroes
• Heroes almost always ignore
quality: Tests, Documentation,
Automation
• Needing a hero means the overall
system is fundamentally broken
• Heroes resist Scrum as focus moves
• To the team
• Away from the individual

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 117


Anti-Pattern: Absent Product Owner (APOP)

• Very common and very


destructive
• Increases wait time and
creates waste
• Feature decisions are
often decided by those
least appropriate to do so

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 118


“In life, as in football, you won’t go far unless you
know where the goalposts are.”
- Arnold H. Glasgow

9
Planning With Scrum

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 119


Scrum Planning

• Plan constantly, not just in the beginning


• Planning is an activity, not a document
• Recognize, embrace, and support change rather than trying to
control it

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 120


Planning Horizons
Owned by the
Product Product Owner 2 Backlogs
Backlog 2 Horizons
to plan
Owned by the against
Scrum Team Release
Plan
Owned by the
Sprint Development Team
Backlog

Daily
Plan

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 121


Backlog Accuracy and Item Detail

Vague Understood Estimated PBIs Tasks

This
Sprint +1 Sprint
Other Next Sprint +2
Backlog Release
Items
Sprint
Planning

Refinement
Refinement

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 122


Estimating With Groups

Group derived estimates include a wider set of experiences and


perspectives than estimates by individuals.

Together, we are
smarter than any
one of us.

- Japanese proverb

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 123


Myth

With more analysis


and effort, estimates
get significantly
more accurate.

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 124


Exercise

Estimating the A Development Team refuses to estimate Feature X


because no one on the team has any experience
Unknown with the technology to be used.
The Product Owner proposes the following
Product Backlog Item. What is your advice to
the Development Team?

Learn how the new


technology works and
3 understand any relevant
design implications to
minutes Feature X.

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 125


Exercise

Estimating the A Development Team is uncomfortable estimating


Feature Z because no one on the team fully
Unknown understands the architecture needed for the
feature. There is no need for a new technology, but
a new technique or design pattern.
The Product Owner proposes the following
Product Backlog Item. What is your advice to
the Development Team?

3
minutes
Experiment with options
for implementing
Feature Z.

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 126


Story Points

• Based on size, effort and • Points are additive


complexity, not duration • Non-linear in progression
• Numerically relative to each other • Use units that help planning
• Different for each team of • 1, 2, 3, 5, 8, 13, 21
estimators • 1, 2, 4, 8, 16, 32

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 127


Planning Poker Rules

• Each Developer has a deck of estimation cards


• Customer/Product Owner reads a story and it is discussed briefly
• Each Developer individually selects a card that is his or her
estimate
• Cards are turned over so all can see them (simultaneously
• Discuss the differences (especially outliers)
• Re-estimate until estimates converge

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 128


1 2 3 5 8 13 21 34 55
Planning Poker

Homer
13
Get ready to go
on vacation

5
Lisa
v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 129
1 2 3 5 8 13 21 34 55
Planning Poker

Homer
13
Get ready to go
on vacation

5
Lisa
v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 130
1 2 3 5 8 13 21 34 55
Planning Poker

Homer
8
Get ready to go
on vacation

5
Lisa
v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 131
Exercise

Create a deck of cards as follows:


Make Your
• 1, 2, 3, 5, 8, 13, 21
Decks • ? = I still have questions
• ∞ = Too big to estimate

* Note: the above sequence uses the actual


Fibonacci sequence

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 132


Exercise

Planning Poker • Choose 3-5 PBIs of varying size your team has
already delivered.
1
• Choose 1 of medium size and label it as a 5.
• Estimate the other completed PBIs.
• Use the estimated items as a comparison point to
the items you are estimating.

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 133


Exercise

Planning Poker • Using the completed and estimated PBIs for


reference, estimate PBIs not yet worked on.
2
• Estimate 3-5 PBIs.

10
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 134


Product Backlog Item Attributes

Title: ...
As a . . .
I want . . .
So that . . .
Development Team
Alpha
Scenario: ...
Given . . .
Business Value - 13
When . . . Effort Estimate - 5
Then . . . ROI - 2.6

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 135


Business Value
Money to be earned
• The Product Owner is responsible for this
Clients to be retained • It isn’t always just revenue
Delight to bring to users • Can be estimated or calculated
• MoSCoW
Market share to capture • 1…100
Money to be saved

Improvement to User
Experience

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 136


Ordering the Product Backlog

• Risk
• Identify risk for items in the Backlog
• Do highest risk items first
Ordered in a way • Return on Investment
to maximize • Simple business value ranking system
value delivered • This gives a single number by which to rank
work
• Because the Product Owner says so

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 137


ROI Index Ordering
ROI

• Helps you see value at a glance 5.7

4.8
• Less subjective 4.3

• Not the last word 4.3

• That’s the Product Owner 3.2

• ROI Index is a tool 3.1

2.3

1.7

0.0

.73

.04

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 138


Exercise

When will item At a Sprint Review one of the PRODUCT BACKLOG


stakeholders wants to know Size: 13
“A” likely be when item A is likely to be Size: 21

released? released. Size: 21


Size: 3
How would you deal with this Size: 5

question? Size: 1
Size: 8
• Average Team Velocity = 33 Size: 13
A
• Sprint Length = 2 weeks Size: 3
Size: 89
Size: 13

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 140


Exercise

What is likely to At a Sprint Review one of the PRODUCT BACKLOG


stakeholders wants to know Size: 13
be released in 8 what is likely to be released in Size: 1

Weeks? 8 weeks. Size: 2


Size: 8
How would you deal with this Size: 5

question? ? Size: 13
Size: 3
• Average Team Velocity = 18 Size: 13

• Sprint Length = 2 weeks Size: 5


Size: 8
Size: 2

5
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 141


Monitor Progress Balancing Date or Feature Targets

How likely are PRODUCT BACKLOG


70 we to meet Size: 13
the release date?
60 Size: 1

Cone of Size: 2
50 Uncertainty Size: 8
Story Points

Size: 5
40
Size: 13

30 Size: 3

Size: 13
20
Size: 5

10 Size: 8

Size: 2
0
1 2 3 4 5 6
Sprint

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 142


Two Basic Types of Release Planning

DATE TARGET PLANNING FEATURE TARGET PLANNING

• The product will release on a • The product will release when


specific date specific features are ready

We Must Answer We Must Answer


How much of the backlog will be When will features A, B, and C be
complete by a given date? ready?

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 143


Section Summary

PRODUCT BACKLOG

Release Plan

Sprint Plan

Daily Plan

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 144


TAKE • Product Backlog holds all the work for the Product
• Product Backlog gives transparency
AWAY • Product Backlog is a living artifact
Planning With • Product Backlog holds all information needed for
Scrum forecasting, planning and reporting

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 145


Suggested Reading

“User Stories Applied” (Mike Cohn) “Agile Estimating and Planning” (Mike Cohn)

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 146


10
Sprint Four

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 147


Case Study – Animal Website
Competitor announced new product
Sprint 4

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 149


Scrum Team, prepare to inspect your Product Backlog.
Sprint 4
• Plan the Sprint (10 min)
• Build an Increment of product (30 min)
• Review the Increment (15 min)
• Hold a retrospective on how the work went (10 min)
Case Study – Animal Website
• Debrief with the class (5 min)

70
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 150


11
Getting Started

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 151


Agility Requires Organizational Change

• Today’s culture is finely tuned to produce


current conditions
• Agility is an entirely new state
Culture:
• Culture must change to achieve Agility
“The way we do • Organizational change is a difficult
things here.” multi-step process that requires leadership

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 152


Exercise
Reasons to use or not What is not working for Who can support us and
Getting started use Scrum us now? how?

with Scrum
1 3 5

What will happen if we What changes do we Who needs support from


don’t change? want to see in 6 months? us and how?

2 4 6

20
minutes
• Fill out the canvas for your organizational transformation
• Follow the boxes in order

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 153


Exercise

Agile Transition
Backlog

Create and order a backlog for


your organization’s transition to
agility with Scrum.

15
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 154


Exercise

Refining the Scrum • Who will be the Product Owner for this
Implementation Scrum Implementation Backlog?
Backlog
• Who will work with this Product Owner to
refine this backlog?
• Ideally, 1 person from each team in class
• Plus the highest ranking person in class

2
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 155


Who Fills These Roles and Why?

PRODUCT OWNER

SCRUM MASTER
v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 156
What is a Reasonable DoD For a First Sprint?

• Where is the Increment deployed? By whom?


• What tests accompany it?
• What documentation accompanies it?
• Will bugs known today still be present?

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 157


Product Backlog

• Is there one today?


• If not, when will one exist?
• How and where will the Product
Backlog be managed and made
visible?
• Are the PBIs estimated and
ordered?
• If not, when and where will that occur?
• Who will schedule it?
• How will PBIs be estimated?

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 158


The First Sprint

• How long will Sprints be and why?


• When will the first one begin and end?
• What might be a valid Sprint Goal for your first Sprint?

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 159


Information Radiators

• Where will they be?


• What will they show?

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 160


Who Will Schedule These Events?

• Sprint Planning
• Daily Scrums
• Sprint Review
• Sprint Retrospective

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 161


Refining the Product Backlog

Will you refine the Product Backlog?


• How
• When
• Where

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 162


TAKE • Understanding Scrum helps
• Thinking about Scrum helps
AWAY • Start, inspect, adapt
Getting Started

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 163


“Nothing focuses the mind like a noose.”
- Mark Twain

12
Closing

@ScrumDotOrg v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 164


Three Things You Wanted to Know (Revisit)

• Did we cover what you absolutely wanted to know?


• Did we set some questions aside that we still need to go into?

P
v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 165
Exercise

It’s Your Call I’ve had 2 great days of discovery about Scrum. But,
when I go back to work I still have to deal with many
old ways of working (dates, actuals, predictions).

Identify 3 actionable ideas or improvements


from this class you will try.

10
minutes

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 166


Inspect Your Knowledge – Feedback in 14 Days or Less!

Over the past 2 days, you have learned the importance of inspection,
adaptation, and fast feedback cycles. To reinforce those concepts, if
you attempt the Professional Scrum Master I (PSM I) certification
assessment within 14 days and do not score at least 85%, you will be
granted a 2nd attempt at no further cost.

• Test your basic knowledge of Scrum and learn from immediate feedback by
taking an Open assessment:
www.scrum.org/assessments/open-assessments
• Use the Open assessments to prepare for Level I assessments

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 167


Your Scrum.org Profile

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved


Feedback

Feedback is important, and we take it seriously. Your feedback


helps us to continually inspect and adapt our courses.

Share your feedback on the class you attended at:


www.scrum.org/feedback

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 169


Connect With The Scrum.org Community

Forums Twitter LinkedIn Facebook RSS


Scrum.org @scrumdotorg LinkedIn.com Facebook.com Scrum.org/RSS
/Community /company/Scrum.org /Scrum.org

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 170


Thank You!

v 4.3.1 © 1993 – 2018 Scrum.org All Rights Reserved 171

Das könnte Ihnen auch gefallen