SCRUM MASTER TRAINING - Agile Lean House

© 1993-2012 Jeff Sutherland

SCRUM MASTER TRAINING

With help from Citrix Online, Google, Yahoo, Microsoft, IBM, Oracle, MySpace, Adobe, GE, Siemens, Disney Animation, BellSouth, Nortel, Alcatel-Lucent, EMC, GSI Commerce, Ulticom, Palm, St. Jude Medical, DigiChart,

RosettaStone, Healthwise, Sony/Ericsson, Accenture, Trifork, Systematic Software Engineering, Exigen Services, SirsiDynix, Softhouse, Philips, Barclays Global Investors, Constant Contact, Wellogic, Inova Solutions, Medco, Saxo

Bank, Xebia, Insight.com, SolutionsIQ, Crisp, Johns Hopkins Applied Physics Laboratory, Unitarian Universalist Association, Motley Fool, Planon, FinnTech, OpenView Venture Partners, Jyske Bank, BEC, Camp Scrum, DotWay AB, Ultimate Software, Scrum Training Institute, AtTask, Intronis, Version One, OpenView Labs, Central Desktop, Open-E, Zmags, eEye, Reality Digital, DST, Booz Allen Hamilton, Scrum Alliance, Fortis, DIPS, Program UtVikling, Sulake,

TietoEnator, Gilb.com, WebGuide Partner, Emergn, NSB (Norwegian Railway), Danske Bank, Pegasystems, Wake Forest University, The Economist, iContact, Avaya, Kanban Marketing, accelare, Tam Tam, Telefonica/O2, iSense/

Prowareness, AgileDigm, Highbridge Capital Management, Wells Fargo Bank, Deutsche Bank, Hansenet/Alice, GlobalConnect, U.S. Department of Defense, Agile Lean Training, EvolveBeyond, Good Agile, Océ, aragostTRIFORK, Harvard Business School, Schuberg Philis, ABN/AMRO Bank, Acme Packet, Prognosis, Markem-Imaje International,

Sonos, Mevion, UPC Cablecom, Niko, Autodesk, First Line Software, SCRUMevents, UPC Cablecom, NIKO, CMS-BOCO, BottomLine

436,638 Scrum jobs in the United States, 139 in Switzerland

1


Biographical Sketch - Jeff Sutherland• 1960-1975 - West Point, Fighter Pilot, U.S. Air

Force• 100 missions over North Vietnam F4 Phantom

• 1973-1986 - Univ. Colorado School of Medicine• Asst. Prof. Radiology, Biometrics, and Preventive Medicine

• Complex adaptive systems research, mathematical simulations of cancer cell formation

• 1983-2008 - VP/CTO/CEO 10 technology companies, Agile coach to 21 startups• 1983-1993 prototyping new development processes

• 1993 created first Scrum, now the leading software development methodology

• 1996-2008 CTO IDX (GE Healthcare) and PatientKeeper

• 2006-present Senior Advisor, OpenView Ventures

• 2008-present Chairman Scrum Foundation

• 2006-present CEO Scrum Inc.

2

© 2012

Scrum In

c.

3

Laura Althof

Executive Director, Scrum Inc.Laura Althoff oversees client relations, coaches a broad range of companies, and leads workshops focused on Agile Leadership for management. She is deeply involved with organizational transformation and keenly aware of both the professional, personal, and structural challenges facing companies who want to move to an Agile framework.

Prior to joining Scrum Inc., she spent a decade and a half as a transformational consultant helping leadership teams in a variety of private industries, as well as elite universities and national arts institutions. She sees her focus as helping teams and leadership define both their vision for change and the resources needed to successfully execute it. Laura is a trained mediator, licensed clinical social worker, and a graduate of the Agile Coaching Institute.

Christine Hegarty

Business Development, Scrum Inc.After working in several organizations that practiced traditional management methods, Christine knew there had to be a better way. She looked for companies that cared about efficiency, process improvement, eliminating waste and treating people right. That search led her to Scrum. Christine believes so strongly in the power of the Scrum principles that she’s dedicated her career to helping organizations apply them and gain tremendous benefits. Her role includes client outreach, development and marketing.

3


Introductions

• Pair exercise• Line exercise• Self-organization exercise• Team name, learning objectives• Build a Scrum board

• Prioritized backlog• Three columns - Do, Doing, Done

4


Course Objectives• Show how Scrum is a disruptive technology

than can achieve 5-10x velocity and quality giving the Product Owner the ability to dominate the competition (internally or externally).

• Show how Scrum is a risk avoidance strategy that can achieve extraordinary quality with hyperproductive velocity, excellence in design and user experience, while improving working life for the team.

• Show how Scrum can be used in any environment to achieve these objectives.

• Those not interested in these goals should stick to waterfall.

5


Agenda - Sprint 1• Sprint 1 - Scrum Origins and Practice

• Intro (1)• Team Learning Backlog (1)• Scrum Origins (2) • Airplane Game (2)• Agile Manifesto (1)• Shu Ha Ri (1)• Scrum Framework (2)• Complex Systems (1)

• Sprint 2 - Starter Kit for a Scrum Master• Sprint 3 - Planning & Estimation• Sprint 4 - Coaching Sessions & Review

Breaks 10:20 11:20Lunch 12:30

6


Agenda - Sprint 2• Sprint 1 - Scrum Origins and Practice• Sprint 2 - Starter Kit for a Scrum Master

• Understand the Job - Project Manager Exercise (1)• Run a Lean Scrum (2)• Avoid Multitasking: First Things First (1)• Handle Interrupts (1)• Deal with Emergencies (1)• Improve Flow - Constraint theory (1)• Identify Bottlenecks - Value Stream Mapping (1)• Remove Major Impediments - A3 exercise (2)• Scrum the Scrum (1)

• Sprint 3 - Planning & Estimation• Sprint 4 - Class Backlog & Review

7


Agenda - Sprint 3• Sprint 1 - Scrum Origins and Practice• Sprint 2 - Starter Kit for a Scrum Master• Sprint 3 - Planning & Estimation

• A3 Review (1)• Daily Meeting (1)• Scrum of Scrums (1)• Scrum Board (1)• Retrospective (1)• User Stories (1)• Create User Stories (1)• Failed Scrum (1)• Scrum Estimation (1)• Product Backlog Refinement (1)• Acceptance Tests (1)• Release Planning (1)

• Sprint 4 - Coaching Sessions and Review

Nice to have* Money for nothing* Velocity* Technical Debt

8


Agenda - Sprint 4• Sprint 1 - Scrum Origins and Practice• Sprint 2 - Identify and Remove Impediments• Sprint 3 - Planning & Estimation• Sprint 4 - Advanced Topics and Review

• Scrum Coaching Sessions (4)• Management, Advanced Topics• Product Owner• ScrumMaster and Team

• XP Game (4)• Dan Pink Video (1)• Certification/Handouts/Evaluations (1)

9

© 2011 Scrum Inc.

As a Scrum Master I need to understand How Scrum Was Createdin order to implement it well

10


Ikujiro Nonaka

The Japanese view Scrum as:•A way of doing•A way of being•A way of life

Sutherland, Kenji, Nonaka - Tokyo, Jan 2011

11


Scrum team characteristics• Scrum formation

• Autonomy• Transcendence• Cross-fertilization

• Moving the Scrum downfield• Built-in instability• Self-organizing project teams• Overlapping development phases• “Multilearning”• Subtle control• Organizational transfer of learning

12


13


Lean Enterprise Institute - Steve Bell

ProductCreation

ProductionTechniques

Scrum Lean

14


Product Creation (Scrum = Lean)• When Takeuchi and Nonaka studied high

performing companies like Toyota and Honda they see cross-functional teams that:• are autonomous• are motivated by transcendent purpose• achieve mastery through cross fertilization

• Allan Ward looking at the same teams saw:• Entrepreneurial System Designer (ESD) - the

Scrum Product Owner• Teams of Responsible Experts - the Scrum team

• Set Based Concurrent Engineering - used by the first Scrum team and companies like Apple

• Cadence, Pull, and Flow - Scrum sprint, self-management of work, and velocity

15


Solution to the global financial crisis“The Wise Leader implements Scrum.” Takeuchi & Nonaka

• Idealistic and pragmatic• Based on transparency, trust, community• Managers become leaders• Innovation accelerates• Workplace is transformed• Common good is achieved

16


Lean Implications for Initial Scrum Implementation: Womack on Pull Systems

First visible effect of converting from departments and batches to product teams and flow

• Product development time cut by 50%• 75% reduction in order processing• 90% in physical production• If you can’t quickly do this you are doing

something wrong.

17


Scrum and Lean

18


Scrum Exercise

19


The Basic Scrum Cycle

Build

Inspect

Adapt

Plan

3 minutes

1 minutes

2 minutes

20


One Person, One Fold

21


Product Owner Tests

22


How to Play the Game• Goal: See how good your team can get at making many airplanes

– Each airplane must be made from ¼ of a sheet of Letter/A4-sized paper– Each team member may only do 1 “fold” of the paper at a time. You must

then pass the airplane to another team member to do the next fold.– Planes must have a blunt tip (so no injury if hit in the eye)

• Each airplane must tested and shown to fly 3 meters in the testing area. – Planes may only be tested once; if it fails, it must be discarded.– Only successfully tested planes count towards your goal.– Work in progress (partially folded airplanes) must be discarded at the end of

each Sprint.• Teams are responsible for self-organizing, and deciding among themselves how to

manage the work, assign roles, etc.

23

© 2011 Scrum Inc.

As a Scrum Master I need to understand the Agile Manifesto

