© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. Scrum for Teams 1 Notice: Much of this...

© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.

Scrum for Teams

1

Notice: Much of this content is the copyright of Pete Behrens, Agile Organization & Process Coachwww.trailridgeconsulting.com and is reproduced with permission.© Trail Ridge Consulting, LLC. and Leffingwell, LLC.

(rev 8 9_10)

http://www.trailridgeconsulting.com/

© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 2

Who are we?

PETE

= Product Manager, Product Owner, Business Owner

= Team member, Developer, Tester, Architect, Writer, UI Designer, etc.

= Project Manager, ScrumMaster, Functional Manager, etc.

Your Primary Role

Create a Table Tent Card representing you

Your Agile/Scrum ExperienceLess Experience More Experience

1

0 5

Blank = Other


IN PROCESS

DONE

TO DO

INTRO

SCRUMOVERVIEW

PRODUCTBACKLOG

USERSTORIES

PRIORITIZING SCRUM TEAM

SPRINT PLANNING SPRINT

TRACKINGSPRINT DEMO

SPRINTRETRO

RELEASESPRINT

Scrum Training Backlog

3

ESTIMATING


Before: Predictive Process Approach

1970 1980 1990 2000

Predictive Processes

Waterfall

Predictive, plan-based Process

Plan – measure – re-plan - repeatPr

oces

s

Inpu

ts

Out

puts

4


Predictive vs. Empirical Process

If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach

(measure and adapt) is the method of choice. - Ken Schwaber

Empirical (Adaptive) Process

Proc

ess

Controls

Inpu

ts

Out

puts

Plan – measure – re-plan - repeat

5


Scrum

6

Scrum is not a methodology

Scrum does not provide the answers to how to build quality software faster

Warning!


Scrum

Scrum is a framework within which the game of product development is played

How your team plays and how good or not-good it is becomes highly visible

Your team gets to continuously improve

7


Scrum Framework

Potentially Shippable Increment

Daily Standup

Two week Sprint

Solution, program, or

product backlog

Sprint commitment


Scrum Origins

The New, New Product Development

Game*Lean

Iterative, Incremental

Development, Time-boxes

Smalltalk Engineering Tools

Scrum

9


Scrum Origins

10

“The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”

Hirotaka Takeuchi and Ikujiro Nonaka,“The New New Product Development Game” Harvard Business Review, January 1986.


11© 2009 Trail Ridge Consulting, LLC

Exercise: Scrum Ball Game

11

Rules1.You are one big team

2.Ball must be touched by each person3.Ball must be passed with air time between any two people4.No ball may be passed to a direct neighbor5.Ball must return to start point before it is counted complete

• Your team has 2 min. to organize and begin your first sprint• Your team has 2 min. to complete the sprint• Your team will be asked to provide a ball completion estimate prior


Scrum Practice Overview

Collocated, cross-functional teams of 7(+/-2) develop software in short (2-3 wk) Sprints

Teams are self-organizing, self-managing, empowered and accountable

Each sprint delivers incremental, tested, user value. Work within a sprint is fixed. The ScrumMaster mentors the team All work to be done is carried as Product backlog Backlog is managed and prioritized by a Product

Owner, who is integral to the team A daily 15-minute stand-up meeting is a primary

communication mechanism Everything (Sprint, meetings, demos, etc.) is time

boxed Requirements, architecture, and design emerge in a

collaboration with stakeholders12


Scrum: Whole Team


Scrum Roles

Represents the stakeholder and customer community Develops and maintains the product backlog Prioritizes the product backlog Empowered to make decisions

Self-organizing Seven plus or minus two performers of mixed skills Responsible for estimating, committing to and delivering work Full autonomy and authority during a sprint

Oversees the process Responsible for maximizing team productivity Facilitates the meetings Removes impediments hindering team productivity

14


The Power of ba -

“Dynamic interaction of individuals and organization creates synthesis in the form of a self-organizing team.

The fuel of ba is its self-organizing nature – a shared context in which individuals can interact with each other.

Team members create new points of view and resolve contradictions through dialogue.

New knowledge as a stream of meaning emerges.

This emergent knowledge codifies into working software.

Ba must be energized with its own intentions, vision, interest, or mission to be directed effectively.

Leaders provide autonomy, creative chaos, redundancy, requisite variety, love, care, trust, and commitment.

Creative chaos can be created by implementing demanding performance goals. The team is challenged to question every norm of development.

Time pressures will drive extreme use of simultaneous engineering.

Equal access to information at all levels is critical. “

The energy that drives a self-organizing team

Source: New, New Product Development Game, Harvard Business Review, 1983

15


Scrum Planning

16

Product & Release Cycle

Sprint & Daily CycleRelease ScopeAnd Boundaries

ReleasePlanning

SprintPlanning

Develop& Test

Review&

Adapt

ReleaseVision

Drives

Feedback


A Product Backlog

17

Backlog Item Size Done1. Login portal 5 2. Display minutes 3 3. Support ticket call 8 4. Remote login help 13 5. Update profile 26. Buy more time 87. Single sign-on 208. Log rotation 59. Timer display 310. Automatic logout 111. Usage warning 212. Exchange 12 integration 1313. HP Openview API 2014. XML API 815. 300 logins/min 1316. Location tracking 517. Intrusion detection 1318. Update MySQL DB 2019. Update Web Stack 1320. Update Linux Kernel 821. Support Novel Auth 1322. Support RADIUS Auth 823. Scan & Block Int. 4024. AP Manager Int. 20

A simple planning and tracking tool


Scrum Heartbeat: Sprint

18

Sprint 1

Spr

int

Rev

iew

AnalysisDesign

Test Test Test

CodeIntegrate

Spr

int

Ret

rosp

ectiv

e

AnalysisDesign

CodeIntegrate

AnalysisDesign

CodeIntegrate

Scrum Scrum Scrum

Spr

int

Pla

nnin

g

Spr

int

Pla

nnin

g

Sprint 2…

AnalysisDesign

Test

CodeIntegrate

Scrum


Sprint Output: Potentially Shippable Product Increment

19

Full lifecycle on an increment of functionality

A thin vertical sliceof the product whichcontains all aspectsof the final product

Consumable - whole in every part

AnalysisAnalysis DesignDesign CodeCode TestTest DocumentDocument


Good news about Scrum

Scrum removes risk early Scrum can adapt to changing business priorities Scrum will drive earlier time-to-benefit by

implementing features throughout the project Scrum Increases ROI of a project & team throughput

by not developing features you don’t need Scrum improves employee satisfaction by sharing

