Upload
erik-marsh
View
219
Download
6
Tags:
Embed Size (px)
Citation preview
© 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)
© 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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
IN PROCESS
DONE
TO DO
INTRO
SCRUMOVERVIEW
PRODUCTBACKLOG
USERSTORIES
PRIORITIZING SCRUM TEAM
SPRINT PLANNING SPRINT
TRACKINGSPRINT DEMO
SPRINTRETRO
RELEASESPRINT
Scrum Training Backlog
3
ESTIMATING
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Scrum
6
Scrum is not a methodology
Scrum does not provide the answers to how to build quality software faster
Warning!
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 8
Scrum Framework
Potentially Shippable Increment
Daily Standup
Two week Sprint
Solution, program, or
product backlog
Sprint commitment
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Scrum Origins
The New, New Product Development
Game*Lean
Iterative, Incremental
Development, Time-boxes
Smalltalk Engineering Tools
Scrum
9
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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.
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 13
Scrum: Whole Team
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Scrum Planning
16
Product & Release Cycle
Sprint & Daily CycleRelease ScopeAnd Boundaries
ReleasePlanning
SprintPlanning
Develop& Test
Review&
Adapt
ReleaseVision
Drives
Feedback
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 20
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 21
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 22
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 23
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
A
Scrum Context
24
Need to Respond to
Change
Agile and LeanPrinciples
Scrum Practices
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 25
Key Agile Principles
1. Whole Team
2. Time-boxing
3. Adaptive Planning
4. Close Customer Involvement
5. Feedback Learning
6. Constant Systemic Testing
FOCUS
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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.
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
• 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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 31
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 32
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 33
IN PROCESS
DONE
TO DO
INTRO SCRUMOVERVIEW
PRODUCTBACKLOG
USERSTORIES
ESTIMATING
SCRUM TEAM
SPRINT PLANNING SPRINT
TRACKINGSPRINT DEMO
SPRINTRETRO
RELEASESPRINT
Scrum Training Backlog
PRIORITIZING
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Traditional Approach
Detailed RequirementSpecifications and Planning
Detailed Project Planning and Tracking
36
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Exercises: Product Backlog
BRAINSTORM BACKLOG ITEMS THAT ADDRESS YOUR VISION
ORPROBLEM CONTEXT
Acceptance Criteria: - 10-15 Backlog items
41
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
IN PROCESS
DONE
TO DO
INTRO SCRUMOVERVIEW
PRODUCTBACKLOG
USERSTORIES
ESTIMATING
SCRUM TEAM
SPRINT PLANNING SPRINT
TRACKINGSPRINT DEMO
SPRINTRETRO
RELEASESPRINT
Scrum Training Backlog
42
PRIORITIZING
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 43
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 45
What is a User Story?
User Stories represent customer requirements
rather than document them
User Stories are a tool for writing backlog items
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
User Story Template
As a <role>I can <activity>
So that <business value>
48
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 49
User Stories…
Are NOT Requirements or Use Cases
Are a planning and tracking tool
Can reference Requirements and Use Cases
49
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
INVEST in a Good Story
INVEST acronym created by Bill Wake
I
N
V
E
S
T
50
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
User Stories are Small
Complex Problem Compound Problem
TechnicalSpike
FunctionalSpike Split Story
56
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
IN PROCESS
DONE
TO DO
INTRO SCRUMOVERVIEW
PRODUCTBACKLOG USER
STORIES
ESTIMATING
SCRUM TEAM
SPRINT PLANNING SPRINT
TRACKINGSPRINT ENDING
CLASSRETRO
RELEASESPRINT
Scrum Training Backlog
65
PRIORITIZING
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 66
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Team-based Estimation
69
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Estimation Technique:Team Estimation
Increases accuracy Builds understanding Drives commitment
Traditional estimation performed by a manager, architect or select group negates these benefits
70
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 76
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
IN PROCESS
DONE
TO DO
INTRO SCRUMOVERVIEW
PRODUCTBACKLOG USER
STORIES
SCRUM TEAM
SPRINT PLANNING SPRINT
TRACKINGSPRINT DEMO
SPRINTRETRO
RELEASESPRINT
Scrum Training Backlog
78
ESTIMATING
PRIORITIZING
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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)
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Feature Time(Effort)
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Feature Time(Effort)
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)
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
WSJF Prioritization Matrix
84
WSJF Priority = Cost of Delay/Effort
In general, do the Weighted Shortest Job First! (CoD/Effort)
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 86
IN PROCESS
DONE
TO DO
INTRO SCRUMOVERVIEW
PRODUCTBACKLOG USER
STORIES
ESTIMATING
SCRUM TEAM
SPRINT PLANNING SPRINT
TRACKINGSPRINT DEMO
SPRINTRETRO
RELEASESPRINT
Scrum Training Backlog
PRIORITIZING
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Teamwork
"It is amazing what can be accomplished when nobody cares about who gets the credit." - Robert Yates (NASCAR)
87
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Role Collaboration
CustomerTeam
DevelopmentTeam
StoryCreation
StoryPriority
StoryAcceptance
ProductOwner
ScrumMaster
Scrum Role Relationships
ProductVision
Story Conversation
Stakeholders
Stakeholders
90
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 94
Example Shared Team Area
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 97
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Teamwork
Remains the ultimate competitive advantage
however,
most teams are dysfunctional
98
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
Source: Five Dysfunctions of a Team, Patrick Lencioni
100
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 101
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
104Source: Five Dysfunctions of a Team, Patrick Lencioni
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
Source: Five Dysfunctions of a Team, Patrick Lencioni
107
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 108
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
109Source: Five Dysfunctions of a Team, Patrick Lencioni
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 110
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Scrum and the Five Dysfunctions
111
Inattention to Results
Avoidance of Accountability
Lack of Commitment
Fear of conflict
Absence of Trust
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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?
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
The Surprising Truth About What Motivates Us
http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=youtu.be
115
AMP
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
IN PROCESS
DONE
TO DO
INTRO SCRUMOVERVIEW
PRODUCTBACKLOG USER
STORIES
ESTIMATING
SCRUM TEAM
SPRINT PLANNING
SPRINT TRACKING
SPRINT DEMO
SPRINTRETRO
RELEASESPRINT
Scrum Training Backlog
116
PRIORITIZING
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Scrum Planning
Product & Release Cycle
Sprint & Daily CycleRelease ScopeAnd Boundaries
ReleasePlanning
SprintPlanning
Develop& Test
Review&
Adapt
ReleaseVision
Drives
Feedback
117
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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?
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 123
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Sprint Planning
124
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 125
Sprint Backlog: The Task Board
Story Tasks To Do In Process Done Hours
As a user, I can… 8
As a user, I can… 3
As a user, I can… 5
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Exercise: Sprint Planning
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Exercise: Sprint Planning
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.
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
IN PROCESS
DONE
TO DO
INTRO SCRUMOVERVIEW
PRODUCTBACKLOG USER
STORIES
ESTIMATING
SCRUM TEAM SPRINT
PLANNING
SPRINT TRACKING
SPRINT DEMO
SPRINTRETRO
RELEASESPRINT
Scrum Training Backlog
133
PRIORITIZING
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Day 2─5 Implementing
15 Minute standup
Team designs, implements stories
Story elaboration, communication,
negotiation
Meet afterProduct Owner
134
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Open Environment, Constant Communication
136
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Sprint Tracking Through Using the Task Board
139
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Scrum team in an enterprise setting
140
Modular team
workspace
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Iteration Status with “Burndown Charts”
Spreadsheet
Courtesy Trailridge Consulting, LLC
141
Manual
141
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
With Tooling Automation
Broken Build
Story Status
Burn down
142142
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
An XP shops “Wall of Truth”
143
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
DAY 2-9 Daily Scrum
144
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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!
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
The Simple Math Behind TDD
151
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Sprint Intensity
Time
Intensity
Waterfall
Scrum
152
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Day 6 – Implementation and Mid-Iteration Review
Mid iteration status review
Team designs, implements stories
Story elaboration, communication,
negotiation
Prepare stories, use cases for next
iteration
Next iteration preview
153
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC. 155
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.
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Day 7-9 Implementation Continues
Team designs, implements stories
Story acceptance
15 Minute standup
Meet after
Prepare stories, use cases for next
iteration
157
Product Owner
Product Owner
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
IN PROCESS
DONE
TO DO
INTRO SCRUMOVERVIEW
PRODUCTBACKLOG USER
STORIES
ESTIMATING
SCRUM TEAM SPRINT
PLANNING
SPRINT TRACKING
SPRINT DEMO
SPRINTRETRO
Scrum Training Backlog
159
PRIORITIZING
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Day 10 – Demo and Retrospective
Review - Story by story demonstration
Retrospective
Complete stories - wrap up demos
15 Minute standup
Meet after
160
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Sprint Review
162
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Sprint Review:Two Questions
Is THIS what you
asked for?
Demonstrate the Product Review the Release Progress
164
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
A Simple Template
167
What Went Well
What Didn’t
What 1 (2), (3) things will we do different next time?
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Exercise - Definition of Done
170
When is a User Story done?
When is a Sprint done?
When is a Release done?
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
IN PROCESS
DONE
TO DO
INTRO SCRUMOVERVIEW
PRODUCTBACKLOG USER
STORIES
ESTIMATING
SCRUM TEAM SPRINT
PLANNING
SPRINT TRACKING
SPRINT ENDING
CLASSRETRO
RELEASESPRINT
Scrum Training Backlog
171
PRIORITIZING
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Stabilization Sprint Warning Sign
Sprint 1 Sprint 2 Sprint 3
TechnicalDebt
173
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
IN PROCESS
DONE
TO DO
INTRO SCRUMOVERVIEW
PRODUCTBACKLOG USER
STORIES
ESTIMATING
SCRUM TEAM SPRINT
PLANNING
SPRINT TRACKING
SPRINTRETRO
RELEASESPRINT
Scrum Training Backlog
176
PRIORITIZING
SPRINT DEMO
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
Class Retrospective
177
What Went Well
What Didn’t
What 1 (2), (3) things would we do different next time?
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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
© 2008-10 TrailRidge Consulting, LLC. & Leffingwell, LLC.
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