in order to implement Scrum

24


Agile Manifestowww.agilemanifesto.org

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

25


Scrum is easy to understand but hard to implement• A systematic approach to implementing

Scrum will give you the most benefit fastest for the least effort.

• The Shu Ha Ri concept from the martial arts can help.

26


AikidoThe Way in Harmony with the Spirit

27


Making the Most of your Scrum

• Shu state• ScrumMaster sets up process as in the Scrum

Guide.• Team has a known velocity at a sustainable

pace• Retrospective is used to enhance performance

28


ScrumMaster in Ha State

• Team has software done with all features tested and no bugs at the end of a sprint.

• Product owner has ready backlog at beginning of the sprint (good user stories)

• Team has data showing velocity and quality has at least doubled.

• Team is positioned to work towards hyperproductivity, the design goal of Scrum

29


Team of One in Ri State

• Team needs to be hyperproductive.• But what does a great ScrumMaster do?

http://www.youtube.com/watch?v=Hzgzim5m7oU

30



© 2011 Scrum Inc.

What is Scrum?

31

32

© Copyright Allianz Global Investors AG 2012

Scrum Framework

1

33


Scrum Framework

Scrum

Ceremonies

Daily Scrum

Team

ScrumMaster

Sprint Review

Sprint Backlog RolesSocial

Objects

Sprint Planning

Make Work

Visible

Product Backlog

Retrospect-ive

Product Owner

Scrum BoardBurndown ChartPointsVelocity

DoneReady Kaizen

Product Backlog

Refinement

34


Scrum Framework in 30 seconds• A product owner creates a prioritized wish list called a product backlog.• During sprint planning, the team pulls a small chunk from the top of that wishlist, a

sprint backlog, and decides how to implement those pieces.• The team has a certain amount of time, a sprint, to complete its work - usually two to

four weeks - but meets each day to assess its progress (daily scrum).• Along the way, the ScrumMaster keeps the team focused on its goal.• At the end of the sprint, the work should be potentially shippable, as in ready to hand

to a customer, put on a store shelf, or show to a stakeholder.• The sprint ends with a sprint review and retrospective.• As the next sprint begins, the team chooses another chunk of the product backlog and

begins working again.

35


Scrum has Three Roles• Product Owner:

• Define and prioritize the features of the Product Backlog• Decide on release date and content• Responsible for the profitability of the product (ROI)

• ScrumMaster• Facilitates the Scrum process and Team self-organization • Removes obstacles and shields the team from interference

• Responsible for improving performance of the team

• Team• cross-functional (incl. testing)• self-organizing/-managing group of individuals, has autonomy

regarding how to achieve its commitments • typically 3-9 people

36


Scrum has Four Meetings• Sprint Planning

• Product Backlog must be READY before this meeting

• Daily Scrum• Self-organize to improve perfomance

• Sprint Review• Decide what is DONE. That determines

velocity.• Retrospective

• Identify the top process improvement and put in the backlog for the next sprint

37


Scrum Makes Work Visible

• Product Backlog• Sprint Backlog• Scrum Board• Burndown Chart

• Show work remaining• Velocity

38


Product Backlog(Features)

Product Owner

Sprint Backlog(Stories)

24 hrs

Sprint1-4 Weeks

Sprint Review

Sprint Retrospective

Product BacklogGrooming

Daily Standup

How Scrum Works

Sprint Planning

PO

IncrementalProduct Release

PO - Product OwnerSM - ScrumMasterT - TeamC - Customer

SM

T

Input from End-Users,

Customers, Team and Other

Stakeholders

SMT T T T T

Customer-Ready Product Increment

TSM

PO

T

SMPOC

TSM

PO

Product Owner

PO

TPO

KAIZENPROC

ESS E

FFICENCY IMPROVEMEN

TS

1

2 3 8 9

45

6

7

Feedback Loop to PO

Feedback Loop to PO

The Product Owner creates a working vision of the end product defined as a set of prioritized features in the Product Backlog.

The highest priority features from the Product Backlog are pulled into the Sprint Backlog.

At Sprint Planning, the team pulls top priority stories from the Sprint Backlog into the current Sprint, makes final refinements and kicks off the Sprint.

Each day, the team meets and answers: What did I do yesterday?What do I plan to do today?What impediments are in my way?

During the Sprint, the team grooms the Product Backlog and refines the definition of features so that they are ready to be pulled into a future Sprint.

At Sprint Review, the team demos features completed during that Sprint and collects feedback to update remaining features in the Product Backlog.

The Scrum Master facilitates a Retrospec-tive that identifies process improvements to accelerate the team in the next sprint.

Each Sprint results in a customer-ready product increment.

The team repeats the Sprint cycle until the Product Owner decides to release the product.

1

2

3

4

5

6

7

8

9

39

© 2011 Scrum Inc.

As a Scrum Master I need to understand Complex Adaptive Systems


40


Complex Adaptive Systems Theory

NeverUpset

TensionSour

EarlySupportive

FunEcstatic

BetterUnsupportive

MediocreHappier

Chaos

Read

y Rea

dy D

one D

one

Not Ready

Not Done35%improvement

300-400%improvement

Traditional Project Management Scrum

41


What is a Complex Adaptive System?n Self organization n No single point of controln Interdisciplinary teams n Emergent behavior n Outcomes emerge with high dependence on relationship and context n Team performance far greater than sum of individuals

J. Sutherland, A. Viktorov, and J. Blount, Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams, in International Conference on Complex Systems, Boston, MA, USA, 2006.

42


Simple Rules Create Self-Organization

• Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior. --Dee Hock, VISA

43

© 2011 Scrum Inc.

Groom Learning Backlogs

44


Agenda - Sprint 2• Sprint 1 - Scrum Origins and Practice• Sprint 2 - Starter Kit for a Scrum Master

• Understand the Job - Project Manager Exercise (1)• Run a Lean Scrum (1)• First Things First (1)• Handle Interrupts (1)• Deal with Emergencies (1)• Understand Flow - Constraint theory (1)• Identify Bottlenecks - Value Stream Mapping (1)• Remove Major Impediments - A3 exercise (2)• Scrum the Scrum (1)

• Sprint 3 - Planning & Estimation• Sprint 4 - Class Backlog & Review

45

© 2011 Scrum Inc.

As a Scrum Master I need to understand My Responsibilities


46


Exercise: Project Leader

• Write down all responsibilities of project leader

• Put one responsibility on each sticky note

47

CSM v 11.07 © Jeff Sutherland 1993-2011

Brooks LawAdding people to a late project makes it later

Optimal team size is 3-7 people

Team%Size%Cost%

Time%0%

5%

10%

15%

20%

25%

1% 2% 3% 4% 5%

Team%Size%

Cost%

Time%

Source: http://www.qsm.com/process_01.html (491 projects)

2

174

106

48

http://www.qsm.com/process_01.html



Exercise: Project Leader

• Write down all responsibilities of project leader

• Put one responsibility on each sticky note• Arrange the sticky notes in these categories

• Product Owner• ScrumMaster• Team• Waste• Other

49


Teams are:

• Cross-functional• Self-organizing• Self-managing

50

© 2011 Scrum Inc.

Run a Lean Scrum

51


9th Hidden Turning Point in HistoryU.S. News and World Report, 21 Apr 1991 - see also J. Womack, D. Jones, D Roos, “The Machine that Changed the World: The Story of Lean Production.” Harper Perennial, 1991.

• W. Edwards Deming taught the Japanese the PDCA cycle.• PLAN: In Scrum, the Product Owner has a business plan and needs

to execute it in a way that maximizes stakeholder value.• DO: The ScrumMaster owns the process and facilitates the team that

executes the plan.• CHECK: The Product Owner inspects the results of team work in

short cycles.• ACT: The ScrumMaster facilitates a retrospective where the team

discovers how to produce better results in the next cycle.• PLAN means to avoid MURI, or unreasonableness• DO means to avoid MURA, or to control inconsistencies• CHECK means to avoid MUDA, or to find waste in outcomes• ACTION indicates the will, motivation, and determination of

the ManagementTOYOTA PRODUCTION SYSTEM “ONE - BY - ONE CONFIRMATION”, University of Kentucky, Lean Manufacturing Conference, May 14-16, 1997, Mr. Kitano – Keynote Address © Toyota Motor Manufacturing, 1997, available at http://www.MfgEng.com with permission of TMM

52

http://www.MfgEng.com

http://www.MfgEng.com


Lean Results - Same with Scrum

National Public Radiohttp://www.npr.org/templates/story/story.php?storyId=99336704

Red River Army DepotHumvee Repair Facility

53

http://www.npr.org/templates/story/story.php?storyId=99336704





Toyota Way as seen by Takeuchi and Nonaka

Respect for People

Teamwork

Continuous Improvement

RespectChallenge KaisenGenchi Genbutsu

The Toyota Way 2001

Source: Catherine Louis

54


Toyota Way implemented by lean consultants

TeamworkContinuous

Improvement

Respect

Challeng

e

Kaisen

Genchi Genbutsu

The Toyota Way 2001

Source: Catherine Louis

55


Taiichi Ohno’s Taxonomy of Waste

56


The 7 Wastes of Software Development• Partially done work• Extra features • Lost knowledge• Handoffs• Task switching• Delays• Defects

Never45%

Rarely19%

Sometimes16%

Often13%

Always7%

Features and functions used in a typical system:

Source: Standish Group Study Reported at XP2002by Jim Johnson, Chairman

2/3 of the stuff we build is rarely or

never used!

Only 1/5 of thestuff we build is used

often or always!