responsibility Scrum Increases visibility throughout the

organization


Challenges with Scrum

Scrum is not a silver bullet Scrum will expose problems early Scrum requires team alignment, trust and

collaboration Scrum defines new roles and responsibilities Scrum will be successful only if the feedback it

generates is addressed


Scrum compresses the software development lifecycle

Analysis

Design

Development

Test

Deployment

Analysis

Design

Development

Test

Deployment

Traditional PhasedApproach

Scrum time-boxes the lifecycle

Handoffs

Delays

TaskSwitching

Lackof Ownership

Lackof Commitment

CompromisedQuality

Shared CommitmentShared OwnershipShared FocusMore ProductiveQuality Built In


Scrum and the team

DeveloperProd Mgr Tester Operations

Handoffs Delays

TaskSwitching

Lackof Ownership

Operations

DeveloperProd Mgr

Scrum Cross-functional Team

TraditionalTeam

Shared CommitmentShared OwnershipShared Focus

More ProductiveQuality Built In

Lackof Commitment

Designer

CompromisedQuality

Tester

Designer


A

Scrum Context

24

Need to Respond to

Change

Agile and LeanPrinciples

Scrum Practices


Key Agile Principles

1. Whole Team

2. Time-boxing

3. Adaptive Planning

4. Close Customer Involvement

5. Feedback Learning

6. Constant Systemic Testing

FOCUS


Principles of Lean Product Development Flow

1. Take an economic view

2. Actively manage queues

3. Understand and exploit variability

4. Reduce batch sizes

5. Apply WIP constraints

6. Control flow under uncertainty - cadence and synchronization

7. Get feedback as fast as possible

8. Decentralize control

26

Reinertsen, Principles of Product Development Flow, 2009.


Lean Thinking Reduces Waste

– Inventory

– Extra Processing

– Overproduction

– Transportation

– Waiting

– Motion

– Defects

27

– Undelivered, untested reqs & code

– Process overhead

– Extra features

– Task switching, handoffs

– Waiting for reqs, code, tests, reviews

– Task switching, Handoffs

– Defects

Poppendieck. LLC 2004

Manufacturing Software


Exercise: Batch Size, Flow & Pull

28

1. CREATE A 4-PERSON PROCESS2. EACH PERSON FLIPS ALL PENNIES ONE AT A TIME AND RECORDS RESULTS3. PASS ALL PENNIES AT ONCE TO

THE NEXT PERSON4. RECORD TIME FROM START TO

END

Batch push system


Exercise: Batch Size, Flow and Pull

29

Small lot pull system

1. SAME 4-PERSON PROCESS2. EACH PERSON FLIPS EACH PENNY

AND RECORDS RESULT3. PASS EACH PENNY AS FLIPPED4. TIME FROM START TO FIRST PENNY

AND ALL PENNIES END


• A mfg defect is discovered on the third penny at station 4. • It requires 10 sec. of rework at station 3• How much rework is required in push vs. pull? Processed

Unprocessed

1 2 3 4

Bad penny discovered

Bad penny discovered

Push

Pull

Exercise: Rework


Scrum works with XP practices

User Stories

CollectiveOwnership

CodingStandards

SustainablePace

ContinuousIntegration

Whole Team

ReleasePlanning

Small Releases

Customer Tests

EmergentDesign

PairProgramming

Test-DrivenDevelopment

AutomatedTesting

Adapted fromxprogramming.com

http://www.extremeprogramming.org/index.html


Caution

Scrum is not a methodology - Scrum does not provide the answers to how to build quality software better

Scrum is based on the hypothesis that there is no meta-solution for software development - just a framework within which we will can empirically to inspect and adapt

This can be very frustrating to those looking for clear procedures and final answers


IN PROCESS

DONE

TO DO

INTRO SCRUMOVERVIEW

PRODUCTBACKLOG

USERSTORIES

ESTIMATING

SCRUM TEAM


TRACKINGSPRINT DEMO

SPRINTRETRO

RELEASESPRINT


PRIORITIZING


34

The Product Backlog

The To Do List !

Hang Pictures

Fix Closet Door

Change Light Bulbs

Replace Furnace Filters

Change Light Switch

Hang Shelving

Repair Furniture

Fix Garden Hose

Clean Garage

Take Garbage to Dump!

Paint Kids Rooms

Product Backlog:

A prioritized list of remaining work

34


The Product Backlog

The family portrait picture shall hang on the living room south wall 3’6” from the ceiling and 5’8” from the west wall using a 2p nail at a 45 degree angle toward the floor.

The picture shall hang horizontally level with the ceiling.

The picture shall hang with the people upright.

Does your To Do list look like this?

Hang Pictures

35


Traditional Approach

Detailed RequirementSpecifications and Planning

Detailed Project Planning and Tracking

36


The Product Backlog

A Backlog is used for:

Planning

AND

Tracking

Hang Pictures

Fix Closet Door

Change Light Bulbs

Replace Furnace Filters

Change Light Switch

Hang Shelving

Repair Furniture

Fix Garden Hose

Clean Garage

Take Garbage to Dump!

Paint Kids Rooms

37


Backlog Items are Right-sized

Feature Requirement Task

Backlog Item

VagueHigh-level

SpecificLow-level

Right-sized

Clean GarageSpring Cleaning

Rake Lawn

Wash Windows

Clean North Kitchen Window

Spray on WindexWipe off Windex

Remove Screen

Repeat Outside

Replace Screen

Clean South Kitchen Window

38

Epic


The Product Backlog

Backlog Item Size Done1. Login portal 5 2. Display minutes 3 3. Support ticket call 8 4. Remote login help 13 5. Update profile 26. Buy more time 87. Single sign-on 208. Log rotation 59. Timer display 310. Automatic logout 111. Usage warning 212. Exchange 12 integration 1313. HP Openview API 2014. XML API 815. 300 logins/min 1316. Location tracking 517. Intrusion detection 1318. Update MySQL DB 2019. Update Web Stack 1320. Update Linux Kernel 821. Support Novel Auth 1322. Support RADIUS Auth 823. Scan & Block Int. 4024. AP Manager Int. 20

39


Prioritizing the Backlog

Who prioritizes the backlog?

Product Owner

Stakeholders

Customers

What do they prioritize the items on?

Economics of Cost of Delay1

Risk Reduction

Why do they prioritize the backlog?

So the team delivers the most valuable solutions and receives the most valuable feedback as early as possible

40

1Principle of Product development Flow E3: If you only quantify one thing, quantify the cost of delay− Reinertsen 2009


Exercises: Product Backlog

