Practical Scrum course day 2

Scrum Workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Practical Scrum 
Day II
Ilan Kirschenbaum
Agile coach
co-founder @ practical-agile
twitter: @_kirschi
email: ilan@practical-agile.com
blog: http://fostnope.com/

Exercise

• Our Specially Crafted Feedback Forms
• Agile Practitioners IL
• Lifetime Guarantee

Agenda
• Product owner
• Product backlog
• Planning
• Estimating
• Sprint planning
• Sprint backlog
• Burndown charts
• Daily scrum
• Sprint review
• Sprint retrospective
• Scrum simulation
• Scaling Scrum

Product Owner

Exercise: The
painters game

Round 1

Round 2

Round 3

QIt’s possible to transfer information
effectively on written documents
without much of human contact.
Essential knowledge is lost in every
handover and human interaction is needed
to overcome it.

The Product Owner
• The person that represents the customer.
• Should have business knowledge or at least have
access to it.
• Has almost no authority over the team in technical
aspects.
• Exceptions are non-functional constraints and
requirements And the deﬁnition of Done.

Role of the PO
• Defines the features of the product
• Defines release dates and content
• Responsible for ROI.
• Prioritizes feature according to value.
• Can change features and priority  
once every predefined interval.
• Decides what will be worked on in each iteration
• Accepts or rejects results.

Concept Change
• Traditionally throws content “over the fence”– no
more!
• Takes an active role throughout the development
lifespan.
• Needs to make decisions regarding ROI every sprint.
• The single wringable neck.

Product Backlog

The Product Backlog

The Product Backlog
• List of features, Technology, issues.
• Items should deliver value for customer.
• Constantly prioritized & Estimated.
• Anyone can contribute.

The Product Backlog
• Visible to all.
• Derived from business plan, may be created
together, with the customer.
• Can be changed every sprint!!!
• Customer is not “programmed” to think of
everything in advance.

The Product Backlog - Example
Description Estimate Acc. test sprint
As a user I would like to register 3 1
As a user I would like to login 5
Show successful
login & 
Show failing login
1
As a buyer I would like to make a
bid
3 1
As a buyer I would like to pay with
a credit card
8 2
As a seller I would like to start an
auction
8 2
…

The Product Backlog - Example
Description Value Estimate Acc. test sprint Wiki link
As a user I would
like to register
1200 3 1 www…..
As a user I would
like to login
1100 5
Show successful
login & 
Show failing login
1
As a buyer I
would like to
make a bid
1000 3 1
As a buyer I
would like to pay
with a credit card
700 8 2
As a seller I
would like to
start an auction
10 8 2
... …

The Product Backlog
• Can be defined in any way that serves best the PO.
• User stories are recommended for functional requirements.
• Usually contains the fields: ID, area, description, value,
estimate, test criteria.
• Common other fields: dependency details, source of item.
• Remember to “KISS” - Keep it simple, stupid sweetheart!

User Stories
• Are not use cases!
• Describe requirements from the user’s POV
• A deﬁned format: 
As a …. I would like to…. [so that….]
• Should not include too many details.
• Modeled for discussion, to overcome the communication gap.
• Guidelines for a good story are: Independent, Valuable, Properly sized,
Testable.

User Stories - Example
• As a customer I want to be able to check my current balance.
• As a manager I would like to be able to see the overall
balance of the customers.
• As a manager I would like to see trends in sales.
• As a sales person I would like to have a report of past activity
for speciﬁc customers.
• As a customer I would like to reprint receipts of past purchases.

Exercise
 
As a <WHO> I want to <WHAT> so that <WHY>

QIt is possible to “collect” or even
“know” all the requirements up-
front
Requirements evolve as customers and
our knowledge increases – based on
experience

Backlog Items Size
• The product backlog items (PBI) become more
granular the higher they are in the backlog.
• Usually the PBI starts as very big items (Epics) and are
split into smaller sized items.
• It is common that the PBIs for the next 2-3 sprints are
split so that:
• 3-5 PBIs ﬁt within a single sprint.

Splitting User Stories
• Different scenarios
• Stubbingmocking external dependencies
• Splitting across the data model.  
E.g Support only a subset of attributes
• Splitting across operations 
E.g CRUD parts of a protocol

Splitting User Stories
• Splitting on results 
E.g Success and failure scenarios.
• Splitting cross-cutting concerns 
E.g Logging Security.
• Splitting functional & non-functional requirements

Backlog Grooming
• Also called backlog refactoring.
• Done by the team and the PO.
• The goal is to have the backlog ready for the sprint
planning.
• Grooming = Splitting, clarifying & estimating.

Backlog Grooming
• Usually grooming just enough for 2-3 sprints ahead.
• Recommended to allocate ~5% of sprint time for this
task.
• NEVER allow the PO to reach a sprint planning
meeting with a backlog not in good shape.