There is surely nothing quite so useless as doing with great efficiency what should not be done at all.Peter Drucker

57


Systematic Strategy for Lean

Thinking tools are best transformed by people and projects

Tools divided into three

dimensions

Level\DimensionValue Flow Pull Perfection

Production

Management

People

P6 Build Integrity in

T19 Refactoring T20 Test

P2 Amplify Learning

T5 SynchronizationT4 Iterations

P2 Amplify Learning

T3 FeedbackT6 Setbased

development

P6 Build Integrity In

T18 Conceptual integrity

T17 Perceived integrity

P1 Create Value

T1 Eliminate Waste T2 Value streams

P4 Deliver Fast

T11 Queue theory T12 Cost of delay

P7 See the Whole

T22 Contracts T21 Measurement

T10 Pull

P3 Defer Commitment

T7 Options thinking T8 Defer commitment

T9 Decisionmaking

P5 Empower team

T16 Expertise

P5 Empower team

T14 Motivation

P5 Empower team

T15 Leadership

P5 Empower team

T13 Self determination

58


CMMI/SCRUM Performance Analysis

10%

20%

a

30%

50%

40%

60%

CMMI 1 CMMI 5

70%

80%

90%

100%

CMMI 5SCRUM

Project effort

Rework

Work

Process focusCMMI

SCRUM

50 %

50 %

50 %

10 %

9 %

6 %

25 %

4 %

100 %

69 %

35 %

Source: Systematic Software engineering 2006

59


ImpedimentsData driven removal of impediments using control charts from 11/2007

Examples on causes:

• Special competences• Disk full• Setup misunderstood• COTS failed

Root cause analysis of time to fix a bug automatically generates ScrumMaster’s impediment list.

60


Daily Clean Code Patternscrumplop.org

... bugs turn into features at midnight ...

Here we discuss bugs that arise within the sprint. Preexisting bugs should be prioritized by the Product

Owner and managed in the Product Backlog. Bugs appearing from outside the sprint such as customer

emergencies should be handled by the Illigitimus non Interrupus pattern.

Velocity is limited because a team spends time dealing with too many bugs.

It is natural to want to keep a list of bugs. There are several forces that encourage this.

• One of the most compelling reasons to put bugs on a bug list is that developers are busy with

other tasks, and shouldn’t be interrupted.

• Managers can see that adding new features increases revenue, but fixing bugs does not

apparently increase revenue. If the team has a fuzzy Definition of Done, work might be considered

Done.

• Bugs that arrive might be considered low priority, and it’s nice to have a place to put them.

In short, deferring the fixing of bugs until later is borrowing against your future velocity.

Therefore: Fix all bugs in less than a day.

61

© 2011 Scrum Inc.

Scrum Patterns

62


Scrum Starter KitPatterns that will prevent common problems

1. How do you get started? (Stable Teams) 2. How do you successfully pull backlog into a sprint?

(Yesterday’s Weather)3. How do get defect free at the end of the sprint? (Daily

Clean Code)4. How do you get stuff done? (First Things First)5. How do you deal with interruptions during the sprint?

(Illigitimus non Interruptus)6. How do you ensure you continuously improve?

(Scrumming the Scrum) (Happiness metric)7. How do you get hyperproductive? (Teams that Finish

Early Accelerate Faster)

63


Stable TeamsMoving people from crisis to crisis helps us paint over the cracks in capability. So we never really understand what the organization is capable of delivering. Moving people from team to team when starting projects, or crisis to crisis during delivery leads to an unstable environment with added costs of;

• administration of keeping track of what people are working on

• productivity as teams work through the Tuckman cycle every time they acquire a new member

• exposure to Brook’s Law

The thinking that the requirements of what to build can be fixed and having everything else changed around the requirements is like taking a geocentric view of the solar system

Creating the stable team is moving to a heliocentric view, we accept that the requirements change, but we need to fix (positional) something to measure this variation from.

Therefore

Keep teams stable and avoid shuffling people around between teams. Stable teams tend to get to know their capacity, which makes it possible for the business have some predictability. Team members should be dedicated to a single team whenever possible.

64


Yesterday’s Weather.... a team is progressing with its historical staff and a stable sprint length, and the time has come

to assess the level of the team's commitment for the upcoming sprint.

It's human nature that individuals and teams with self-esteem set increasingly higher goals for

themselves. By trying to achieve these goals, teams learn. Sometimes such strivings leads to

immediate improvement, particularly when the team challenges itself to improve through use of a new-

found technique or technology. Sometimes, however, the new technique doesn't pan out and the team's

performance remains the same or even gets worse.

Sometimes, the team raises the bar just to raise the bar, either to test the limits or to unconsciously

publish its bravado. Even these self-challenges can pay off, especially in the short term. It is more

common that these higher levels are unsustainable in the long term.

Therefore: In most cases, the number of Estimation Points completed in the last Sprint is the most

reliable predictor of how many Estimation Points will be completed in the next Sprint.

65

https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/estimation-points





Exercise: Implementing Product Backlog

D AV E

L I S

B O B

E R I

M A R

Never keep acustomer waiting

Start early= Finish early

Policy Dave

Lisa

Bob

Eric

Maria

66


Round 2 – Development Process

D AV E

L I SLimit WIP(work in process)

Current limit =1 customerat a time

Policy Dave

Lisa

Bob

Eric

Maria

A

67


Discussion – what was the difference? Why?

68


Weinberg Table of Project Switching Waste

Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284.

69


Prioritizing Between Projects

Adapted from Henrik Kniberg

A1 A2 A3

B1 B2 B3

C1 C2 C3

Product A

Product B

Product C

A1 A2 A3B1 B2 B3C1 C2 C3January February March April May June July

A B C

A1 A2 A3 B1 B2 B3 C1 C2 C3

A B C

January February March April May June July

Traditional strategy: ”Everything is important! Do it all at once!”

Agile strategy: ”Prioritize & focus!”

= A

= B

= C

70


Care about the whole product

Not just your little task

Boy are we effective as a team!

This product rocks!

I’m more efficient if I just do my tasks

Source: Revised after Henrik Kniberg

71


Effect of Project Prioritization on Time to Market

72


Effect of Project Prioritization on Market Share

73

© 2011 Scrum Inc.

As a Scrum Master I need to manage Interruptions

in order to be successful with Scrum

74


Pattern: Illigitimus Non Interruptus

8

5

35

55

35

5

8

ProductBacklog

Beginning of sprint

855

3

SprintBacklog

Kaizen

5 Buffer

PO

Support

Sales

Management

Now

Later

Low Priority

On Buffer Overflow ABORT, Replan, Dates Slip

75

© 2011 Scrum Inc.

How Do You Handle Emergencies

76


To Abort or Not to Abort

77


Pattern: Scrum Emergency Procedure When team is more than 20% behind, execute the Scrum Emergency Procedure by mid-Sprint:• Innovate - do something different

• Identify impediments, root cause analysis, remove impediments, otherwise ...

• Offload Sprint Backlog - get someone else to do it, otherwise ...

• Reduce scope in collaboration with Product Owner, or if this is not possible then ...

• Abort the Sprint• Recommended for new teams that need to

learn how to do better estimates

buyinggoldcoins.net

78


It’s all about technique ...

79


Scrum Starter KitPatterns that will prevent common problems




(Illigitimus non Interruptus)6. How do you deal with emergencies? (Scrum Emergency

Procedure)?7. How do you ensure you continuously improve?



80

© 2011 Scrum Inc.

How Do You Improve Flow?Constraint Theory

81


Theory of Constraints – Smooth Flow

S

P

2. Fix bottleneck

1. Reduce intake

4. Fix nextGoal

Problem

Strategy

3. Increase intake

82


Case Study:Developing Products >5x Faster

A real-life example of applying Value Stream Mapping and Scrum to dramatically speed up product development.

Source: Henrik Kniberg

83


SamConcept

pres.Lisa

assigns resources

Graphics design

Sound design Dev Integr. &

deploy2d 1m

4h6m

8

Game backlog

1w 6m 6m

15

Design-ready games

12

Production-ready games

1m 3w 3m(1m+2m)

3w2h 1d

3 m value added time

25 m cycle time

w2w1 w4w3 w6w5 w8w7

= 12%Process cycle efficiency

Estimate

Preliminary result

2 m cycle time = 12x faster

3-4 m cycle time = 6-8x faster

w2w1 w4w3 w6w5 w8w7

Games out of date⇒ Missed market windows⇒ Demotivated teams⇒ Overhead costs


84


Case Study Take-away Points

Speeding up product development is often a matter of improving the process rather than adding people.Value stream mapping is a great tool for spotting bottlenecksScrum is a great tool for removing bottlenecks

But beware the trap – suboptimization!The pictures make it look easy....

But executing the change is usually hard

Sam Concept pres.

Lisa assigns

resourcesGraphics design

Sound design Dev Integr. &

deploy2d 1m

4h6m 1w 6m 6m

1m 3w 3m(1m+2m)

3w2h 1d

Hey, let’s do Scrum here! Maybe we can cut dev time in half!

From 3 months to 1.5 months...

w2w1 w4w3 w6w5 w8w7


85

© Jeff Sutherland 1993-2010

Chaos Theory - Attractor States

Blue PillNot READYNot DONEImpediments are invisible

Living is hard and painful

Red PillAlways READYAlways DONEImpediments removed

Life is fun and easy

Trance State

Awake State

Chaotic Region

pain

exhileration

Your focus determines your reality! Jedi Master

86


"You take the blue pill, the story ends, you wake up in your bed, and believe whatever you want to believe. Morpheus

87