BRAINSTORM BACKLOG ITEMS THAT ADDRESS YOUR VISION

ORPROBLEM CONTEXT

Acceptance Criteria: - 10-15 Backlog items

41


IN PROCESS

DONE

TO DO

INTRO SCRUMOVERVIEW

PRODUCTBACKLOG

USERSTORIES

ESTIMATING

SCRUM TEAM


TRACKINGSPRINT DEMO

SPRINTRETRO

RELEASESPRINT


42

PRIORITIZING


Requirements: A Communication Problem

Those who want software must communicate with those who build it

Business and technical language translation required

It is our job to speak in the language of the business


Team Communication

Cold Hot

Com

mun

icat

ion

Effe

ctiv

enes

s

DocumentationOptions

ModelingOptions

Videotape

EmailConversation

Audiotape

Paper

PhoneConversation

VideoConversation

Face-to-faceConversation

Face-to-faceAt whiteboard

44


What is a User Story?

User Stories represent customer requirements

rather than document them

User Stories are a tool for writing backlog items


User Story: The 3 C’s

Card– Written on card or in tool

and may annotate with notes

Conversation– Details in conversation

with product owner

Confirmation– Acceptance tests confirm

the story correctness

What about the bikes?

Oh yeah, hang the bikes

As a spouseI want a clean garage

so that I can park my car and not trip to the door

• Put tools away• Straighten the shelves• Sweep the floor• Hang the bikes

46


As a network supplier, I can view usage by store so that I can bill shop

owners

User Story Examples

As a shop customer, I can

sign up for internet access so

that I can work online

As a shop owner, I can customize the portal so that I can

promote my business

As a frequent customer I can automatically

login upon return so that I can

speed my entry

47


User Story Template

As a <role>I can <activity>

So that <business value>

48


User Stories…

Are NOT Requirements or Use Cases

Are a planning and tracking tool

Can reference Requirements and Use Cases

49


INVEST in a Good Story

INVEST acronym created by Bill Wake

I

N

V

E

S

T

50


User Stories are Independent

Analysis Design Coding TestingActivity

Functionality Feature Feature Feature

Module Module Module

Do not break stories in a Work Breakdown Structure

Story 1 Story 2 Story 3 Story 4Functionality

Activity Analysis Design Coding

A Story includes an entire slice of functionality

Testing

Define the project plan in terms of what will be deliveredrather than what work steps will be performed.

51


User Stories are Independent

Write closed stories Slice through the architecture (vertical) Write only the delta (the change)

As a Salesperson, I can send a mass email based on an email

template to all of my leads and if there are more than 100 leads

the view will allow paging so that I can quickly email large

numbers of leads.

As a Salesperson, I want to paginate my leads when I send

mass emails so that I can quickly select a large number of leads.

Overly complicated with existing functionality and

acceptance criteria

Focused story on the change to the system

52


User Stories are Negotiable

User Stories are not contracts or detailed requirements

Too much detail gives impression of false precision or completeness

Flexibility drives release schedule and goals

53


User Stories are Valued by Users

Write stories in the voice of the customer Write for one user

We need a design for making sure that packages don't

get corrupt during the push install process, and if errors occur that we can

recover gracefully.

As an administrator, I want to be alerted if there are any

corruptions in upgrade packages installed.

As an administrator, I want to be able to gracefully

recover from any corrupt upgrade packages.Developer voice and value

User voice and value

54


User Stories are Estimatable

55

User Stories are for planning and tracking

– To measure release progress, each story needs an estimate of size

Estimating may be difficult because…

– Developers lack the domain knowledge to know what is to be done

– Developers lack the technical knowledge to know how to do something

– The story is too big or vague


User Stories are Small

Complex Problem Compound Problem

TechnicalSpike

FunctionalSpike Split Story

56


SPIKE Complex Stories

As a Very Large Organization (VLO) Administrator, I want my administrative screens to work

effectively with tens of thousands of managed entities

so that I can do my job

SPIKE: Create VLO dataset, evaluate screens and

identify areas to improve

SPIKE: Evaluate alternative indexing schemes and

report on performance

Functional Complexity

As a VLO Salesperson, I want to my search results to return

quickly so that I can find relevant contacts for the

information I am searching

Technical Complexity

SPIKE: Evaluate alternative hardware solutions and report on impact and

performance

57


SPLIT Epic (Large) Stories

As a cashier, I can view inventory levels in Point of Sale (POS) and Back Office System (BOS), which reflects up to the minute

information from my store and other stores, so that I can get them the product they want.

Back Office Inventory

(BOS) Transactions

Point of Sale(POS) Transactions

PO, DSD, and ASN Receiving

Transactions

Transfer OutTransactions

Transfer, Carton, and Manifest

Receiving Transactions

Return to Vendor

Transactions

Regular Sale

Transactions

Miscellaneous

Transactions

58


Splitting User Stories

1. Workflow Steps

2. Business Rule Variations

3. Major Effort

4. Simple/Complex

5. Variations in Data

6. Data Entry Methods

7. Defer System Qualities

8. Operations

9. Use Case Scenarios

10.Break Out a Spike

59


User Stories are Testable

Write stories that are testable Include Acceptance Criteria for each story

As a VLO Salesperson, I want to my search results to return quickly so that I can find relevant contacts for the information I am searching

Not testable

As a VLO Salesperson, I want to receive the first page of

search results within 3 seconds so that I can find relevant contacts quickly

Testable

60


A Story-Writing Workshop

Involve users – don’t ask them

– Users may not know whatthey want or need

– Users don’t communicatethese needs effectively

Include the whole teamin story writing

– Developers, users, testers, writers, etc.

– Everyone can write stories

Estimate and prioritize stories later

61


Exercise: User Stories

62

AS A STAKEHOLDER,I WANT TO REFINE THE

PRODUCT BACKLOGSO THAT I CAN MAKE SURE IT MEETS MY

USERS NEEDS

Acceptance Criteria: - Each backlog item (10-15) is stated as one or more user stories - Changes (new, changed, removed) stories expected


Acceptance Testing

Card– Written on card or in tool

and may annotate with notes

Conversation– Details in conversation

with product owner

Confirmation– Acceptance tests confirm

the story correctness

What about the bikes?

Oh yeah, hang the bikes

As a spouseI want a clean garage

so that I can park my car and not trip to the door

• Tools are put away• Shelves are

straightened • Floor is swept• Bikes are hung

63


Exercise: Acceptance Criteria

As a TEAM,we want to establish the acceptance criteria for

each story so we’ll know when we’ve completed it

