Scrum 1 PDF

Agile & Klaus Bucka-Lassen
Scrum Inc. (Europe)
Scrum
Agile Trainer, Coach & Consultant
Speaker at Agile Conferences
BP
October 9-10
Co-training CSM courses with
Sunbury / London Jeff Sutherland & Joe Justice
© aragost Trifork ag 2017

Sprint 1

3
GOAL

• Imagine this turns out to be the best
course you have ever experienced
• What made it so good? What was the
one thing that made it stand out?
Exercise • Write a tweet (140 characters) in which
you tell your followers what made the
course so good – be specific!

Tweets
These work as a vision for the traininer. It provides him with information
what would make the customers happy. It gives him a sense of direction.

• Understand what agility is;
why, when, and where it is needed
• Learn Scrum basics & establish common
terminology
Goal of • Learn how to start and continuously
improve your Scrum
Training • Learn about pitfalls and typical
impediments
• Provoke, stimulate and create A-Ha’s
• Be provoked & heckled

1
WORKING
AGREEMENT

• Be in the course/workshop
• One discussion at a time
Working • Steer actively (e.g. by
asking questions)
Agreement • Everything written, drawn
and shown will be handed
out as a photo journal

• Course done in multiple 3.5-hour Sprints
• Who is?
Our • the Customer/User
(most important stakeholder)
Scrum • the Product Owner

• the Scrum Master
• the Development Team

• Main responsibility is to maximize the
Efficiency groups learning by improving velocity
• by planning and taking coffee, bio and lunch
break(s) at the right time for the right length
• by removing impediments, things that
Scrum Master handicap the groups ability to learn
Cheat Sheet • by ensuring the working agreement is
adhered to (or changed if necessary): “Don’t
break the rules, change the rules”
• by making the groups progress transparent to
each other (updating the scrum board,
reminding people to put up A-HAs, etc.)

• Main responsibility is to maximize the
Effectiveness groups learning by picking the right things
• by ensuring we are working on the things that
promise the highest ROI, i.e. return (important
learning) on investment (time)
Product Owner • by making this transparent with use of a
Cheat Sheet product backlog
• by constantly being on the lookout for new
high-value and low cost topics. Either topics
which are really important to discuss within
the group or topics that can be easily and
quickly ticked of (low hanging fruits)

• Day 1
• Sprint 1: 10:00 am – 12:30 pm
Four • Sprint 2: 1:30 pm – 5:00 pm
Sprints • Day 2
• Sprint 3: 9:00 am – 12:30 pm
• Sprint 4: 1:30 pm – 5:00 pm

5
TEAM BUILDING

• Introduce yourself to somebody you don’t
know yet (1 min.)
• What do you know about Scrum
• What are you working on
Introductions
• How do you think Scrum could help
• Let her do the same (1 min.)
• Repeat

• Line up by Scrum experience level
• Use the second dimension to spread by
function
• Line Manager
Build
• Project Leader
Teams • Developer
• Build a x-functional team consisting of
experienced and less experienced Scrum
individuals and a variety of roles.

• Dicide on <Team Name>
ToDo Doing Done
• a Product Owner
• a Scrum Master
Define • a Team Name
• Prepare a
Teams team backlog
• Fill it with learning
objectives
(one per sticky note) PO: <Name> SM: <Name>

5
BEST
PROJECT
EVER
• Bring back to memory your
favorite project ever
• Why this project?
Best Project Three reasons (one per sticky)
Ever • 1 minute Reason 3
• Tell about your project (and yourself)

• Explain what made it so great (the three
reasons)

• How did your clients / customers / users
Best Project feel about this project? => Fist-To-Five
Ever • What does this mean? Is there a
relationship?

Best Project • How does this hold up against the agile
manifesto?
Ever

2
AGILE
MANIFESTO

*actually it is „software“ but really should be „product“
• Individuals and Interactions over Processes

and Tools
• Working product* over comprehensive
Agile documentation
Manifesto • Customer collaboration over contract
negotiation
“Plans are worthless,
• Responding to change over following a
planning is plan
everything”
[Eisenhower] “It is not the strongest of the
“Everyone has a plan
species that survives, not the
– until they get most intelligent, but the one most
punched in the face” responsive to change”
[Mike Tyson] [Charles Darwin]
2
AGILE
CONTEXT

Agile
Context

Sprint 1

Sprint 2

6
COMPLICATED
VS. COMPLEX

Complicated
vs. Complex
• Is this the shortest
route from A to B?
• Does the shortest
route interest me?
• Is it the fastest then?
• Why did I drive the
blue then?
↗ Cynefin Framework [Dave Snowden]

Complicated
vs. Complex

What problem • Is the world and your context getting
more complicated or complex?
are you trying • Are we seeing more disruption
to solve? than ever before?

3
HUMAN
KNOT
(COMPLEXITY)

2
BDUF
(BIG DESIGN UP FRONT)

• How did we get here?
Big • Treating all problems like they were
complicated
Design → Enough analysis allows fail-safe-design
Up → Fixing all parameters
→ Perceived certainty
Front
• “We want it …”