Red pill is wake up call ...In reality the ship is old and plumbing is badPain is a signal that invaders are presentYou have to fix things you don’t want to fixTools are primitive and you must rely on the forceThought police are everywhere in the matrix and they will try to take you down ...

88

© 2011 Scrum Inc.

Eliminating Challenging ImpedimentsA3 Process

Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management SystemBy Durward K. Sobek II., Art Smalley

Managing to Learn: Using the A3 Management ProcessBy John Shook

89


Venture Company ExampleA3 Process Creates Pull-Based Authority

Countermeasures (Experiments)• Meet with board member• Conference call with CEO• Commitment to implement continuous

integration• Site visit to demonstrate working processes

DoConfirmation (Results )

• Clean implementation in one month• Velocity of seven teams average increase of

20%• Immediately savings of 1.7M Euro/year• Cost of implementation 3000 Euro for expert

consultant CheckFollow-up (Actions)•Introduced prioritized automated testing•Introduced code reviews•Cut deployment time in half•Cut support calls in half•Increased sales Act

Background• Teams not getting software done and tested • Critical components failing every other sprint

PCurrent Condition• Engineers not working together? • Inability to test causing failure• Waste estimated at 2.1M Euro/year

L

Goal / Target Condition• Clean tested code worked at end of sprint• Cut waste by 90%• Save 1.8M Euro/year while improving quality

A

Root Cause Analysis• Why- engineers had different design concepts• Why- Team members not communicating• Why- ScrumMaster not doing good job• Why- No continuous integration• Why- Product Owner focused on new features

N

Owner:Mentor:Date:

Title: Seven teams failing too many sprints

A3 Thinking – Durward Sobek

90


Root Cause Analysis

91


Stories *Tasks

Countermeasures (Experiments)• Proposed countermeasure(s) to address each

candidate root cause. [This should be a series of quick experiments to validate causal model analysis.]

• Identify where in the cause/effect model changes are possible and likely to significantly improve the overall situation.

• Predict results for each countermeasure. Do

Background• Why is this important? • Why should the reader care about this situation

and be motivated to participate in improving?

P

Current Condition• How do things work today? • What is the problem? • Baseline Metrics?

L

Goal / Target Condition• What outcomes are expected for what reasons? • What changes in metrics can be plausibly

expected? A

Root Cause Analysis• What is the root cause(s) of the problem? • Use a simple problem analysis tool (e.g., 5

why’s, fishbone diagram, cause/effect network) to show cause-and-effect relationships.

N

Owner:Mentor:Date:

Title: Concise, self-explanatory


92

© 2011 Scrum Inc.

As a Scrum Master I need to Scrum the Scrum

in order to make the Scrum better

93


Non-IT Scrum• The Scrum, Inc. team started up in Dec 2010. The team

was to run with Scrum.• We started with a meeting to figure out status, what we

were doing and what the backlog should be. The following Monday we hit the ground running with an all at once Scrum implementation.

• We were at a state of zero knowledge, trusting that it would all work. out.

94


A Week in the Life

• Weekly sprints• Monday: Sprint Planning• Wednesday: PB Grooming (5-10% of sprint)• Friday: Sprint Review, Retrospective, PB Grooming• Quarterly release planning meetings to drive goals, ending with a

retrospective

95


Product Backlog

96


How Do We Evaluate?

• Use yesterday’s weather• 25% interrupt buffer• Start retrospective with

happiness metric• Prioritize happiness to

generate kaizen• Put kaizen in sprint backlog

with acceptance tests • Evaluate kaizen in sprint

review

Francois Henri "Jack" LaLanne (September 26, 1914 – January 23,

2011)

97

© 2011 Scrum Inc.

Employee Happiness Impacts the Bottom LineTop 5 public companies1 from the Forbes 2011 list of “Top 100 companies to work for,” significantly outperform the bottom 5 companies2.

1. Top ranked public companies were: SAS (1), Google (4), NetApp (5), Camden Properties Trust (7), REI (9)2. Bottom ranked public companies were: W.W. Granger (100), Starbucks (98), Darden Restaurants (97), Morningstar (95),

Aéropostal (94)Note: Public companies used given availability of financial return information; results reflect a weighted average by revenuesSource: Forbes.com; Dunn and Bradstreet

Top companies slightly larger than bottom ones…

… and are significantly more profitable…

… and growing more rapidly

98

© 2011 Scrum Inc.

Happier People Function Better

• Doctors in a positive mode show three times the intelligence and creativity and diagnose 19% faster.

• Optimistic salespeople outsell pessimistic counterparts by 56%.

• Happier CEOs are 15% more productive.• Happier managers improve customer satisfaction

by 42%.• Humans are hardwired to do better in a positive

state.

99

99

© 2011 Scrum Inc.

The Challenge is How to Help People Be Happy at Work

Tal Ben-Shaher (2007) Happier: Learn the Secrets to Daily Joy and Lasting Fulfillment. McGraw Hill.

100

100

© 2011 Scrum Inc.

Happiness MetricFor each person:

• On a scale of 1-5, how do you feel about your role in the company?

• On the same scale, how do you feel about the company?

• Why do you feel that way?• What would make you feel better?

For the team:• What would make the team feel better in the next

sprint?• Identify the top priority for the team.• Execute the pattern “Scrumming the Scrum”

101

101


Happiness Metric

• On a scale of 1 - 5 we rate• How do you feel about your role?• How do you feel about the company?• What would make you feel better?

• With data from Happiness Metric, order individual and company impediments by value - then Scrum the Scrum

Vote for highest value Estimate value

102

© 2011 Scrum Inc.

Scrumming the Scrum... you are using Scrum as a process improvement. The team must have effec6ve SPRINT RETROSPECTIVES and have POPPED THE HAPPY BUBBLE. The basic Scrum mechanisms are in place, and you want to leverage Scrum to fulfill its vision of kaizen:kai-‐zen (カイゼン) n. a Japanese business philosophy of con2nuous improvement of working

prac2ces, personal efficiency, etc. <ORIGIN> Japanese, literally ‘improvement’. The New Oxford American Dic2onary. Only a small minority of Scrum teams achieve the hyperproduc6ve state. This is because most teams fail to iden6fy and remove impediments. Their soRware is not done, their backlog is not ready, and the team does not self-‐organize to improve performance.

Difficult impediments require extreme focus to remove. Working on many impediments at once oRen leads to a lot of work with liXle gain and can demoralize the team.

Therefore: Identify the single most important impediment at the Sprint Retrospective and remove it

before the end of the next sprint.

To remove the top priority impediment, put it in the Sprint Backlog as a user story with acceptance tests that will

determine when it is Done. Then evaluate the state of the story in the Sprint Review like any other task.

103

103

https://sites.google.com/a/scrumplop.org/published-patterns/retrospective-pattern-language/sprint-retrospective





https://sites.google.com/a/scrumplop.org/published-patterns/very-old-patterns/pop-the-happy-bubble

https://sites.google.com/a/scrumplop.org/published-patterns/very-old-patterns/pop-the-happy-bubble

https://sites.google.com/a/scrumplop.org/published-patterns/very-old-patterns/sprint-backlog

https://sites.google.com/a/scrumplop.org/published-patterns/very-old-patterns/sprint-backlog

https://sites.google.com/a/scrumplop.org/published-patterns/scrum-core-pattern-language/sprint-review

https://sites.google.com/a/scrumplop.org/published-patterns/scrum-core-pattern-language/sprint-review

© 2012

Scrum In

c.

Tracking Velocity

0

75

150

225

300

1 11 23 33 45 55 69 81 91 101 111 122 132 142

Team Velocity

Points

Sprint

Source: Scrum Inc. performance data

Raw Scrum Inc. Velocity History(not adjusted for fluctua6on in team capacity by sprint)

Holiday 2011

12x output with 3x FTEs

104


Scrum Starter KitPatterns that will prevent common problemspublished at scrumplop.org








105


Teams that Finish Early Accelerate Fasterscrumplop.org

Context: The Team may be doing well but struggles every sprint to complete the Sprint Backlog. Worst case, the team is feeling demoralized, velocity is low, and sprint backlog is not completed sprint after sprint...

Problem: Teams often take to much work into a sprint and cannot finish it. Failure prevents the team from improving.

Forces: Teams can be optimistic about their ability to finish requested features. But in doing so, they fail to give themselves time to reduce technical debt and sharpen their saws. Thus they are doomed to a persistently slow pace...

Solution:

Therefore, take less work into a sprint.

106

https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/sprint-backlog

https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/sprint-backlog

© 2011 Scrum Inc.

Planning and Estimation - Day 2/Sprint 3

107


Stories *Tasks

Countermeasures (Experiments)• Proposed countermeasure(s) to address each

candidate root cause. [This should be a series of quick experiments to validate causal model analysis.]

• Identify where in the cause/effect model changes are possible and likely to significantly improve the overall situation.

• Predict results for each countermeasure. Do

Background• Why is this important? • Why should the reader care about this situation

and be motivated to participate in improving?

P

Current Condition• How do things work today? • What is the problem? • Baseline Metrics?

L

Goal / Target Condition• What outcomes are expected for what reasons? • What changes in metrics can be plausibly

expected? A

Root Cause Analysis• What is the root cause(s) of the problem? • Use a simple problem analysis tool (e.g., 5

why’s, fishbone diagram, cause/effect network) to show cause-and-effect relationships.

N

Owner:Mentor:Date:

Title: Concise, self-explanatory


108

© 2011 Scrum Inc.

As a Scrum Master I need to Run a Good Daily Meeting

to help the Team improve performance

109


Team in Ri State

