Day1 CoreScrum Training

8/8/2019 Day1 CoreScrum Training

http://slidepdf.com/reader/full/day1-corescrum-training 1/90

Core Scrum

Sam Hwang

Sep 2009



Course agenda

• Overview of Agile and Scrum

• Roles on a Scrum Team

• Product Backlog

• Sprint Planning

• Sprint Tracking• Rules of Scrum

• Stand-up

• Sprint Review• Sprint Retrospective

Today



Outline 1 of 2

• Overview

•Defined vs Adaptive Process

• Origins of Agile

• Scrum Process Diagram

• Scrum Team Roles

• Product Backlog

• Sprint Planning Meeting

• Sprint Tracking



Outline 2 of 2

• Sprint Planning Meeting Simulation

• Sprint Rules!

• Potentially Shippable

• Done (Again)

• Changes / Termination

• Sprint Length

• Stand-up

• Dysfunctional Standup Exercise • Sprint Review

• Sprint Retrospective



A defined process

A defined

process

A defined

process

• Every task must be completely understood.Whengiven a well-defined set of inputs, the same outputs are

generated every time.



Is software development a definedprocess?

• Is every task completely understood?• Given the exact same inputs (including

people) Will we get the same results every time?

Can we even have the exact same inputs?



Adaptive process control

• Useful when

Process cannot be sufficiently described toensure repeatability

• Embrace Change• Inspect and Adapt



An Iterative Process

v2.0 v2.1 v2.3 v2.4

Design

Test

B u i l d

Innovate



What is Agile?



Origins

• Scrum

• “The New New Product Development Game,” HBR, 1986.

• Schwaber, Beedle, Sutherland on Scrum starting in 1995.

• Extreme Programming

• Kent Beck, Ward Cunningham, Ron Jeffries, 1999

• Others

• Lean

• Feature-Driven Development



The Agile Manifesto

• February 2001

• 17 advocates of “lightweight methodologies”got together to see what they had in common

• Result was a manifesto of four valuestatements



Process and toolsProcess and toolsIndividuals and

interactions

Individuals and

interactionsover

The Agile Manifesto

Comprehensive

documentation

Comprehensive

documentationWorking softwareWorking software over

Contract negotiationContract negotiationCustomer

collaboration

Customer

collaborationover

Following a planFollowing a planResponding to changeResponding to change over



Agile

…ContinuouslyShort timeboxed iterations.Deliver ValueWork on highest value and

riskiest features first. Release

frequently. Reduce waste.

Communicate

Big visible charts, informationradiators, daily meetings.

Regular planning sessions.

Get Feedback

Show work early and often,make it visible and get constant

customer involvement

CollaborateWhole team thinking, owning

and solving problems with thecustomer.

AdaptEmbrace change. Give up on

“managing” and “controlling” it



This is NOT Agile

• Compress the schedule

• No documentation

• Hack code

• No design or planning

The organization may gain short term speed at the cost of long term gain.



Course agenda


• Roles on a Scrum Team• Product Backlog

• Sprint Planning


• Stand-up


Today



The Scrum Process



The Scrum Team

Product Owner

Scrum Master

The Stakeholders



Product Owner

Deliver

Value• Plan

• Prioritize

• Collaborate

• Product visionary

• Maximizes business value

• Prioritizes and clarifies requirements



Product Owner

• Defines the features of the product, decideson release date and content

• Is responsible for the profitability of theproduct (ROI)

• Prioritizes features according to marketvalue

• Can change features and priority in theproduct backlog

• Accepts or rejects work results

• Communicates with the business



Scrum Master

• Serves the team

• Tracks progress

• Guards the Scrum process



Scrum Master

• Ensures that the team is fullyfunctional and productive

• Enables close cooperation across allroles and functions and removesbarriers

• Shields the team from externalinterferences

• Ensures that the process is followed.Participates in daily scrum, sprintreview and planning meetings



Work

Sprint

Tasks

The Team Meet Daily

Produce product

increment

Th T



The Team

• Cross-functional

• Self-Organizing

St k h ld



Stakeholders

Review• Prioritize

• Collaborate

• Serve

C d



Course agenda