Acceptance Criteria: - 2 user stories have an acceptance criteria agreed to by the team

64

Instructions: - Write your story on the front of a large sheet- On the back of the sheet, write the acceptance criteria for the story


IN PROCESS

DONE

TO DO

INTRO SCRUMOVERVIEW

PRODUCTBACKLOG USER

STORIES

ESTIMATING

SCRUM TEAM


TRACKINGSPRINT ENDING

CLASSRETRO

RELEASESPRINT


65

PRIORITIZING


Estimating User Stories

Size

Cal

cula

tion

Duration

240Miles Sp

eed

60 M

PH

4Hours

Examples

180 StoryPoints Ve

loci

ty

30 S

P/Sp

rint

6Sprints


Story Points

Story Point size represents

– Complexity – How hard is it?

– Volume – How much is there?

– Knowledge – What do we know?

– Uncertainty – What’s not known?

Unitless but numerically relevant Relative values important

– Triangulate with other stories

– An 8-point story should expect to take twice as long as a 4-point story

1 1

24

8

67


Story Points vs. Ideal Days

Story Points Pros

– Pure measure of size

– Requires true velocity project completion

– Drive collaboration

– Faster to estimate Cons

– More abstract

– People not use to them

Ideal Days (Real Time) Pros

– We have always done it this way

– Executives want dates anyway

Cons– Everyone’s ideal (and

real) day is different

– Leads to unrealistic ideal schedule & commitments

– More emotional process68


Team-based Estimation

69


Estimation Technique:Team Estimation

Increases accuracy Builds understanding Drives commitment

Traditional estimation performed by a manager, architect or select group negates these benefits

70


Estimation Technique:Point Values

XP Keep them Small and Simple– 1,2, 4 split

Mountain Goat Modified Fibonacci– 0,½,1,2,3,5,8,13, [20,40,100] Epics

T-Shirt Sizes (Not recommended)– Small, Medium, Large, X Large

Things to consider– How do you distinguish between 14 and 15?

– Difficulty if over one order of magnitude

71


Exercise - Estimation

Assign “dog points” to each of the following types of dog to compare their “bigness”

– Labrador Retriever

– Dachshund

– Great Dane

– Terrier

– German Shepherd

– Poodle

– St. Bernard

– Bulldog

Table LayoutTechnique

72


Planning poker combines expert opinion, analogy, and disaggregation for quick but reliable estimates.

Participants include all team members The product owner participates, but does not

estimate Each estimator is given a deck of cards with 0,

1, 2, 3, 5, 8, 13, 20, 40, 100, and ?

For each story or theme to be estimated, product owner reads the description

Questions are asked and answered Each estimator privately selects a card

representing his or her estimate. All cards are simultaneously turned over so

that all participants can see each estimate. High and low estimators explain their

estimates. After discussion, each estimator re-estimates

by selecting a card The estimates will likely converge. If not,

repeat the process Some amount of preliminary design discussion

is appropriate . However, spending too much time on design discussions is often wasted effort.

Estimating Poker

Cohn. Agile Estimating and Planning

Description and Setup Estimating Process

73


Exercise: Estimation

AS A DIRECTOR,I WANT TO KNOW THE MAGNITUDE OF THE

SOLUTION CONTEXT SO THAT I CAN PROJECT

COSTS AND TIME

Acceptance Criteria: - Each user story is estimated relative to the other stories - Each user story has a number representing its size

74


Some Questions on Estimation

How do we estimate uncertainty?

How much time should we spend estimating?

How accurate do estimates need to be?

When do we estimate?

75


How much time should we spend on estimating?

A little effort helps a lot A lot of effort only helps a little

50%

100%

Acc

ura

cy

Effort

Don’t IgnoreUncertainty

Source: Agile Estimating and Planning by Mike Cohn


How accurate do our estimates need to be?

First, don’t try to worry about it too much

– We’re usually better off with fairly rapid, imprecise estimates than spending more time

Second, leverage averages

– Just add up the components and report one total estimate

= 13

= 13

= 13

77


IN PROCESS

DONE

TO DO

INTRO SCRUMOVERVIEW

PRODUCTBACKLOG USER

STORIES

SCRUM TEAM


TRACKINGSPRINT DEMO

SPRINTRETRO

RELEASESPRINT


78

ESTIMATING

PRIORITIZING


Prioritizing Work - An economic approach

To prioritize based on economics, we need to know two things

1. What is the Cost of Delay (CoD) in delivering value

2. What is the cost to implement the value thing

79

Principle of Product Development Flow E3: If you only quantify one thing, quantify the Cost of Delay.

-- Reinertsen 2009. Principles of Product Development Flow: Second Generation Lean Product Development


Feature Time(Effort)

Cost of Delay

A 1 3

B 3 3

C 10 3

Time

C

Time

Cost of Delay

C

B

A

Longest Job First

Shortest Job First

Cost of Delay

3

1

A

B

1 Delay Cost

When the cost of delay is equal, do the Shortest Job First

CoD Economics: Shortest Job First (SJF)



Cost of Delay

A 3 10

B 3 3

C 3 1

Time

Time

Cost of Delay

Low Delay Cost First

High Delay Cost First

Cost of Delay

3

A1 Delay Cost

1B

C

1

AB

C

CoD Economics: High Delay Cost First (HDCF)

When the effort is equal, do the high CoD job first



Cost of Delay

Weight= CoD/Effort

A 1 10 10

B 3 3 1

C 10 1 .1

Time

Time

Cost of Delay

Low Weight First

High Weight First

Cost of Delay

3

A1 Delay Cost

1 B

C

BC

A

CoD Economics: Weighted Shortest Job First (WSJF)

When nothing is equal, do the Weighted Shortest Job First! (CoD/Effort)


Cost of Delay Components

User Value–The relative, potential value of the story or feature in the eyes

of the customer. “They prefer this over that”.

Time Value–How does this user value decay over time. Is there a fixed

deadline? Will they wait for us or move to another solution? What is the effect on customer satisfaction while they don’t have it?

Risk Reduction Value– How does this item help us reduce the risk of the project or

program? Is there value to us in the information we will receive?

83


WSJF Prioritization Matrix

84

WSJF Priority = Cost of Delay/Effort

In general, do the Weighted Shortest Job First! (CoD/Effort)


Exercise: Prioritizing Work

AS A TEAM,We want to prioritize our work to achieve the best economic outcomes for

our stakeholders

Acceptance Criteria: - Use the WSJF estimating method to prioritize the user stories you estimated

85


IN PROCESS

DONE

TO DO

INTRO SCRUMOVERVIEW