All Blacks New Zealand

110


Using the Daily Meeting to Improve

Value Velocity

Daily Meeting

READY

DONE

Remove Impediments

Sprint

111


Topic: Daily Scrum

Photo: Jason Yip, Thoughtworks

What is wrong with this picture?

112


Daily Scrum Meeting15 minutes - try this experiment- What did you do yesterday to get the top priority story done (tested)- What will you do today to get the top priority story done- Is there anything that prevents the top priority story getting done

today

Photo: Henrik Kniberg

113


Scrum Board on Steroids

114

© 2011 Scrum Inc.

As a Scrum Master I need to act on Scrum Board Warning Signs

in order to improve team performance

115


Sprint backlog – day 0


116


Sprint backlog – after 1st meeting


117


Sprint backlog – day X


118

© 2011 Scrum Inc.

Scrum Board Warning Signs

119


Care about the whole product

Not just your little task

Boy are we effective as a team!

This product rocks!

I’m more efficient if I just do my tasks


120


Warning sign #1


121


Warning sign #2


122


Warning sign #3

WAIT A SECHow is that burndown calculated?

Cost: 50000 Euro/mo/teamSource: Revised after Henrik Kniberg

123


Swimlane Scrum

Source: Jim Coplien

124

© 2011 Scrum Inc.

Scrum Retrospective

125


Scrum Starter KitPatterns that will prevent common problems published at scrumplop.org








126


Sprint Retrospective

Sprintplanning

Sam sick

Week 1 Week 2 Week 3

Servercrashed

Story #25 removed

from sprint

LAN shootout

Half-day

conference

New desks installed

First storyready for

test

SprintdemoBig

argument Team flow!

New buildserver


127


Sprint Retrospective3 roles• Product owner• Scrum master• Team

3 artifacts• Product backlog• Sprint backlog• Sprint burndown

3 activities• Sprint planning• Daily scrum• Sprint review

• Demo• Retrospective


128


“Rules”

• Only address one impediment• Put the kaizen in the backlog for the sprint -

Scrum the Scrum• Action should usually yield results quickly• Communicate actions (and success or not)

back to the Team

• And the hardest rule: Use common sense.

129


Sprint RetrospectiveLong term effect

Sprint

Vel

ocit

y

4 5 6 7 8 9 10 11 121 2 3 13

Effective velocity over time(with retrospectives)

Effective velocity over time(without retrospectives)


130

© 2011 Scrum Inc.

Product Backlog and User Stories

131


Product Backlog• The Product Backlog consists of work to

be done ordered by business value• Anyone can put anything on the backlog• Product Owner is the final authority on

ordering the backlog.• The backlog consists of Product Backlog

Items (PBIs)• The majority of Scrum teams use User

Stories as PBIs.

132


User Story• A UserStory is a story, told by the user, specifying

how the system is supposed to work, written on a card, and of a complexity permitting estimation of how long it will take to implement. The UserStory promises as much subsequent conversation as necessary to fill in the details of what is wanted. The cards themselves are used as tokens in the planning process after assessment of business value and [possibly] risk. The customer prioritizes the stories and schedules them for implementation. -- RonJeffries

133

http://c2.com/cgi/wiki?UserStory




http://c2.com/cgi/wiki?RonJeffries

http://c2.com/cgi/wiki?RonJeffries


User Story Templates• As a <role> I would like to be able to <action> to

achieve <business value>• As a <user role> I can <story> so that

<benefit>• As a <person name> can < story > so that

<benefit>• As a <user> I want to <goal> so that <value

to attain>

The “so that” line is generally considered optional, but used as a default

134


Break Epics into Stories

135

As a frequent flyer I want to book flights customized to my preferences, so I save time

As a frequent flyer I want to book a trip using miles so that I can save money

As a frequent flyer I want to easily book a trip I take often So that I can save time

As a premium frequent flyer I want to request an upgrade So I can be more comfortable

135


User Story - Guidelines

Immediately actionableNegotiableValuableEstimableSized to fitTestableModified from Bill Wake – www.xp123.com

ProductBacklog

Product vision

A

B

C

A B CC

GUI

Client

Server

DB schema

136


Story Map

Check out

Workflow

Richness

List all products

Sort products by type

See product name

See product picture

Add product to cart

View shopping cart

Register as new user

Receive invoice

Edit user details

Pay with credit card

Administrate user

Manage shopping cart

See product details

Browse catalog

Source: Marco Mulder

Clear cart

Remove item from cart

...

...

......

... ...

137


Story Map by Lachlan Heasman

138


Enabling Specification• User stories notes may be enough for a web site• For a complex system you need enabling specification

• Short - 3-5 pages for a feature• Usually a lightweight use case• Product Owner documents critical information in

collaboration with team

• User experience (design)• Business logic

• Data structures• Stories are derived from the enabling specification• The enabling specification is a living document

• Updated over time• Global picture of the feature• Allows traceability of stories back to product design

139


Communication Effectiveness

(Question

-and-a

nswer)

(No question-an

swer)

2 people at whiteboard

2 people on email

2 people on phone

Video recording

Audio recording

Document

Communication effectiveness

Richness (”temperature”) ofcommunication channel

Effective

HotCold

Ineffective

Source: research from McCarthy and Monk (1994)

3 roles• Product owner• Scrum master• Team




140

© 2011 Scrum Inc.

Create User Stories Exercise

141


Exercise BackgroundGeneral situation

Today is Jan 1.Outlook will be outlawed from April 1!

We are greatsoftware.comOur goal:

Create ”bookmeeting.com” an online resource booking service targeted primarily towards those that use Outlook for booking meeting rooms.

March 1: Pilot customer will start using it.

April 1: Commercial rollout.Our context:

We have access to a pilot customer – a conference center!

We have built similar services before, so we have a functioning team, development environment, and operational environment.

This project is top priority, we have a 5-person Scrum team ready to start today.


142


Bookmeeting.com• Product Vision

• Welcome to bookmeeting.com! It doesn’t get any simpler than this.

• Getting started guide:

• Create an account at bookmeeting.com

• Set up rooms

• Your company can now surf to bookmeeting.com and book meetings!

• Payment

• Pay per month (rate may vary depending on number of rooms)

Roles

Booker

Creates and administrates the meeting booking, invites participants

Participant

Attends meetings. Receives invitations & updates.

Admin

Sets up rooms and users.

Buyer

Buys the service and pays for its use.

Seller

Hosts the service and charges for it use. Initially greatsoftware.com.


143


Exercise Step 1

• Create product backlog• Goal: Pile of users

stories

Write on sticky notes.Use a thick pen.Use the story template.

As a XI want Yso that ZAs a X

I want Yso that Z

As a XI want Yso that Z


As a XI want Yso that Z As a X

I want Yso that Z



144


Ways to Identify Relative BV

• Bubble sort• Compare new story to others

• Dollars (euros, etc)• On each story

• BV Points (via Priority Poker)• Gather “experts” and size versus some standard

using Fibonacci scale• Distribute set number of “points”

• How many dots from my pool of 1,000 does this story get?

• Life-boat strategy• Least important story, then next, etc.

145

© 2011 Scrum Inc.

As a Scrum Master I need to know how to Rescue a Failed Scrum

in order to do my job

146


Case StudyStopping a Death March

This is the real story and not for public consumption!It demonstrates:1. How to fail with Scrum2. How to rescue a failed Scrum3. How to convert a waterfall team into a Scrum team

147


Symptom: Waterfall process (under Scrum banner)

20072006 Requirements

Coding

Testing?Release

We are here

Q1 Q2 Q3 Q4 Q1 Q2

148


Symptom: Long, detailed requirements specifications

149


Symptom: Lack of trust & commitment

150


Strategy: Implement Scrum

• Show us where we stand• Help us move faster

Create product backlog

Estimate product backlog

2007

Jan Feb

We are here

Execute 2 sprints, measure velocity

151


Step 1: Change Definition of Done

• Old definition of done:• Code checked in

• New definition of done:• Releasable

• Tester added to team

152


Step 2: Create a product backlog

Features left to implement Features implemented but not tested & integrated

feature Xfeature X

feature X

feature X

feature X

feature X

feature X

feature X

feature Xfeature X

feature X

feature X

feature X

feature X

feature X

feature X

feature X

feature X

feature Xfeature X

feature Xfeature X

Test/integrfeature Y



















PO

153


Points vs. Hours• Rand Corporation received a grant from U.S.

DOD in the 1940’s to determine best way to estimate tough projects• Discovered estimation in hours has high error rate and

wide variance• Found people could put things in relative size piles best

• Fibonacci growth pattern easiest for humans• Seen everywhere in nature• RAND called it the Delphi technique

154


Why Points are Better Than Hours

Cone of Uncertainty

Gray Line - Hours Red Line - Points

Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan (2012) Scrum + Engineering Practices: Experiences of Three Microsoft Teams. IEEE Best Industry Paper Award, 2011 International Symposium on Empirical Software Engineering and Measurement.

155


The Fibonacci Sequence

• Barry Boehme called it the Wideband Delphi Technique for software• Agilists call it Planning Poker

156


Step 3: Estimate product backlogFeatures left to implement Features implemented but not tested & integrated

2

5

3

2

2

?

Total:180 points

Total:70 points

157


Step 4: Execute 2 sprints

EstimatedVelocity

ActualVelocity

30 925 10

Sprint 1

Sprint 2

158


Step 5: Face reality & Revise the plan

Backlog = 250 points

Velocity = 10 points/sprint 25 sprints > 1 year until release!

2007Promised release

Q1Q1 Q2 Q3 Q4