• Sprint Planning


• Stand-up


Today

P d t b kl



Product backlog

• Items of highest value atthe top

•Prioritized by theproduct owner

•Estimated by the team

This is the

product backlog

This is the

product backlog

A prioritized list of requirements

A l d t b kl



A sample product backlog

Backlog item Estimate

Allow a guest to make a reservation 3As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a

reservation. 3

As a hotel employee, I can run RevPAR reports

(revenue-per-available-room)8

Improve exception handling 8

Bug #4334 – Improve error handling with… 1

Investigate PayPal integration 9

Common product backlog



Ideal Time

Calendar Time

Common product backlogestimating units

Ideal Time or Calendar Time



Ideal Time -or- Calendar Time

Ideal time

• The amount of time something is likely to take one

person if they aren’t disrupted or distracted• If two people will work on it, their time is added

• Often expressed in days (including ½ day, etc.)

Calendar Time

• Just old-fashioned guessing at the hours or days

something will take

Estimating the Product Backlog



Estimating the Product Backlog

• Use coarse-grained estimates for the

Product Backlog

• Think: “Days” or “Weeks”

Course agenda



Course agenda



• Sprint Planning


• Stand-up


Today

The Scrum Process



The Scrum Process

Sprint Planning Meeting Sprint Review/Sprint Retrospective

Sprint Planning



Sprint Planning

Team takes a subset of the product backlogand commits to delivering it for the sprint.

Sprint Planning



Sprint Planning

Objective

In Sprint Planning, the Team determines a list of features to bedeveloped in the current sprint.

Victory Conditions

They’ve defined a clear goals for the sprint

They’ve come up with a task-driven plan for achieving itThey can make a commitment to completing that plan

Sprint Planning

Description PlayersEquipment Rules: 1 Rules: 2

Sprint Planning



Sprint Planning

Equipment

1.5 to 2 sprint's worth of Product Backlog

Post-it notes / Whiteboard

Sprint Planning


Sprint Planning



Sprint Planning

Players

Team Members

Product Owner

Sprint Planning


Sprint Planning



Sprint Planning

Rules

• Determine theteam’s initialcapacity

• Get velocity usingyesterday’s weather

• Multiply by thenumber of days inthe sprint

• Adjust for knowncontingencies

Sprint Planning


Sprint Planning



Sprint Planning

27 hours1 day3 hoursEduardo

21 hours3 day3 hoursMichael

27 hours1 day3 hoursRita

27 hours1 day3 hoursAnne

TotalLess Vacations, Holidays, EtcBase

Hours

Name

Based on Yesterday’s Weather

Sprint Planning


Sprint Planning



Sprint Planning

Rules

• Select an item from the product backlog and

discuss

• Break down into tasks to complete the item

• Estimate amount of work for each task

• If team has capacity left, proceed with next

item; otherwise, stop – sprint planning is done

Sprint Planning


Sprint Planning



Sprint Planning

Rules

• Players volunteer for task

• Volunteer estimates task

• Estimate is subtracted from their bandwidth

• Don’t know enough to estimate? Spike

• Estimates are in hours, typically 2-4 hour tasks

Sprint Planning


Sprint Tasks: Yahoo! Example



Sprint Tasks: Yahoo! Example

Sprint Planning: Done



Sprint Planning: Done

Definition of “DONE” helps clarify goal

• Mockups, schemas to review• Usability results

• Fully tested and staged code

Sprint Planning Values andI i ht



Insights• Volunteering

• “Done”

• Yesterday’s Weather

• Improved predictability

• Humane work

• Team Commitment => taking a stance

• Who is involved / who is the team

• Declaring personal availability before accepting work so that you don’t feel like a bad-guy when you turn down work

• Self-empowerment

• Team alignment

• Time boxing

• Fixed : resource and time

• Estimate: Requirement/Value

Course agenda



Course agenda



• Sprint Planning


• Stand-up


Today



0

200

400

600

800

1,000

4 / 2 9

5 / 1 3

Tracking Progress

Tracking Progress



ac g og ess

Description

In Task Tracking, the Builders provide incremental

information about their progress, which is then

converted into a global picture of how well the team