PRODUCTBACKLOG USER

STORIES

ESTIMATING

SCRUM TEAM


TRACKINGSPRINT DEMO

SPRINTRETRO

RELEASESPRINT


PRIORITIZING


Teamwork

"It is amazing what can be accomplished when nobody cares about who gets the credit." - Robert Yates (NASCAR)

87


Roles in Scrum

The single customer voice who sets vision, prioritizes work and defines acceptance

The process facilitator who empowers the team and removes impediments

The people who deliver the customer value through architecture, design, code, test, doc

Those with a stake in the project but without direct impact on the solution - executives

ProductOwner

DevelopmentTeam

ScrumMaster

Stakeholders

89


Role Collaboration

CustomerTeam

DevelopmentTeam

StoryCreation

StoryPriority

StoryAcceptance

ProductOwner

ScrumMaster

Scrum Role Relationships

ProductVision

Story Conversation

Stakeholders

Stakeholders

90


Roles: Product Owner

Establishes and shares the vision

Provides a single voice for the customer and stakeholder

Prioritizes the Product Backlog

Accepts user stories into the baseline (QA role)

Makes the hard calls

Member of the team

91


Roles: ScrumMaster

Ensures team follows the principles and practices of Scrum

Facilitates the process and meetings

Removes obstacles and barriers between team and others

Protects the team from external forces

Coaches the team

Works with other ScrumMasters to coordinate solution delivery

92


Ideal Scrum Team

7 +/2 members maximum

Developer Developer Developer Tester

TesterDeveloperProduct Owner

Tech

nic

al

Inte

rfac

eArchitect

Tech lead Scrum / Agile Master

Team

of

Team

In

terf

ace

QA/Release Mgt

93

DefineBuildTest

DefineBuildTest

DefineBuildTest

DefineBuildTest

Characteristics• 7 ± 2 members• Co-located• Dedicated• Focused• Cross-functional• Self-organizing


Example Shared Team Area


Basic Truths about Teams

Teams are more productive than the same number of individuals

Broad-band face-to-face communication is the most productive way for teams to work together

Teams and people do their best work when they are not interrupted

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

Changes in team composition negatively impacts productivity

95


The Five Dysfunctions of a Team

96

Inattention to Results

Avoidance of Accountability

Lack of Commitment

Fear of Conflict

Absence of Trust

Source: the Five Dysfunctions of a Team , Lencioni


Basic Truths about Teams

Teams are more productive than the same number of individuals

Broad-band face-to-face communication is the most productive way for teams to work together

Teams and people do their best work when they are not interrupted

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

Changes in team composition negatively impacts productivity


Teamwork

Remains the ultimate competitive advantage

however,

most teams are dysfunctional

98


Five Dysfunctions of a Team

Source: Five Dysfunctions of a Team, Patrick Lencioni

Absence of

Trust

Fear of

Conflict

Lack of

Commitment

Avoidance of

Accountability

Inattention to

Results

99


Identifying Trust

Teams with an absence of Trust

Conceal weaknesses and mistakes from one another

Hesitate to ask for help or offer help outside their area of responsibility

Jump to conclusions about the intentions and aptitudes of others without attempting to clarify them

Waste time and energy on managing behaviors for effect

Dread meetings and find reasons to avoid spending time together

Trusting Teams

Admit weaknesses and mistakes

Ask for help and accept questions and input about their area of responsibility

Give one another the benefit of the doubt before arriving at a negative conclusion

Focus time and energy on important issues, not politics

Look forward to working as a group

Take risks on offering feedback


100


Building Trust

Human Resources approach

– Personal history exercise

– Team effectiveness exercise

– Personality profiles

– 360-Degree feedback

– Experiential team exercises

OR, commit to short focused goals where you focus on results and build trust through work

– Also, as a leader, support and show vulnerability


Identifying Conflict

Teams that fear conflict…

Have boring meetings

Create environments where back-channel politics and personal attacks thrive

Ignore controversial topics that are critical to team success

Fail to tap into all the opinions and perspectives of team members

Waste time and energy with posturing and interpersonal risk management

Teams that engage in conflict…

Have lively, interesting meetings

Minimize politics

Put critical topics on the table for discussion

Extract and exploit the ideas of all team members

Solve real problems quickly

102Source: Five Dysfunctions of a Team, Patrick Lencioni


Fear of Conflict

Separate ideological from personal conflict– Focus on concepts and ideas, not people and personalities

Purpose is to create the best possible solution in the shortest period of time

Acknowledge that conflict is productive– Rather than allow issue to continually resurface

Leader must mine for conflict and draw it out

Leader must create environment that supports healthy disagreements

103


Identifying Commitment

A Team that fails to commit…

Creates ambiguity among the team about the direction and priorities

Watches windows of opportunity close due to excessive analysis and unnecessary delay

Breeds lack of confidence and fear of failure

Revisits discussions and decisions again and again

Encourages second-guessing among team members

A Team that commits…

Creates clarity around direction and priorities

Takes advantage of opportunities before competitors do

Aligns the entire team around common objectives

Develops an ability to learn from mistakes

Moves forward or changes direction without hesitation or guilt



Causes for Lack of Commitment

Lack of Consensus– Teams don’t routinely seek consensus

– Confusion between consensus and unanimous decision

– Need: Must rally around (buy-in) final decision

Lack of Clarity– Dysfunctional teams hedge their bets and delay important

decisions

– Better to make a decision boldly and be wrong than to waffle

– Conflict underlies willingness to commit without perfect information

105


Gaining Commitment

Review key decisions made in meetings Use deadlines Contingency planning

– What is the result of a missed commitment?

Allow for, and review failure Practice!

106


Identifying Accountability

A Team that avoids accountability…

Creates resentment among team members who have different standards of performance

Encourages mediocrity

Misses deadlines and key deliverables

Places an undue burden on the team leader as the sole source of discipline

A Team that is accountable to each other…

Ensures that poor performers feel pressure to improve

Identifies potential problems quickly by questioning one another’s approaches without hesitation

Establishes respect among team members who are help to the same high standards

Avoids excessive bureaucracy around performance management and corrective action


107


Gaining Accountability

Most effect way to gain accountability is through peer pressure

Create peer pressure through…

– Publication of goals and standards

– Simple and regular process reviews

– Team rewards

Management controlled accountability is a negative re-enforcing loop


Identifying Results

A Team not focused on results…

Stagnates and fails to grow

Rarely defeats competitors

Loses achievement-oriented employees

Encourages team members to focus on their own careers and individual goals

Is easily distracted

A Team focused on results…