„Tell us everything now, or else...”
• Poor communication
(with customer during project, team often working on
assumptions, “Fire and Forget”)
• Bad priorization
• Restrictive response to change
• High risk, high cost
Consequences • Building too much ...
[Standish Group study, XP2002]

7
SCRUM
OVERVIEW

Scrum
• Support the way successful projects have

shown to run
• Practices are simple, but ...
• doing them is not easy, the forces pulling
back into old habits are enormous

Scrum
• 3 Roles
• Product Owner
• Scrum Master
• Development Team
• 5 Events
• The Sprint
• Sprint Planning Great Video
• Daily Scrum
• Sprint Review
• Sprint Retrospective
• 3 Artifacts
• Product Backlog
• Sprint Backlog
• Increment

2
PRODUCT
BACKLOG

• Functional requirements
• Content originates from many sources (all
Product stakeholders, incl. team)
Backlog • Managed by Product Owner
• Visible and transparent to everyone

• Detailed appropriately
A DEEP
• Estimated as necessary
Product • Emergent
Backlog • Prioritized

• Functional requirements are often worded
as User Stories:
As a [Role]
User I want to [Feature]
So that I can [Reason]
Stories
• May start as fairly big and blurry stories
(epics) and are refined and sliced as they
surface the top of the Product Backlog

3
PRODUCT
OWNER

The right things
are done
The things are

done right
Product Owner
Hardly defined
Requirements gathering Somewhat defined

Maximizing ROI
Prioritization
Expectation management
Explaining stories
Status communication
First line of support
Funding
etc.
Refinement
etc.

• Visionary
• Has deep understanding what is of value to
the customers
• Self-confident & motivated
Qualities • Empowered and decisive
and Skills • Good communicator
• Trusted (good working relationship with
team and stakeholders)
• Leader and facilitator

• Probably the most crucial role to staff right
Don’t be • Tough full time job
fooled • Must own the product backlog

• Not empowered
(Lack of guidance, direction and decision making)
• Not available
Common (Collaboration with the team suffers, decision delays)
• Not prepared
Mistakes (Poor preparation work for the next sprint)
• Not trained
(Lack of Scrum knowledge and useful techniques such as user
stories)
There is a strong correlation between a Product Owner who is motivated, trained, available and
empowered ... and a successful product development

Product
Ownership
… a bit like Asteroids Epic
(1979) Story PO
Team & SM
Impediment

3
FOCUS
(MULTITASKING)

Name Inc.
J
Ja
Jas
Jasp
Jaspe
Jasper
• Policy: Never keep customers A
Al
Ali
Alin
Alina
waiting
• Groups of 6-8 people
• One writer
K
Ke
Kev
Kevi
Kevin
•
•
One timer
Customers
N
Ni
Nik
Nikl
Nikla
Niklas
• Rules *
• Timer starts and records M
Mi
Mic
Mich
Micha
Michae
Michael
• Time for 1st complete name
•
• Time for all names
Writer gets first letter from every
P *
Pe
Per
customers name, then the
second letter, then the third,
etc., until all names have been
written down in full

Name Inc.
Jasper *
• Policy: Focus on one customer Alina
at a time!
• Groups of 6-8 people
• One writer
Kevin
•
•
One timer
Customers
Niklas
• Rules
• Timer starts and records Michael
• Time for 1st complete name
•
• Time for all names
Writer gets all letter from the
Per *
first customer, then the second
customer, then the third, etc.,
until all names have been written
down in full

Confirming
Weinberg’s
Results

Gerald Weinberg
100%
90% 20%
80% 40%
70% 60%
Context 60%
75%
50% 100%
Switching 40% 80%
Waste
30% 60%
20% 40%
25%
10%
0%
1 Project 2 Projects 3 Projects 4 Projects 5 Projects
Work Waste

Sprint 2

Sprint 3

3
DEVELOPMENT
TEAM

Challenge or
Opportunity!
• A lot at stake –
possibly the
companies
existence.
• What is the classic
strategy to resolve
issues like that?

Task Force
• What characteristics
distinguishes a Task
Force?
• Small team
• Clear short term objective
• Diversity of skills (often
experts in their respective
field)
• Focused on problem
• Autonomous
• Team is provided the
necessary resources
• Disbanded after mission
accomplished

Dev-Team
Characteristics
• ~ 6 members
+ SM + PO
• Cross-functional
(Team is capable of
doing “everything”)
• Autonomous (self-
organizing)
• Stable & full-time
membership
• T-shaped skills

T-Shaped Skills
Ability Outside
Spezialisation
Spezialisation
Enables Swarming

1
SPRINT
PLANNING

• Cite a theme / goal for the Sprint
(helps the team focus and keep aligned)
Sprint • Achievable subset of Product Backlog
becomes Sprint Backlog
Planning • Product Owner decides which User Stories
make it into the Sprint Backlog; Team
decides how many