2008 Earliest likely release

Q2

We are here

159


Step 6: Act

Backlog = 250 points

Velocity = 10 points/sprint

Fix impedimentsPressure on teamIneffective build & test environmentLack of teamwork, discipline & motivationDisruptions & context switchingUnrealistic expectationsROOT CAUSE: Company not focused

Reduce

Increase

Reduce total scopeIncremental releases

Overall priorities1. Operations2. Project X3. Anything else

160


Result

2007Originally promised release(big-bang)

Q1Q1 Q2 Q3 Q4

2008Earliest likely release if process hadn’t changed(big-bang)

Actual release(incremental)

Actual release(incremental)

Velocity

10

20

30

9-10

25-30estimated

actual

Q2

Q1 Q2 Q3

2007

161


Case 3: Take-away points• Waterfall is still waterfall even if you call it Scrum

• Know your tools, get training & coaching early.• Don’t believe your plan

• There is no ”the plan must be right because we promised”.• Make sure you have reliable feedback loops & a changeable plan.

• There is no ”too low velocity”• Just actual velocity, and a realistic or unrealistic plan.

• Build quality in• Don’t postpone test & integration, that gives a false velocity.

• Having good people isn’t enough• An inappropriate process can cause even a great team to fail.

• Dramatic improvements can be made quickly• With a strong management team that has access to empirical data

and is willing to focus.

162

© 2011 Scrum Inc.

As a Scrum Master I need to know how to Estimate Storiesin order to do my job

163


Irrelevant Information

SM

20 hrs

Spec 1

ABC

Same spec+ irrelevant details

ABC

SM

39 hrs

Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006

164


Anchoring

SM

456 hrs

Spec

PO500 hrs

Never mind me

Same spec

SM

555 hrs

PO50 hrs

Never mind me

Same spec

SM

99 hrs

Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006

165


Agile Estimating Strategy

• Don’t estimate time• Estimate relative size of stories• Measure velocity per sprint• Derive release plan

• Estimates are done by the people who are going to do the work• Not by the people who want the work done

• Estimate continuously during the project, not all up front

• Prefer verbal communication over detailed, written specifications

166


Exercise

• Estimate stories• Pick smallest relevant story and give

it 3 story points• Estimate relative size of other stories• Discuss outliers and vote again until

all numbers are within 3 cards, then average.

• Extra time? • Break down big stories into smaller

stories









8

2

3

5

1

2

5

13

167

© 2011 Scrum Inc.

Refining the Product Backlog

168


Product BacklogAdministrate

users

Register new user

Edit existing user

Delete user

Find user

100 simultaneous

users

Operations manual

As a helpdesk operator I want

to see who is logged in

View Invoice in HTML, PDF, or

Excel format

100 simultaneous

users

Operations manual




Excel format

Register new user

Edit existing user

Delete user

Find user

100 simultaneous

users

Operations manual




Excel format


169


Splitting Stories and Breaking Out Tasks

Administrate users

REgister new user

Edit existing user

Delete user

Find user

User admin

User admin

User admin

User admin

Do GUI design

Write failing test

Do integration

test

Create DB schema

Write server-side

logic

Write form validation

Split stories

Break into tasks(normally during sprint planning meeting)

13

5

3

8

2


170


Some Definitions of Done

Default Definition of Done• Acceptance tested• Release notes written• Releasable• No increased technical debt

Default Definition of Done• Unit/Integration tested• Ready for acceptance test• Deployed on demo server

= I haven’t messed up the codebase

Default Definition of Done• Releasable

What’s else must be done before shipping the code? - For example ”customer acceptance test + user documentation”Why not? Who does it? When? What happens if a problem turns up?Burn up this work in release burndown!


171


Burndown Strategies

• Burndown number of stories completed• stories must be small and of similar size

• Burndown stories only in points• stories must be small

• Burndown tasks in points• use planning poker to estimate tasks in points

• Burndown tasks in hours• Scrum Foundation and ScrumInc. no longer view

this as best practice

172

© 2011 Scrum Inc.

Acceptance Tests

173


Modern Agile Acceptance Model• The move toward Acceptance Test

Driven Development requires a more complete model of progressing requirements acceptance

• Example model (sharper definition of done)• Conditions of Satisfaction - broad terms

• Acceptance Criteria - further refined• Examples - actual scenarios or data

• Executable Examples - Executable Spec

174


Simple Scenarios• Suppose we are creating a registration

function• It consists of specifying email (as User

ID) and Password

Enter your Email and Password to RegisterEnter your Email and Password to Register

Email Address:

Password:

Register

175


AcceptanceCondition of Satisfaction• Conditions of Satisfaction are high level

criteria established with an initial Epic/Feature/User Story• In our previous example, the conditions of

acceptance for the password would be:• Ensure the password is not easy to crack.

• The PO would define the conditions of acceptance in concert with business stakeholders


Email Address:

Password:

Register

176


AcceptanceAcceptance Criteria• Acceptance Criteria specifies the details that

the team can then build against:• Following the example for Password:

• Must be at least 8 characters and no more than 12

• Must contain only alphanumberics and the period

• Must contain at least one digit• Must contain at least one character

• Etc. (there may be more criteria)

• The PO works closely with a tester, developer, and business stakeholder to define these criteria


Email Address:

Password:

Register

177


AcceptanceExamples Make It Real• Actual examples are the ultimate way to

communicate requirements:

• The PO works closely with a tester, developer, and business stakeholder to define these criteria

Password Expected Expected Message Comment

abc123 Invalid Your password must be at least 8 characters and no more than 12 charcters long

abcdefghi Invalid Your password must contain at least one character and one number

1aaaaaaaa Valid Why valid?

ajx972dab Valid

178


Acceptance Test Driven Development (ATDD)Tools: Fit and Cucumber

FIT (Framework for Integrated Test) and Fitnesse (Wiki front end)

• Test specified in table format• Developers generates classes

(“fixtures”) to hook into application

• Users/testers use Wiki or Excel to specify inputs and outputs

Cucumber• New tool for natural language

scenarios

In order to ensure my account is correctAs a Registered UserI want to check my recent activity

Scenario: Recent Account Activity Given I am a registered user “Jsmith” And I am logged in with password “xyx123” And I have had account activity in the last 45 days And I am on the home page When I click the “Recent Activity” button Then I should see the “Account Activity” Page And I should see a list of my activity over the last 45 days

Scenario: No Recent Account Activity Given I am a registered user “Jsmith” And I am logged in with password “xyx123” And I have had account activity in the last 45 days And I am on the home page When I click the “Recent Activity” button Then I should see the “Select Account Activity Period” Page And I should get a message: “You had no activity in the last 45 days, please select a time frame to review”

numerator denominator quotient

10 2 5

12.6 3 4.2

100 4 25 expected24 returned

179

© 2011 Scrum Inc.

Release Planning

180


Release Cycles

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16Sprint #

Release 1(Alpha)

Release 2(Beta)

Release 3(Live)

Release 5(maintenance)

17 18 19 20


• Goal: every sprint results in potentially releasable product increment.• Product owner decides when to release.



181


Measuring VelocityBeginning of sprint

8

5

35

55

35

5

8

ProductBacklog

Estimatedvelocity = 26

8

5

35

5

SprintBacklog

End of sprint

8

5

35

5

SprintBacklog

Done!

Done!

Done!

Almost done

Not started

Actualvelocity = 18

182


Release Planning

• Today is Aug 6• Sprint length = 2 weeks• Velocity = 30 - 40

What will be done by X-mas?(10 sprints)

300

400PO

183


Release Burndown

100

200

300

400

Work remaining(story points)

Sprint1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16


184


Release Burndown with Changing Scope

-40

-20

0

20

40

60

80

100

120

1 2 3 4 5

Work Added

Work Remaining

Release date

185

© 2011 Scrum Inc.

Velocity

186


What if this is the first sprint for the team?

• Good rule of thumb is 40% burnup cost.• 40% of your story points will be used to get

the team operational.• Team Forming, Storming, Norming• Team not understanding Scrum• Team thinking they can do more than they can

do

187


V V V

V

2009

Q42008

Q32008

June2008

May2008

2009

2010

2011

2012

Apr2008

Backlog Maintenance

188


Product Owner Responsibility

• Get one sprint READY backlog• Team can get started

• Get two sprints READY backlog• Team can go sprint to sprint

• Build out Release Plan• Company can predict revenue

• Build one year roadmap• Customers can be briefed on company strategy

189


What Is PRINCE2?

• Process driven Project Management method• Describes procedures to coordinate people and

activities in a project• A project has a clear start and end• Goal: deliver product according to business case

• Projects are split in stages• At the end of each stage, verify if business case

is still valid• If not: terminate


190


Scrum and PRINCE2 Have a Different Focus

Scrum• Get the work DONE• Says little about

starting and stopping projects

• Prefers stable teams

PRINCE2Create a controlled environmentSays little about how to get work DONEDefines temporal organization

Note: PRINCE2 does not mandate waterfall


191


Scrum in a PRINCE2 Environment

Directing a project

Managing stage

Initiating a project

Starting up a project

Controlling a stage

Closing a project

Managing product

Planning

Product working

Initial release

Vision

Release

Sprint

Updated release

Release

self-organizing

PID: business


192


Scrum Can Help PRINCE2 Projects to Be Successful

• Scrum is great in getting work packages done, PRINCE2 doesn’t tell you how to do this

• Work packages in Scrum are increments of production ready software

• Production ready software is the most reliable indicator of progress


193

© 2011 Scrum Inc.

Velocity and Technical Debt

194


Clean & Simple Code