Enjoys success and suffers failure acutely

Retains achievement-oriented employees

Minimizes individualistic behavior

Benefits from individuals who subjugate their own goals/interest for the good of the team

Avoids distractions



Achieving Results

Leader must set the tone with the focus on results

– Publicly declare results

– Create rewards for results

Avoid team or individual status

– Focus on status will distract the team away from their primary goal

– Only evaluate status as information in meeting the goal


Scrum and the Five Dysfunctions

111

Inattention to Results

Avoidance of Accountability

Lack of Commitment

Fear of conflict

Absence of Trust


Exercise – Five Dysfunctions

112

Sit down with your team, and perform a self-assessment of the Five Dysfunctions of a Team using the template in the appendix.

What areas of for improvement do you see?


Exercise: Self-organization

You are the ScrumMaster. Everyone on the team except John meets with you. They tell you that John is not doing his work, is offensive, is difficult to work with, and they want you to fix the problem.

What do you do?

113


Agile Leadership Example

1. Review the article “Leadership as a Task, Rather than an Identity, provided in the appendix

2. Underline any sentences that you find interesting or thought provoking

3. Be ready to share your thoughts

Source: Harvard Business Review article "Leaderships Online Labs" - May 2008 by Byron Reeves, Thomas W. Malone, and Tony O’Driscoll

114


The Surprising Truth About What Motivates Us

http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=youtu.be

115

AMP

http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=youtu.be


IN PROCESS

DONE

TO DO

INTRO SCRUMOVERVIEW

PRODUCTBACKLOG USER

STORIES

ESTIMATING

SCRUM TEAM

SPRINT PLANNING

SPRINT TRACKING

SPRINT DEMO

SPRINTRETRO

RELEASESPRINT


116

PRIORITIZING


Scrum Planning

Product & Release Cycle

Sprint & Daily CycleRelease ScopeAnd Boundaries

ReleasePlanning

SprintPlanning

Develop& Test

Review&

Adapt

ReleaseVision

Drives

Feedback

117


Sprint Cycle

Dai

ly S

crum

Dai

ly S

crum

Dai

ly S

crum

… Dai

ly S

crum

Spr

int

Pla

nnin

g

Spr

int

Ret

rosp

ectiv

e

Dai

ly S

crum

Dai

ly S

crum

Dai

ly S

crum

…

Spr

int

Pla

nnin

g

Sprint 3 Sprint 4

Release

Spr

int

Rev

iew

…

118


Sprint Meeting Calendar

Day 1 Day 2-9 Day 10

Iteration planning Daily standup Daily standup

Define, design, develop, test,

accept

Demo

Iteration commitment

Retrospective

Iteration n: two weeks

Day 6Mid iteration

review

Prioritize and elaborate backlog

Iteration n-1

Routine meeting schedules simplify planning, management, and assessment

119

Story Preview?


Exercise: Cadence and Synchronization

AS A TEAM,WE WANT TO KNOW WHEN AND WHERE

WE’LL MEET IN ORDER TO REDUCE MEETING PLANNING OVERHEAD

Acceptance Criteria: - Team has identified the place, time and format for each sprint meeting.

120


DAY 1 Sprint Planning and Commitment

Present Iteration Objectives and Story Backlog to Team

Team designs, bids stories, takes responsibility

Negotiation and finalization

Commitment

Product Owner Team

121


Sprint Planning

GOAL Define and commit to what will be built in the sprint time-box

PROCESS Product Owner defines WHATScrum Team defines HOW

RESULT Sprint Backlog of theTeam’s Commitment

122


Sprint Planning:Creating and estimating tasks

1. Login portal2. Display minutes3. Support ticket call4. Remote login help5. Update profile6. Buy more time7. Single sign-on8. Log rotation9. Timer display10. Automatic logout11. Usage warning

Product Backlog

Sprint Backlog

Team Capacity


Sprint Planning

124


Sprint Backlog: The Task Board

Story Tasks To Do In Process Done Hours

As a user, I can… 8



Code the… 8

Code the… 6

Test the… 12

Code the… 4

Test the… 7

Code the… 16

Test the… 8

Code the… PB 3

Test the… GC 2

Code the… ML 6

Code the… JH 1

Code the… JH 0

64

47

23

TestsReady


Sprint Planning Meeting

Prioritize the product backlog prior to meeting Creating the Sprint Backlog

– Take the highest priority story

– Identify all tasks for that story to be implemented

– Estimate hours for each task

– Team decides if it can commit to complete story

– Repeat for the next story Guidelines

– The whole team < 4 hours

– Estimate tasks collaboratively in hours (1-16)

– Team decisions, team ownership126


Sprint Goal

A short statement of the objective for the sprint Increases clarity and commitment for the team Communicates intent to management Provides flexibility in how the goals are achieved

127


Example: Objectives and Prioritized Iteration Backlog

Objective 1 - Update and Support Beta 1.1.41

– Finalize and push last name search

– Finalize and push first name morphology

– Add request an invitation (see Rally)

– GUI/login nits and nats (see defect list)

– Augmented user tracking

Objective 2 - Version 1.2 Index 75%

– Get balance of 80% data to Canada

– Start new code development on EC2 Objective?

– Full text indexing (part 3 of 4). Objective:

– Develop Quofile Storyboard for 0.9

Other Stories

– Establish search replication validation protocol

– Refactor artifact dictionary schema

– Affiliates II (depending on what we discover tomorrow)

– Search layer optimization/testing continues

This iteration has two objectives. One to support the released product, the

second for new development

Actual stories are in repository , or just await discussion with the team – these are the priorities

Misc stories from the backlog, in priority

order

128


Exercise: Sprint Planning

AS A PRODUCT OWNER

I WANT TO STATE THE OBJECTIVES FOR OUR

FIRST SPRINT SO WE’LL KNOW HOW TO

EVALUATE OUR RESULTS

Acceptance Criteria: - The team has stated an objective for their first real (not exercise) sprint

129


Sprint Commitments

Team pulls in work for the sprint Identify all tasks to complete a

story (dev, test, doc, build, etc.) Team decides how much to take

RECIPROCAL COMMITMENTS Team commits to delivering

some amount of functionality

Business commits to leavepriorities alone during the sprint

130



AS A TEAM MEMBER,I WANT TO KNOW THE TASKS REQUIRED TO

COMPLETE A STORY SO I KNOW WHETHER I CAN COMMIT TO IT IN THE

SPRINT

Acceptance Criteria: - The team has identified the tasks for one real story - The team has estimated the time for each task

131



AS A TEAM,I WANT TO PLAN THE