is progressing.

Victory Conditions:

They know whether or not they can fulfill their sprint

commitments

A sprint burndown chart



A sprint burndown chart

H o u r s

Course agenda



g



• Sprint Planning


• Stand-up


Today



Sprin tsSprin ts

Sprints



p

During the sprint:

• Analysis

• Design

• Code

• Test

This is thesprint

This is thesprint

Always deliver



y

• Always deliver a potentially shippable

product increment at the end of each sprint

• Do not miss the end of the sprint

The deadline is sacred

Potentially shippable productincrement



increment

• High quality• Tested

• “Done”

Potentially shippable ≠ shippable

The scope of “done”



p

PlanningPlanning

AnalysisAnalysis

DesignDesign

CodingCoding

TestingTesting

PerformancePerformance

User AcceptanceUser Acceptance

PilotPilot

LiveLive

!!Extend the scope of

“Done” as far as possible

Defining “Done”



What does “Done” mean in your current project?What doesWhat does ““DoneDone”” mean in your current project?mean in your current project?11

What issues do you see with this definition of done?How would you address them?What issues do you see with this definition of done?What issues do you see with this definition of done?How would you address them?How would you address them?

22

What engineering problems do you see with thisapproach?

How would you rectify them?

What engineering problems do you see with thisWhat engineering problems do you see with thisapproach?approach?

How would you rectify them?How would you rectify them?

33

Pair with someone you donPair with someone you don’’t know.t know.

Turn to each other and share shortTurn to each other and share shortanswers to the following for 5 minutes:answers to the following for 5 minutes:

Sequential vs. overlappingdevelopment



development

Source: “The New New Product Development Game” by

Takeuchi and Nonaka. Harvard Business Review, January 1986.

Rather than doing all of

one thing at a time...

...Scrum teams do a little

of everything all the time

Queuing theory



Queuing Theory 101

Cycle Time as a Function of Utilization and Batch Size*

0

5

10

15

20

25

30

35

40

45

10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

C y c l e T i m e

( h o u r s )

Small Batches

Medium Batches

Large Batches

*This assumes batch size is proportional to variability.

Little’s Law



Total Cycle Time =Number of Things in Process

Average Completion Rate

• The long-term average number of customers ina stable system N, is equal to the long-term

average arrival rate, λ, multiplied by the long-term average time a customer spends in thesystem, T

N = λ T

• In other words:

Exercise 1



• Make teams of 5 people• 4 will operate

• 1 will measure (using chronometer)

• Put 20 cards face up in front of you

• Start the chronometer

• Move all cards to your neighbor and flip down all of the20 cards (one by one)

• When the 20 cards are moved, your neighbor move all

cards to his neighbor and flip up all the cards• Do it again … till the last member of the team

•Stop the chronometer

Exercise 2



• Make teams of 5 people

• 4 will operate

• 1 will measure (using chronometer)

• Put 20 cards face up in front of you

•Start the chronometer

• Move 1 card to your neighbor and flip down this card

• When 1 card is available for your neighbor, he takes it

and moves it to its neighbor and flip up this card• Do it again … till the last member of the team and the

last card

• Stop the chronometer

Discussion



• Compare the 2 results (duration)

• What is the fastest organization• Could you explain why?

• Don’t forget to use mathematics ☺

Large Batch generates long period of waiting

Average completion rate is similar (time to flip 4

times a card) but the number of things in process is

reduced

Deliver Fast



• Now, you know how to deliver fast

• Reduce Number of things in the Process

• Use SCRUM approach (short iterations)

• Reduce size of requirements

• Use MMF approach (see next section)

Reciprocal commitments



The business commits to leave

priorities alone during the sprint

No changes during a sprint



• What the team commits to—and what theproduct owner agrees to—during sprint

planning should be what is delivered

• We start with vague requirements. Our

understanding of those requirements is

refined during the sprint.

However, keep in mind that...



Average time to implementation



Week 1 Week 2 Week 3 Week 4

Sprint 1 Sprint 2

Average change is delivered 1½

sprints after being discovered.

…and delivered here.

…gets planned into this

sprint…

The Lesson

A change that is