Agile Planning with
Scrum

The “Planning Onion”
Daily
Iteration
Release
Product
Portfolio
Strategy

Why Plan?
• Reduce risk.
• Reduce uncertainty.
• Gather data to assist in decision making.
• Provide external stake holders with data.
• Establish expectation to measure progress against.

Estimating

–John Maynard Keynes
“It’s better to be roughly right than precisely
wrong.”

Persistance of Time

Exercise: Relative
Estimations

34.4

Why Relative?
• We are not good in measuring absolute values.
• We are good in comparing things.
• We have the basic math skills (or a calculator).
• High accuracy has a high toll.
• Estimates become commitments
• Time is not persistent.

Story Points
• Name is derived from user stories.
• They reﬂect the “bigness” of a user story.
• How hard it is ? 
How risky it is ? 
How much of it there is ?
• Relative values matters.

Planning Poker
1. Each person gets a deck of cards (Fibonacci).
2. The item to be estimated is read to all.
3. Attendants ask clariﬁcations for the item.
4. Each person selects a card and puts it on the table facing down.
5. When everyone is done, cards are exposed.
6. If the estimations do not match a short discussion is done – Highest & Lowest
estimators speak ﬁrst. -> Goto 4.
7. Handle next item.
12 3 5 8
132040

Why Use Planning-Poker?
• Those who do the work estimate it.
• Emphasizes relative estimation
• Estimates are within one order of magnitude.
• Reduces anchoring - Everyone's opinion is heard.

Speciﬁcation Length
•One page spec
•Group A
•7 Pages spec
•Group B
173 hours
117 hours

Irrelevant Information
•Group A
•added irrelevant details:
•End user desktop apps
•Usernames & passwords
•Etc.
•Group B
39 hours
20 hours

Extra Requirements
•Requirements 1-4
•Group A
•Requirements 1-5
•Group B
4 hours
4 hours
•Requirements 1-5 but told  
to estimate 1-4 only
•Group C
8 hours

Anchoring
•Group A
•Customer thinks 500
•customer has no technical knowledge
•Don’t let the customer inﬂuence you
•Group B
555 hours
456 hours
•Same as B  
customer thinks 50
•Group C
99 hours

Why Use Planning-Poker?
• Those who do the work estimate it.
• Emphasizes relative estimation
• Estimates are within one order of magnitude.
• Reduces anchoring - Everyone's opinion is heard.
• Modelled for open discussion – forces thinking.
• It’s quick & fun !

Velocity
• How many points can the team complete in one iteration.
• Easy to measure.
• Fixes estimation errors.
• Easily reﬂects the project status.
• Primary parameter in planning.

Iteration Planning
Description Estimate
As a user I would
like to register
3
As a user I would
like to login
5
As a buyer I would
like to make a bid
3
As a buyer I would
like to pay with a
credit card
8
As a seller I would
like to start an
auction
8
…
This Iteration
3 5 3
Next Iteration
8 8
Average Velocity = ~14

Release Planning

Calculating Release Time
S
T
V

http://artparty4u.wix.com/xtremeaverage/apps/blog/wtc-ceo-andrew-messick-on-ironman-swim :‫מקור‬

Release Planning
• Given that:
– the items for the release are estimated.
– The velocity is known (or predicted)
– We know the scope or deadline.
• We can estimate one of the two:
– how much can we do until the deadline.
– How many sprints it will take to complete the
content.
• The more data we will have, the more accurate will
be our estimate.

Sprint Planning &
Sprint Backlog

Sprint Planning
• The ﬁrst meeting of the sprint.
• Divided into two parts
• Part I
• Part II

Sprint Planning
• Lasts between 2-8 hours.
• Participants: PO, Team, Scrum Master.
• Product backlog should be in good shape.
• PO should have good understanding of the top
backlog items.

Sprint Planning Part I
• Goal: Decide what the team takes to part II in order
to commit for sprint content.
• PO Explains the top items from the backlog.
• Team and PO selects the sprint goal.

Sprint Planning Part II
• Goal: Generate the sprint backlog & commit on the
sprint’s content.
• The team splits each of the stories into smaller tasks
and estimates each task.
• Some design decisions are done.
• Verify that the goal is achievable.

The Sprint Backlog
• An artefact that belongs to the team.
• Assists the team in tracking the sprint’s progress.
• Maximum task length should not exceed 16h for a 4
week sprint.

The Sprint Backlog
• Updated throughout the sprint
• Every team member can add, remove or change
the sprint backlog.
• Status of tasks & remaining work is updated daily.
• Sprint content emerges.

The Sprint Backlog - Example

More Task Board Examples

Task Board
To do In progress Done
PBI # 1
PBI # 2

Sprint Planning
• Part I
• Velocity based planning.
• Commitment based planning.
• Part II
• Trust velocity
• Hours & capacity based.