EXERCISE SPRINT SO WE CAN LEARN FROM THAT

EXPERIENCE

Acceptance Criteria: - Team has a plan for the exercise sprint

132

Instructions: - At the end of the day, your team will execute a 20

minute exercise sprint - Using the class handout, plan how you will

execute the exercise sprint.


IN PROCESS

DONE

TO DO

INTRO SCRUMOVERVIEW

PRODUCTBACKLOG USER

STORIES

ESTIMATING

SCRUM TEAM SPRINT

PLANNING

SPRINT TRACKING

SPRINT DEMO

SPRINTRETRO

RELEASESPRINT


133

PRIORITIZING


Day 2─5 Implementing

15 Minute standup

Team designs, implements stories

Story elaboration, communication,

negotiation

Meet afterProduct Owner

134


Scrum Heartbeat: Sprint

Sprint

Spr

int

Rev

iew

AnalysisDesign

Test Test Test Test

CodeIntegrate

Spr

int

Ret

rosp

ectiv

e

AnalysisDesign

CodeIntegrate

AnalysisDesign

CodeIntegrate

AnalysisDesign

CodeIntegrate

DailyScrum

DailyScrum

DailyScrum

DailyScrum

Spr

int

Pla

nnin

g

135


Open Environment, Constant Communication

136


Big Visual Story Board

137

Not Started In Process Done Accepted

dsds

Wednesday Thursday Friday Monday MondayTuesday ThursdayWednesday Friday Tuesday

dsds

dsds

dsds

dsds

dsds

dsds

dsds

dsds

dsds

dsds

dsds


Track Sprints at the Story Level

138

• The cards are story proxies for visual use. • Actual stories in agile project management tool, along with tasks, estimates,

attachments, acceptance criteria• Each story has a “chief engineer” whose job is to understand the state of the story,

and move it along as appropriate in both places

One teams Big, Visual Information Radiator (BVIR)

Burn down

Definition of done

Story states

“today” indicator


Sprint Tracking Through Using the Task Board

139


Scrum team in an enterprise setting

140

Modular team

workspace


Iteration Status with “Burndown Charts”

Spreadsheet

Courtesy Trailridge Consulting, LLC

141

Manual

141


With Tooling Automation

Broken Build

Story Status

Burn down

142142


An XP shops “Wall of Truth”

143


DAY 2-9 Daily Scrum

144


Daily Scrum

Guidelines

– Daily - 15 minutes - Stand up – For the team

– Issue & dependency identification, not solving

– Team review of commitment each day

Questions

– What did you do yesterday?

– What will you do today?

– What’s in your way?

THIS IS NOT STATUS MEETING FOR MGMT

Will we still achieve ourSprint goal?

145


Managing the Sprint Backlog

No upfront task assignment

– Individuals sign up for tasks as available

Team self manages interdependencies Re-estimate work remaining daily

– Team can add, delete or change tasks as necessary

146


Exercise: Daily Scrum

Acceptance Criteria: - A daily Scrum executed by each team - Using real yesterday, tomorrow, and roadblocks relative to your current real projects

AS A TEAM MEMBER,I WANT TO KNOW

WHETHER WE ARE STILL ON TRACK TO MEET OUR

SPRINT GOAL SO WE CAN ADJUST ASAP

147


Example: Teams Standup Ground Rules

148

Be on-time and prepared for meetingLeave Blackberry at cube or tucked away (it is only 15 minutes)

Go through the three questionsWhat did I do yesterday?What will I do today?What is in my way?

Save comments and questions until after the three questions are discussed by each team memberNo personal attacks (that just ‘aint right!)Stay focused on the Sprint ObjectivesDeep discussions and design take off line.Clothing optional and hugs acceptable if approved in advance by team member. (just jokes) Always refer to the Stories/Backlog items in discussions.Know when it is your turn to listen, not speak. One speaker at a time.If you are feeling and not thinking, take a moment.Callout approval when Ground Rules are being broken.Have Fun, Get it Done!


Ana

lysi

s

Cod

ing

Test

ing

Ana

lysi

s

Cod

ing

Test

ing

CodingAnalysis

Execution: Don’t Waterfall Sprints

Analysis Coding TestingAnalysis

CodingTesting

Testing

This is an inter-sprint waterfall

Ana

lysi

s

Cod

ing

Test

ing

This is a intra-sprint waterfall

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

These are cross-functional sprintsSprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

A C TA C T

A C T

A C TA C T

A C T

A C TA C T

A C T

149


Don’t Waterfall the Sprint

Waterfall each story Or better yet, do each story backwards

– Identify acceptance tests first

– Program using Test-Driven Development

– Utilize Paired Programming

Work on stories in priority order

– Avoid working all stories together

– Minimize tasks in process

150


The Simple Math Behind TDD

151


Sprint Intensity

Time

Intensity

Waterfall

Scrum

152


Day 6 – Implementation and Mid-Iteration Review

Mid iteration status review


Story elaboration, communication,

negotiation

Prepare stories, use cases for next

iteration

Next iteration preview

153


Mid-iteration Checkpoint

What is the overall status of this iteration? Are we going to land this thing? If not, what can we do about it?

– Reassign resources to higher priority stories?

– Reprioritize stories to achieve the objective?

– Delete stories?

– Will this affect the release?

154


Sutherland’s Sprint Pilot’s Emergency Landing Procedure

1. Innovate/remove impediments - quickly analyze the root cause of the problem (blocked story, resources diverted to emergency, or whatever) and see what ideas the team has to correct the problem.

2. Get Help – can help be found outside the team? If so, apply these resources to accelerate the burn down.

3. Reduce scope – cut lower priority features and re-plan based upon what the team can accomplish. While the team might not be able to deliver all the stories, it might still be able to fulfill the objectives of the sprint

4. Abort – if the deck is still pitching and the glide path is still too high, then lastly, it may be necessary to abort the sprint and simply start over. Not every sprint can be a winner (unless the team is too risk averse) so the learnings and completed stories can launch you into a new, more realistic sprint. This is the last resort, but it could still be better than an unfortunate landing.


Sprint Healthy Balance

CommitmentAdaptability

Too much holding to commitment can lead to burnout and inflexibility

Too much adaptability can lead to lack of predictability

156


Day 7-9 Implementation Continues


Story acceptance

15 Minute standup

Meet after

Prepare stories, use cases for next

iteration

157

Product Owner

Product Owner


Exercise: Sprint Execution

AS A TEAM,WE WANT TO EXECUE THE EXERCISE SPRINT