public class Dog { private final String name; private int woofCount = 0;

public Dog(String name) { this.name = name; }

public void woof() { ++woofCount; }}

import java.sql.Connection;import java.util.concurrent.ExecutorService;import java.util.concurrent.Executors;

public class Dog {private Executor executor = Executors.newFixedThreadPool(18);private int CACHE_SIZE = 50;

public Dog() {try { Class.forName("oracle.jdbc.ThinDriver"); connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); } catch (ClassNotFoundException e) {}

new Thread().start();}

public void woof(Person woofCaller) {Connection connection = null;PreparedStatement statement = null;try { connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis()); statement.setString(2, person.getName()); statement.setString(3, person.getPhoneNumber().getNumber()); statement.executeUpdate(); } }}} Connection a = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");b = a.prepareStatement("select * from Dog where name = '" + name + "'"); c = b.executeQuery();if (c.next()) {String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber);return person;} else { return new Person("", null);}

} catch (SQLException e) { return null;} catch (IllegalArgumentException x) { throw x; }}

public List<Person> getAll() { connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis());}if (statement != null) {if (c.next()) {String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber);return person;} else {

Dog.java v0

Dog.java v1.1Big & hairy

Dog.java v1.2Clean & simple

public class Dog { public static void main(String[] args) { System.out.println("WOOF 1!"); System.out.println("WOOF 2!"); }}

Dog.java v1.0Quick & dirty

Simple code:1.Passes all tests2.No duplication3.Readable4.Minimal

Simple is hard!


195


Velocity CalibrationEstimatedVelocity

ActualVelocity

40 30

30 28

30 31

30 30

Estimated Actual

40 30

40 30

40 30

Estimated Actual

40 30

50 30

60 30

Estimated Actual

40 35

35 30

30 25

30

25

20


196


Technical Debt & Release Planning

1

Remainingstory points

Sprint

2 3 4 5 6 7 8 9 10 11 12 13 14 15

100

200

300

400

Um... we’re donewhen we’re done!

We’ll be done by

sprint 10!

Sorry, we’re late!We should definitely by done by sprint 12!


197


Technical Debt

Vmax

Vactual

velo

city

time

Vmax

velo

city

time

VactualSustainable pace!

Definition of Done• .... bla bla ....• No increased technical debt

Code duplicationTest coverageCode readability


198


Dealing with Technical Debt

Vmax

Vactual

velo

city

time

Road to hell

First stepSlow downStop accumulating debt

Second step(optional)Slow down even moreStart repaying debt

Sustainable pace Increasing pace!

Definition of Done• .... bla bla ....• No increased technical debt

Definition of Done• .... bla bla ....• Technical debt decreased

3 roles• Product owner• Scrum master• Team





199


Gartner - Technical Professional Advice2012 Planning Guide: Application Delivery Strategies• Business users are losing patience with old-

school IT culture. Relationships are tense and resentful. Legacy systems and practices impede agility. Bottom line - GET AGILE

• Adopt a product perspective.• Say goodbye to waterfall.• Improve cross-competency collaboration.• Launch a deep usability discipline.• Start a technical debt management program.

200


201


202

© 2011 Scrum Inc.

Scrum Roles

203


Henrik Kniberg

Product Owner

Represents all stakeholdersDecides where the team should go

Not how they get thereNot their speed

Defines scope / vision / roadmap PrioritizesOwns product backlog

Does not estimate storiesUsually not the line manager


204

© 2011 Scrum Inc.

ScrumMaster Challenges

205


Scrum Master

• Works with the Product Owner to:• Find techniques for effective Product Backlog

management;• Clearly communicate vision, goals, and Product Backlog

items to the Team;• Teach the Scrum Team to create clear and concise

Product Backlog items;• Understand long-term product planning in a Scrum

environment;• Understand and implement the values of the Agile

Manifesto; and,• Facilitate Scrum events such as release planning

206


Scenario 1 The VP of the group appears in the middle of the Sprint, and says to you: one of our

clients has a special request which if we can complete it, we will win $1 million in business.

Scenario 2 The product owner says that he's not going to be available to attend the Sprint planning

meeting, but he doesn't mind if the team goes ahead and does it without him.

Scenario 3 It's halfway through the Sprint, and the team is way behind on progress. It looks like

there's no way it's going to finish what it committed to during the Sprint.

Scenario 4 One member of the team speaks up and says he thinks the retrospective is a waste of

time; several other members of the team murmur in agreement, and someone else suggests that the team stop doing the retrospective.

Scenario 5 The team appears to be very stressed out. They are having to work late most nights of

the week, and they even have to work Saturdays every now and again, in order to meet their Sprint goals. You hear comments like Scrum is awful it forces us to work so hard

Scenario 6 A team member has recently moved. He mentions that he is trying to find daycare for

his daughter and it’s blocking him from doing his work.

Scenario 7 The team hasn’t had any impediments for the last seven weeks. My boss is very happy.

He thinks I’m the best ScrumMaster ever.

207


ScrumMaster

Enforces Scrum practicesCoaching rather than command & control

Removes impedimentsUsually part of the team Usually Not the line

managerUsually Not the tech guru

Small team Large team

Few problems ≈ 10% ≈ 50%

Many problems ≈ 50% 100%

Is ScrumMaster a full-time role?

Impediment backlog

• Slow workstations• Interference from

sales• No test environment• No contact with

customer• Crowded office


208


Basic Truths about TeamsTeam motivation

People are most productive when they manage themselves.

People take their commitment more seriously than other people’s commitment for them.

People do the best they can.

Under pressure to “work harder,” developers automatically and increasingly reduce quality.

Team performanceTeams and people do their best work when they aren’t interrupted.

Teams improve most when they solve their own problems.

Broad-band, face-to-face communications is the most productive way for teams to work together.

Team composition

Teams are more productive than the same number of individuals

Maximum effective team size is around 7-8 people.

Products are more robust when a team has all of the cross-functional skills focused on the work

Changes in team composition reduce productivity.

Source: Ken Schwaber

209


Team

7 +/-2 full-time individualsCross-functionalSits togetherShared responsibilitySelf-organizing

SM


210


Management Responsibilites

1. Provide strategic vision, business strategy, and resources (business model).

2. Remove impediments surfaced by Scrum teams that the teams cannot remove themselves.

3. Ensure growth and career path of employees.4. Challenge teams to move beyond mediocrity.

211


Work that a manager no longer has to do• Make commitments on behalf of the team about how much they can

get done by a certain date.• Convince team that the commitments made on their behalf are

attainable.• Give direction to the team on how to implement the work, so they can

deliver on their forecasts.• Monitor the team's progress, to make sure they stay on schedule, and

they are not having problems.• Step in and determine the solution, if the team falls behind on their

schedule, or starts having problems.• Conduct weekly status update and 1:1 meetings with the team, to

surface issues, and provide direction.• Provide motivation and push the team to work harder than they might

want to, using carrots and / or sticks.• Decide task assignments among the team members and follow up on

tasks to make sure they've been done.• Be responsible for the team doing the right thing at the right time in

the right way.

Source: ADM Copyright 1993-2010, All Rights Reserved v1.3

212


Manager as a Patron

PATRON ROLE There is someone who defends the developer at the enterprise level

The team needs a sponsor who can remove obstacles and provide resources. The ScrumMaster is only the "scrounger" who goes looking for these resources when needed; the team needs a patron who helps protect and nourish the Scrum effort, and its product, as a whole.

213


Leadership StylesTHE CONTEXT’SCHARACTERISTICS

THE LEADER’S JOB DANGER SIGNALS RESPONSE TODANGER SIGNALS

SIMPLE -Repeating patterns andconsistent events-Clear cause-and-effectrelationships evident to everyone;right answer exists-Known knowns-Fact-based management

-Sense, categorize, respond-Ensure that proper processes arein place-Delegate-Use best practices-Communicate in clear, direct ways-Understand that extensiveinteractive communication maynot be necessary

-Complacency and comfort-Desire to make complexproblems simple-Entrained thinking-No challenge of received wisdom-Overreliance on best practice ifcontext shifts

-Create communicationchannels to challenge orthodoxy-Stay connected withoutmicromanaging-Don’t assume thingsare simple-Recognize both the value andthe limitations of best practice

COMPLICATED

-Expert diagnosis required-Cause-and-effect relationshipsdiscoverable but not immediatelyapparent to everyone; more thanone right answer possible-Known unknowns-Fact-based management

-Sense, analyze, respond-Create panels of experts-Listen to conflicting advice

-Experts overconfident in theirown solutions or in the efficacy ofpast solutions-Analysis paralysis-Expert panels-Viewpoints of nonexpertsExcluded

-Encourage external and internalstakeholders to challenge expertopinions to combat entrainedthinking-Use experiments and games toforce people to think outside theFamiliar

Excerpted from “A Leader’s Framework for Decision Making” by D. Snowden & M. Boone in Harvard Business Review, NOV 2007.

214


Leadership StylesTHE CONTEXT’SCHARACTERISTICS

THE LEADER’S JOB DANGER SIGNALS RESPONSE TODANGER SIGNALS

COMPLEX -Flux and unpredictability-No right answers; emergentinstructive patterns-Unknown unknowns-Many competing ideas-A need for creative and innovativeapproaches-Pattern-based leadership

-Probe, sense, respond-Create environments and experiments that allow patternsto emerge-Increase levels of interaction andcommunication-Use methods that can help generateideas: Open up discussion (asthrough large group methods);-set barriers; stimulate attractors;encourage dissent and diversity;and manage starting conditionsand monitor for emergence

-Temptation to fall back intohabitual, command-and-controlmode-Temptation to look for factsrather than allowing patterns toemerge-Desire for accelerated resolutionof problems or exploitation ofOpportunities

-Be patient and allow time forreflection-Use approaches thatencourage interaction sopatterns can emerge

CHAOTIC -High turbulence-No clear cause-and-effect relationships,so no point in lookingfor right answers-Unknowables-Many decisions to make and notime to think-High tension-Pattern-based leadership

-Act, sense, respond-Look for what works instead ofseeking right answers-Take immediate action toreestablish order (command andcontrol)-Provide clear, directCommunication

-Applying a command-and-controlapproach longer than needed-“Cult of the leader”-Missed opportunity for innovation-Chaos unabated

-Set up mechanisms (such as parallel teams) to take advantage of opportunities afforded by a chaotic environment-Encourage advisers to challenge your point of view once the crisishas abated Work to shift the context fromchaotic to complex

Excerpted from “A Leader’s Framework for Decision Making” by D. Snowden & M. Boone in Harvard Business Review, NOV 2007.

215

© 2011 Scrum Inc.

Sprint Planning

216


Sprint Planning Meeting

ProductBacklog

Sprint 1Backlog

Goal: xyzJackass team, sprint 15

Sprint goal- Beta-ready release!

Sprint backlog- Deposit (5)- Migration tool (13)- Backoffice login (3)- Backoffice user admin (5)(Estimated velocity = 26)

Schedule- Sprint period: 2006-11-06 to 2006-11-24- Sprint demo: 2006-11-24, 13:00, in the cafeteria- Daily scrum: 9:30 – 9:45, in conference room Jimbo

Team- Jim - Erica (scrum master)- Tom (75%)- Niklas- Eva- John

217


Why is it important that the team AND product owner attend the sprint planning meeting?

Scope

Cost Priority

PO

POSM



218


Sprint Planning Meeting - Example

• Goal• Present product backlog• Reprioritize, re-estimate, split/combine stories• Break out tasks• Estimate velocity, draw the line

EncryptedPassword

More important Less important

Deposit Migrationtool

Backofficelogin

BackofficeUser admin

WithdrawPerf Test8 13 3 13 8

UserMigration

tool5

TransactionMigration

tool5DBdesign2h

Impl.DAO12h

IntegrTest

8hRefact.

4h

Write failing test8h

GOAL: Beta-ready release!

20

219


The Sprint Commitment

• Team’s commitment to the Product Owner:• “We promise that ...”

• We believe we can reach the sprint goal.• We will do everything in our power to reach the goal and will

inform you immediately if we have problems.• Code will be potentially shippable at the end of the sprint.• If we fall behind schedule we will remove the lowest priority

stories first.• If we get ahead of schedule we will add stories from the

product backlog in priority order.

• We will display our progress and status on a daily basis.• Every story we do is complete.

• Caveat• Estimates are estimates. We will be early some times and

late other times. We will document this normal variation with our sprint velocity.

220


Software Estimation Accuracy

Barry Boehm. Cost Estimation with COCOMO II. CS 577a, University of Southern California, Center for Software Engineering. Fall 2006

©USC-CSE 6

• Effect of

uncertainties

over time

Feasibility Plans/Rqts. Design Develop

and Test

Phases and Milestones

Relative

Size

Range

Operational

Concept

Life Cycle

Objectives

Life Cycle

Architecture

Initial

Operating

Capability

x

0.5x

0.25x

4x

2x

221


Sprint Demo

• Team demonstrates working code to stakeholders

• Only 100% completed stories are demonstrated• Partially complete stories are ignored

• Direct feedback from stakeholders• Feedback incorporated into the product

backlog

What have we accomplished?

222


Can We Talk About Other Things?

• Yes.• But talk is cheap (and easy to misunderstand)

• Yes.• Velocity and its meaning• Meaning of progress to date• New Release plan• Etc, etc, etc

223

© 2011 Scrum Inc.

Testing

224


Testing – Ideal Case

Sprint 1

Timeline

Sprint 2

v1.0.0

Scrum team

End users

v1.1.0


225


Testing – Common Alternative

Sprint 1

v1.0.0

1.0 acceptance test

Bug!

Sprint 2

v1.0.1

v1.0.1

Scrum team

Acceptance test team

End users

v1.1.0

Timeline

226

© 2011 Scrum Inc.

Scaling

227


Expanded Scrum Cycle

Engineering Practices

Product Owner

228


Small Teams• Adding people to a late project makes it later

Team%Size%Cost%

Time%0%

5%

10%

15%

20%

25%

1% 2% 3% 4% 5%

Team%Size%

Cost%

Time%

Source: http://www.qsm.com/process_01.html (491 projects)

229




Linear Scalability

230


Few Roles • Performance = Communication Saturation =

Collective Team Knowledge• Daily meeting with few roles = high velocity

0

20

40

60

80

100

120

0 20 40 60 80

Number of Roles

% S

atur

atio

n

Communication Saturation and Roles. Organizational Patterns of Agile Software Development by Coplien and Harrison (2004)

231

© 2011 Scrum Inc.

Engineering Practices and Scrum

232


Scrum & XP

SprintPlanningmeeting

Daily Scrum

Sprint Review

Sprintbacklog

Productbacklog

TDD

Pair programming

Refactoring

Simpledesign

Coding standard

SustainablePace

Metaphor

Continuous Integration

Collective ownership

Whole team

Planning game

Small releases

Customer tests

Burndownchart

Productowner

Team

ScrumMaster

Scrum

XP


233


Feedback Cycles

Pair programming

Continuous integration

Daily Scrum

Sprint demo

Unit test


234

© 2011 Scrum Inc.

XP Game

235


• Simulation of 3 sprints• GOAL: implement as much business value as possible!

• Product owner:– Prioritizes stories– Validates “done”– Keeps score

• Scrum master– Ensures rules & timeboxes

are followed

XP game

236

© 2011 Scrum Inc.

Next Steps

237

© 2012

Scrum In

c.

Common “Release Plan” for Companies at Different Levels of Scrum Experience

Companies Just launching Scrum

Companies with teams using Scrum

Scrum Capability Assessment

Leadership workshop

ScrumMaster Training

Product Owner Training

Implementa[on coaching

Scrum CapabilityAssessment

Implementa[on coaching

Set enterprise level goals

Select Exec. Sponsor & transi[on team

Select Pilot team(s)

Provide Scrum Training

Create ini[al product backlog

Kickoff 1st sprint planningPick SM & PO

Monitor and remove impediments

Start regular sprint cycle

Update enterprise level goals

Iden[fy key improvement

levers

Leadership workshop

Formulate correc[ve ac[ons (A3s)

Add Kaizen to backlog

Execute improvements

ScrumMaster Training?

Product Owner Training?

Implementa[on coaching?

238

238


Motivate your teams

http://www.youtube.com/watch?v=u6XAPnuFjJc

239

http://www.youtube.com/watch?v=u6XAPnuFjJc&noredirect=1

http://www.youtube.com/watch?v=u6XAPnuFjJc&noredirect=1


For those who want certification ...• The Scrum Alliance CSM test will transition to pass/

fail on 1 Sep 2012. Read the Scrum Primer - http://agileatlas.org/articles/scrum-primer

• Students who pass the test will receive a list of missed questions with correct answers highlighted.

• Students who fail will receive a list of missed questions without answers.

• The test can be taken one additional time at no charge. After that a fee of $25 per additional attempt will be charged.

• A passing score is a least 24 out of 35 questions correct.

240

http://agileatlas.org/articles/scrum-primer





Next Steps• Names and email addresses will be uploaded to

Scrum Alliance• You will get email with username and

password• Login and update your profile • Take the test and get a passing score• You will have a web page that identifies

you as a certified ScrumMaster

241

© 2012

Scrum In

c.

Stay Connected• Our Website

• check in for announcements, new content and services, book releases, and more!

• www.scruminc.com

• ScrumLab• join the conversations on our forums with the scrum

community and your class.• coming soon: articles, videos, papers on all things scrum• scrumlab.scruminc.com

• Blog• scrum.jeffsutherland.com

• Webinars• advance your learning with our interactive webinars. visit

the scrumlab store to view upcoming topics.

• Twitter, Facebook, and G+• @jeffsutherland, scrum and scrum inc.

242


Resources• How to Build Hyperproductive Teams (Ri State)

• Scrum and CMMI: Going from Good to Great

• Carsten Jakobsen and Jeff Sutherland

• Shock Therapy: Bootstrapping a Hyperproductive Scrum

• Jeff Sutherland, Scott Downey, and Bjorn Granvik• All papers are at “Jeff Sutherland’s Papers” http://

scrum.jeffsutherland.com• Download Scrum Handbook at http://jeffsutherland.com/

scrumhandbook.pdf• Download Scrum Papers at http://jeffsutherland.com/scrumpapers.pdf• Hyperproductive Metrics slides at http://scrum.jeffsutherland.com/

2010/10/scrum-metrics-for-hyperproductive-teams.html• Slides http://jeffsutherland.com/csmjsv16.pdf

243

http://jeffsutherland.com/scrum




http://jeffsutherland.com/scrumhandbook.pdf




http://jeffsutherland.com/scrumpapers.pdf

http://jeffsutherland.com/scrumpapers.pdf

http://scrum.jeffsutherland.com/2010/10/scrum-metrics-for-hyperproductive-teams.html




http://jeffsutherland.com/csmjsv16.pdf

http://jeffsutherland.com/csmjsv16.pdf

SCRUM MASTER TRAINING - Agile Lean House

Documents