identified here…

Reproduced with kind permission by Mike Cohn mountaingoatsoftware.com

Sprint length



• Most common lengths:

• 2-weeks, 4-weeks

•How long the business can go without changing its mind•Pick a length that spreads intensity appropriately

•Ability to reliably predict effort on tasks four weeks out

•Length of the overall release

•Amount of uncertainty on the project•The overhead of iterating

Factors to consider…

Sprint Length



• Keep the same sprint length for all your sprints.

• Don’t change length arbitrarily from one sprint to

another

• Be sure to run sprints back to back.

• Always end the sprint on time

• Promote regularity

• Establish a heartbeat

These Policies

Intensity varies over time



Months

I n t e n

s i t y

Months

Waterfall

Scrum

Sprints



Is there such a thing as an “analysis sprint” where

requirements are pulled together?

Is there such a thing as anIs there such a thing as an ““analysis sprintanalysis sprint”” wherewhere

requirements are pulled together?requirements are pulled together?

11

If a project requires a lot of infrastructure andarchitecture work that will take eight weeks to

complete, should the first sprint be eight weeks long?

Is the architecture an adequate deliverable?

If a project requires a lot of infrastructure andIf a project requires a lot of infrastructure andarchitecture work that will take eight weeks toarchitecture work that will take eight weeks to

complete, should the first sprint be eight weeks long?complete, should the first sprint be eight weeks long?

Is the architecture an adequate deliverable?Is the architecture an adequate deliverable?

33

Is there such a thing as a “testing sprint”?Is there such a thing as aIs there such a thing as a ““testing sprinttesting sprint””??22

Release Sprints



• Always target a potentially-shippable

product increment

• But, some polishing can occur in a releasesprint

Some stress, performance or usability testing

Compliance

Documentation touchups (final screen shots)

A Sprint Warning



Don’t let work slop over from

sprint to sprint and build up

Will this sprint finish on time?

350



M o n d a y0

50

100

150

200

250

300

T u e s d a y

W

e d n e s d a y

T h u r s d a y

F r i d a y

W

e d n e s d a y

M o n d a y

T u e s d a y

F r i d a y

T h u r s d a y

350

Course agenda





• Sprint Planning


• Stand-up


Today

Stand-Up



Stand-Up



The stand-up is..

• A 15 minute meeting• A forum for team members to

answer • What I did

• What I plan to do today• What is blocking me



• Understand what is in play

• Increase Collaboration

Why Stand-ups?

• Allows for efficient collaboration

• Demonstrate respect

Good Stand-ups:



Course agenda





• Sprint Planning


• Stand-up


Today

Sprint Review



Description

In the Sprint Review, the team demos the completedfeatures (and other products of the sprint) to allinterested parties.

Victory Conditions• Everyone understands where the product is andwhat it can do at this point in time

• Valuable feedback is acquired from Stakeholders

• Everyone has fun

Sprint Review



Equipment

• A functional product that was finished at the end of the sprint

• Demonstrable on a staging server

• Other work artifacts to demonstrate

Sprint Review



Players

• The Whole Team

• Developers, Testers, UED, etc

• Product Owner

• Any Stakeholder who is interested

Sprint Review



Rules

• Hold a 30 minute informal presentation

• Limit the prep time to 2 hours total

• Be careful not to do additional work justfor the review!

Course agenda





• Sprint Planning


• Stand-up


Today



Sprint Retrospective




Description

In the Sprint Retrospective, the Team takes

stock of what did and didn’t work during thelast sprint, and comes up with strategies to

improve their processes and development

methods.Victory Conditions

Inspect & Adapt




Players

• Team Members

• Builders

• Product Owner

• No Other Stakeholders!




Rules

• Typically 30-60 minutes

• Done after every sprint



Sprint RetrospectiveS tar t



S top

Con tinue

• Showing the software to customers early

• Specifying acceptance tests early and withcustomers

• Doing code inspections• Getting FitNesse into the nightly builds

• Trying to finish one story before moving to the

next

• Being disrespectful of QA

• Making progress with the canonical database

• Emphasizing test automation



Thank You!

Documents

Day1 CoreScrum Training