• Sprint planning can take less than an hour
• PO: “What is your expected velocity for the
upcoming sprint”
• Team has possibly prepared that number
already (based on history, availability of team
Being members, and other known relevant factors)
• Product Owner takes ready stories* from the
Ready top of his product backlog and moves them to
the Sprint Backlog until capacity is exhausted
is Key • Ready Stories: Discussed and estimated
beforehand in so-called Refinements
(previously known as Groomings)
• The better prepared the Product Owner is,
the shorter the Sprint Planning

2
SPRINT

• Input: Highest priority
product backlog items
{
• Content defined by the
Scrum Team
• Lasts 1-4 weeks
Sprint • Every backlog item from
concept to cash
• Output: Potentially
Shippable Product
Increment

• NO changes by any non-Development
Team Member: 2-way commitment
• Define the length of Sprints such that the
Sprint rule above doesn't hurt too much
Rules • Sprint lengths should be constant over
time to allow for a kind of clock-cycle
• Team members choose their own stories /
tasks (by priority)

2
SCRUM
BOARD

Scrum Board
At the beginning
of the sprint

Scrum Board
After a couple
of days

Scrum Board
In a perfect world

Scrum Board
Warning Sign #1

Scrum Board
Warning Sign #2

Scrum Board
Warning Sign #3

2
DAILY
SCRUM

Daily Scrum
(aka Stand-Up)
• 15 minutes; same time and
place
• Discuss what is holding the team
back from achieving the sprint
goal
• Mention general impediments,
making the team slow
• Don’t use this forum to solve
problems
• Three questions
• How did I help the team to reach
the goal
• How will I help the team to reach
the goal
• What is holding me back from
doing this as efficiently as
possible

DOES YOUR TEAM FEEL LIKE THIS?

1
SCRUM
MASTER

• Minister of the interior
• Does not tell people what to do and when
• Mainly responsible for
The • Enforcing Scrum values and practices
• Maximizing teams efficiency mainly by
Scrum removing impediments that impede flow (e.g.
interruptions, unnecessary bureaucracy and
Master formalism, low degree of automation,
ineffective communication, sub-optimal
process, poor backlog quality, etc.)
• 50% - 100% job

2
SPRINT
REVIEW

Sprint Review
(aka Demo)
• Team presents what it
has accomplished with
an informal demo of the
new features, bug fixes,
etc.
• Participants
• Product Owner &
Stakeholders
• Dev-Team & Scrum
Master
• Everybody else who is
interested
• ~ 1 hour

3
RETROSPECTIVE

• Participants: Team and SM (possibly PO)
• Discuss: What went well, what not. What
do we continue to do, what not. New
experiments?
• Output: Prioritized impediment backlog
Overview (which the Scrum Master owns) &
Action(s)
• 1st good practice: Concentrate on one
impediment at a time (Limited-WIP: 1)
[Scrumming the Scrum]

• Goal
• Inspect the team and their process
• Identify pain points & flow interruptions, prioritize
and update
the impediment backlog accordingly
• Agree on concrete actions - Adapt
• Working agreement (example)
Goal and Rules • Everyone participates & pays attention (no
mobiles, laptops, etc.)
• Be honest, constructive, professional, and
respectful (don’t get personal or start finger
pointing)
• Focus on what's relevant for the team
• Be positive and enthusiastic – you're given the
opportunity to improve!

• Set the stage – Get people to talk. Once they have opened
their mouth, it's much easier for them to participate in the
discussions that will take place during the rest of the
Retrospective.
• Collect data – Do not go into solution mode, but just gather
as much data as possible. It's like brainstorming. Don't limit
people in this phase. No judgements.
• Create insights – Identify problem areas (using the data
Typical from the step before). Agree on which are the most
important challenges (e.g. by dot voting). Then find and
discuss the root cause of the problem (for instance by asking
"Why?" again and again).
Format • Actions – Agree on a hypothesis and an experiment that
proves/disproves this hypothesis actions that might resolve
the problem and agree in particular on one action that will
be done during the next sprint. By default, the Scrum
Master is responsible for this action (which doesn't mean he
can't delegate it to somebody else).
• Close Retrospective – Ask for other feedback from the
team. Open questions. Ways to improve the Retrospective,
etc. Thank the team for participating.

• Starfish
• Timeline
• Speed Boat
• Mad, Sad, Glad
Techniques
• Cool Wall
for Data • … and many many more. Google for
Gathering different techniques (e.g.
retrospectivewiki.org) and experiment with
what works best for you – never let the
retrospectives get boring.

Scrum 1 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Scrum 1 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Agile & Klaus Bucka-Lassen

Scrum Inc. (Europe)

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

Scrum • the Product Owner

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

• Tell about your project (and yourself)

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

• Individuals and Interactions over Processes

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

↗ Cynefin Framework [Dave Snowden]

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

[Standish Group study, XP2002]

© aragost Trifork ag 2017

© aragost Trifork ag 2017

• Support the way successful projects have

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

The things are

Requirements gathering Somewhat defined

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

Switching 40% 80%

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017

© aragost Trifork ag 2017