QMultiple parallel programs speed up
the development
Multiple programs create big management
overhead and risk of overloading the
pipeline, R&D works most efficiently in
continuous mode

Burndown Charts

Burndown Charts
• A simple way of tracking progress.
• Used in different levels:
• Sprint.
• Release.
• Product.
• Shows the amount of work left to reach target.

Release Burndown ChartEffortremaining
0
25
50
75
100
Sprint
1 2 3 4 5 6 7 8

Sprint Burndown Chart

Daily Scrum

Daily Scrum
• Daily
• No longer than 15 minutes
• Same place same time.
• Stand up.
• All the team must attend.

Daily Scrum
• 3 Questions:
• What have we accomplished since the last daily
• What will we complete until the next daily
• What are my/our impediments.
• Only team members are allowed to speak.

Daily Scrum
• Keep asking
• Is this meeting
useful ?
• If not, ﬁnd out why?
• Is the team reporting to the SM ?
• Does the team share their work ?
• Are impediments removed ?
• Are the reports unclear ?
• Does it take longer than 15
minutes ?
• Etc.

Sprint Review

Sprint Review
• Held At the end of each sprint.
• This is —-NOT—- a Sprint Demo
• During this meeting the team presents to the managementcustomers
usersproduct owner, what work has been DONE and what was not.
• The only form of “automated” presentations allowed is working
software, Slideware is banned.
• The things that were not accomplished will be returned to the product
backlog.

Retrospective

Sprint Retrospective
• Key feature of inspect & adapt
• Periodically take a look at what is and is not working
• Typically 1-2 hours
• Done after every sprint (for sprint retrospective)

• Who participates ?
• Scrum Master - facilitates
• Product owner
• Team – all of the team.
• Possibly customers and others

• The goal of the meeting is to generate action items
(Experiments) to execute next sprint
• Things to stop doing.
• Things to keep doing.
• Things to start doing.

Retrospective Model Example
• Opening (2-5 minutes)
• Data collection (15-25 minutes)
• Generate insights (15-25 minutes)
• Create experiments (15-25 minutes)
• Closing (2-5 minutes)

Opening
• 1 word
• SAD MAD GLAD
• Score the sprint.

Data collection

To keep To change
• List the things in two columns.
• Prioritize each column.
• Take top 3 from each column.
• Prioritize again.

Timeline
• Draw a chart on the board.
• Have each team member write meaningful events.
• Put sticky notes on the board at the relevant time.
• Group items based on timetopicelse.
• 1 is also a group.
• Prioritize.

Spider web
• Draw a spider web on the board.
• Write attributes that are important to you on each edge.
• Have each team member rate each attribute.
• Discuss the most painful one.
• Repeat until the time is over.

Generate insights
• Silent grouping.
• 5 why’s.
• Spin dating.

Create Experiments
• Not many experiments.
• Experiment should be:
• S.M.A.R.T 
Speciﬁc, Measurable, Attainable, Relevant, Timely

Closing
• Action items owners.
• And:
• Rate the retrospective.
• SAD MAD GLAD.

QProduct development process can
be defined as a predictable and
repeatable process
Product development is an evolving and
adaptive process

Scrum Simulation

Scaling Scrum

• Do it only if you must!
• Scrum can be implemented without scaling for ~100 people.
• Sometimes it is better to have less people working on a project.
• Focus on synchronization & communication.
• CI at the top level
• Scrum of scrums.
• Multiple team sprint planning.
• COP – communities of practice.
• The right organizational structure

Scaling Sprint Planning
Planning part I
Product owner
Representative of each team
backlog
Planning part II
Team 1
Planning part II
Team 2
Planning part II
Team 3
Select backlog
item
s
Select items
Selectbacklog
item
s
sprint 
backlog
sprint 
backlog
sprint 
backlog

– Every team sends one representative (Not the Scrum master!!!)
Daily Scrum
10:00 am
Team 1
Daily Scrum
10:15 am
Team 2
Daily Scrum
10:30 am
Team 3
Daily Scrum
11:00
Scrum of scrums 
Team
representatives
Extra question:
Do we intend to
create a problem

Organization
Structure

The Traditional Way - Component Teams
Component A
Component B
Component C
Component D

The Traditional Way - Bottleneck
Component A
Component B
Component C
Component D
Release feature list:
•Feature 1 – A(20%) B(30%) C(50%)
•Feature 2 – A(40%) B(20%) D(40%)
•Feature 3 – B(80%) C(20%)
•Feature 4 – A(50%) C(50%)
•Feature 5 – A(20%) C(70%) D(10%)
Total Effort needed:
A – 210
B – 130
C – 190
D – 50