SO WE CAN LEARN FROM THAT EXPERIENCE

Acceptance Criteria: - Team has some number of stories accepted - Team has an exercise velocity

158

Instructions: - Your team has twenty minutes to complete as

many stories as possible- You can use any resources at your disposal.- Only the product owner can accept stories


IN PROCESS

DONE

TO DO

INTRO SCRUMOVERVIEW

PRODUCTBACKLOG USER

STORIES

ESTIMATING

SCRUM TEAM SPRINT

PLANNING

SPRINT TRACKING

SPRINT DEMO

SPRINTRETRO


159

PRIORITIZING


Day 10 – Demo and Retrospective

Review - Story by story demonstration

Retrospective

Complete stories - wrap up demos

15 Minute standup

Meet after

160


Scrum Diagnostic: “done”?

Acceptance criteria met Code standards followed No open regressions All P1 & P2 defects

resolved Code coverage of 70% or

greater Test plans and cases

documented and passing

Performance and scalability impact assessed

User experience reviewed and testing scheduled

All UI labels ready for localization

New functionality documented

161

http://www.implementingscrum.com/


Sprint Review

162


Sprint Review Meeting

What is it?– Presentation of value to the “customer”

– New feature demonstration

– Feedback from customers, stakeholders Guidelines

– 2 hour prep rule

– Minimal slides for context

– Demonstrate actual product functionality Attendees

– Product owners, management, executive sponsors, other teams, customers, team

163


Sprint Review:Two Questions

Is THIS what you

asked for?

Demonstrate the Product Review the Release Progress

164


Sprint Review:Two Perspectives

Sprint Results Release Plan Impact

Jan Feb Mar Apr May Jun Jul Aug Sep

0

20

40

60

80

100

120

140

160

Completed

Remaining

Poin

ts

Compare to commitment Show what was done or NOT done Discuss what is coming next

Update any additions or subtractions to the release

Display what is completed from the previous sprint

Project a new release date based on the progress

165


Sprint Retrospective

What is it?– Review of the team & process

– Did we meet the objectives

– Velocity compared to plan

– Review of impediments Guidelines

– 30 minutes

– After every sprint

– Whole team participates

– Find one thing to do better next time

166


A Simple Template

167

What Went Well

What Didn’t

What 1 (2), (3) things will we do different next time?


Exercise: Sprint Execution

AS A TEAM,WE WANT TO IDENTIFY SOME

LESSONS LEARNED FROM THE EXERCISE SPRINT SO WE’LL KNOW WHAT TO

EXPECT IN THE REAL WORLD

Acceptance Criteria: - Team has identified three things they would do better in another exercise sprint

168


Agile Project Metrics

Functionality Iteration 1 Iteration 2

# stories (loaded at beginning of iteration)

# accepted (defined/built/tested and accepted)

% accepted

# not accepted (not achieved within iteration)

# pushed to next (rescheduled in next iteration)

# not accepted: deferred to later date

# not accepted: deleted from backlog

# added (during iteration, should typically be 0)

Quality and test automation

% SC with test available/test automated

Defect count at start iteration

Defect count at end of iteration

# new test cases

# new test cases automated

# new manual test cases

Total automated tests

Total manual tests

% tests automated

Unit test coverage percentage

169


Exercise - Definition of Done

170

When is a User Story done?

When is a Sprint done?

When is a Release done?


IN PROCESS

DONE

TO DO

INTRO SCRUMOVERVIEW

PRODUCTBACKLOG USER

STORIES

ESTIMATING

SCRUM TEAM SPRINT

PLANNING

SPRINT TRACKING

SPRINT ENDING

CLASSRETRO

RELEASESPRINT


171

PRIORITIZING


Patterns: The Practical World

The Sprint goal is to have tested and accepted software at the end of every iteration– But automation of testing may lag by one or more iterations

Over time:– the set of accumulated functional test cases

– + system level and performance test cases serve as full regression tests for iteration and release

The release goal is to execute a full suite of release level acceptance testing, full regression and system and performance testing in less than one iteration

Often, a typical release pattern develops

Iterate IterateIterate StabilizeIterate

Ship!

172


Stabilization Sprint Warning Sign

Sprint 1 Sprint 2 Sprint 3

TechnicalDebt

173


Release Sprints

– Non-automated regression

– Exploratory testing

– Stress, performance or usability testing

– Final integration

– Compliance

– Defects

– “Matrix of death” testing

– User environment testing

– Documentation Finalization

– Localizations

– Release Note

– Deployment Plans

174


Remember - Always Deliver!

Successful sprints deliver a potentially shippable product increment

Do not miss the end

– Deadline is sacred

– Scope may change

Always deliver value Quality is fixed: only accepted items “exit” the sprint

175


IN PROCESS

DONE

TO DO

INTRO SCRUMOVERVIEW

PRODUCTBACKLOG USER

STORIES

ESTIMATING

SCRUM TEAM SPRINT

PLANNING

SPRINT TRACKING

SPRINTRETRO

RELEASESPRINT


176

PRIORITIZING

SPRINT DEMO


Class Retrospective

177

What Went Well

What Didn’t

What 1 (2), (3) things would we do different next time?


Scrum Alliance Certification

ScrumMaster (CSM)– Education-based program focused on the process and

core leadership skills and competencies required Scrum Practicing (CSP)

– Experienced-based program focused on applying Scrum in an organizational project context

Scrum Coach (CSC)– Skills and competency-based program for those helping

organizations adopt, transition or implement Scrum Trainer (CST)

– Skills and competency-based program for those teaching others about Scrum and how to apply it

178


Further Reading

Agile Software Development with Scrum- Ken Schwaber and Mike Beedle

Agile Project Management with Scrum- Ken Schwaber

Scaling Software Agility: Best Practices for Large Enterprises

- Dean Leffingwell

User Stories Applied and Agile Estimating and Planning- Mike Cohn

Principles of Product Development Flow- Don Reinertsen

179


Other Resources

Dean Leffingwell (http://scalingsofwtareagility.wordpress.com)

Scrum Alliance (http://scrumalliance.org) Agile Alliance (http://agilealliance.org) Agile Manifesto (http://agilemanifesto.org) Scrum Gatherings twice yearly Agile Conferences yearly Scrum Yahoo! Group – scrumdevelopment

180

http://jeffsutherland.com/

http://mountaingoatsoftware.com/

http://scrumalliance.org/

http://agilealliance.org/

http://agilemanifesto.org/

© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. Scrum for Teams 1 Notice: Much of this...

Documents

Transcript of © 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. Scrum for Teams 1 Notice: Much of this...