The Traditional Solutions
• Move people from team to team to match requirements A(5) , B(3), C(5), D(2).
• Decreases job satisfaction, hurts performance.
• What will happen next release ?
• Leave team formation as is:
• Some teams will be “unemployed” – What will they do ?
• Need to “invent” work for them.
• Other teams will have too much pressure.
• Change the scope of the release to equalize efforts:
• Still bottlenecks exists on feature level.
• The problem will be worst next release.

Feature Teams

Sources of Requirements
Component A
Component B
Component C
Component D
Security
related
Features
User
admin
related
features
Item
CRUD
related
features
Reporting
related
features

Feature Teams
• All teams have cross component ability.
• This might take some time.
• All team produce E2E functionality.
• Immediately reduces bottlenecks, reduces waste.
• Long term, eliminate this bottleneck.
• Increases ﬂexibility – allows development by business value.
• Requires increased communication between teams (this is a good thing!)
• Increases business understanding inside teams.
• Requires commitment and effort to implement.

Component A
Component B
Component C
Component D
Release feature list:
•Feature 1 – A(20%) B(30%) C(50%)
•Feature 2 – A(40%) B(20%) D(40%)
•Feature 3 – B(80%) C(20%)
•Feature 4 – A(50%) C(50%)
•Feature 5 – A(20%) C(70%) D(10%)
Feature 1
Feature 2
Feature 3
Feature 4
Total Effort needed:
A – 210
B – 130
C – 190
D – 50

Scaling the PO Role
• Easy when feature teams exists.
• Instead of a PO have a PO team.
• Each team member is an APO – Area product owner.
• Area product owner focuses on one or more requirement areas.
• Team decides together how the general prioritization of the back log is.
• Each APO has the responsibility to support, follow and prioritize within his areas.
• APOs report back to the team for adaptations.
• Usually an APO deals with the same teams for a long period of time.

Appendix

Recommended Links
• Scrum alliance – www.scrumalliance.org
• Scrum development group on yahoo –  
groups.yahoo.comgroupscrumdevelopment
• Agile alliance – www.agilealliance.org
• infoQ – www.infoq.com
• Agile Practitioners IL Discussion Group  
http://www.linkedin.com/groups/Agile-Practitioners-IL-81807
• My blog – http://fostnope.com
• Practical Agile website -  
http://www.practical-agile.com/

Recommended Books
• Ken Schwaber & Mike beedle – Agile software
development with Scrum
• Ken Schwaber – Agile project management with
Scrum.
• Ken Schwaber – Enterprise Scrum.
• Bass Vodde & Craig larman - Scaling Lean & Agile
Development (2 books)

Other Recommended Books
• Tom DeMarco & Timothy lister – Peopleware.
• Frederick P. Brooks - The Mythical Man-Month
• Craig Larman – Agile & Iterative software development.
• Mary Lynn Manns and Linda Rising - Fearless change
• Diana Larsen & Esther Derbey – Agile retrospectives
• Mike Cohn – Agile estimation and planning.
• Mike Cohn – User stories applied.
• Test Driven (java) – Lasse koskalle
• Clean code – Robert C. Martin.
• And many more…

References and Additional Sources
• 1970 - Managing the development of large software systems (aka Waterfall
Model, Winston Royce) http://leadinganswers.typepad.com/leading_answers/
ﬁles/original_waterfall_paper_winston_royce.pdf
• 1986 – The new, new software development game (Takeuchi & Nonaka) http://
ﬁles.meetup.com/1671339/The%20New%20New%20Product%20Development
%20Game.pdf
• LikerHoseus 2008 – The Toyota Way http://www.amazon.com/The-Toyota-
Way-Management-Manufacturer/dp/0071392319
• 2001 - Agile Manifesto http://agilemanifesto.org
• 1991-2013 - The Scrum Guide (Schwabber, Sutherland) https://www.scrum.org/
Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf

• 1971 - The Psychology of Computer Programming (G. Weinberg) http://
www.amazon.com/The-Psychology-Computer-Programming-Anniversary/dp/
0932633420
• 1987 - Peopleware, Productive Projects and Teams (T. De-Marco) http://
www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113
• 2003 - Lean Software Development: An Agile Toolkit (M&T Poppendieck)
http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/
0321150783
• 1999 - Extreme Programming Explained (K. Beck & C. Andres) http://
www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/
0321278658

• 2004 - Working Effectively with Legacy Code (M.
Feathers) http://www.amazon.com/Working-
Effectively-Legacy-Michael-Feathers/dp/0131177052
• 1975 - The Mythical Man-Month (F. P. Brooks) http://
www.amazon.com/Mythical-Man-Month-Software-
Engineering-Anniversary/dp/0201835959
• This is Water video https://www.youtube.com/
watch?v=DKYJVV7HuZw

End of
day 2

Practical Scrum course day 2

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to Practical Scrum course day 2 (20)

More from Ilan Kirschenbaum (16)

Recently uploaded (20)

Practical Scrum course day 2