Tighten up Your Scrum Process

Benjamin Day
@benday | www.benday.com
Let’s say you’re doing Scrum already.
(Sort of )
It’s ok but the magic has worn off.
How do you re-kindle the magic?
#1: Pay attention.
Scrum Mindfulness
#2: Try some new stuff.
Scrum Tune-up
What does ‘done’ mean?
“Done” vs. “Done Done”
 A written definition of done is
as close to a “magic silver bullet” as
you’ll find in software.
 Definition of Done (DoD) =
Everything it takes to call a feature
‘done’
 Ambiguity and differences of
opinion are poison for software projects.
Your DoD helps eliminate ambiguity.
DoD is a conversation starter.
Have a conversation with the team
about what ‘Done’ means.
Write it down.
 Software developers think that
software development begins and ends
with us.
(We’re basically right, too.)
The “software development industry”
is probably misnamed.
“Software delivery industry”.
 Software delivery is a lot
bigger than just writing the code.
 Software delivery
focuses on the ‘big picture’
of getting software to the point
that it can actually be used.
Code by itself isn’t that useful.
“Well, it works on my box.”
 When developing your
written Definition of Done (DoD),
you’ll discuss a lot more than just coding.
 Sample Definition of Done (DoD)
Development / Coder
 Code is written with unit tests
 Unit tests have a minimum of 75% code
coverage
 Code has been merged to Main
 Code compiles and unit tests pass when run as
part of an automated build
 Database schema objects are under source
control
 Database upgrade script is under control
 Code reviewed by someone other than
the original author
Testing, Deployment, Ops
 Written QA test plan
 Tested with QA test plan by someone other
than the original author
 Deployed and tested in Staging environment
 Automated UI tests are written and pass
 No Severity 1 or 2 bugs
 Reviewed by Product Owner
 Passes acceptance criteria for the PBI
 Known deployment & rollback plan
 Deployment plan reviewed by Ops
 Database changes reviewed by DBAs
 Load tested
 Deployed to Production
 Why a Written DoD?
- Helps your team to…
• …Accurately estimate
• …Understand how much work is left

- Helps the Scrum Master to…

• …defend the team against the “two second fix” request
• …advocate for the team and explain what they do all day
The “Two Second Fix” Request.
 Sample Definition of Done (DoD)
Development / Coder
 Code is written with unit tests
 Unit tests have a minimum of 75% code
coverage
 Code has been merged to Main
 Code compiles and unit tests pass when run as
part of an automated build
 Database schema objects are under source
control
 Database upgrade script is under control
 Code reviewed by someone other than
the original author
Testing, Deployment, Ops
 Written QA test plan
 Tested with QA test plan by someone other
than the original author
 Deployed and tested in Staging environment
 Automated UI tests are written and pass
 No Severity 1 or 2 bugs
 Reviewed by Product Owner
 Passes acceptance criteria for the PBI
 Known deployment & rollback plan
 Deployment plan reviewed by Ops
 Database changes reviewed by DBAs
 Load tested
 Deployed to Production
 “What do you do all day anyway?”
 Your non-software, non-IT colleagues have no idea what you do

 If the business had their way, they wouldn’t pay you

- (…and you wouldn’t work there.)

 The business generally just grits their teeth and tolerates

your existence as an expense

 In many orgs, the business thinks you’re lazy and incompetent

I doubt that’s true.
They just don’t understand
what you do.
A written DoD helps.
 Sample Definition of Done (DoD)
Development / Coder
 Code is written with unit tests
 Unit tests have a minimum of 75% code
coverage
 Code has been merged to Main
 Code compiles and unit tests pass when run as
part of an automated build
 Database schema objects are under source
control
 Database upgrade script is under control
 Code reviewed by someone other than
the original author
Testing, Deployment, Ops
 Written QA test plan
 Tested with QA test plan by someone other
than the original author
 Deployed and tested in Staging environment
 Automated UI tests are written and pass
 No Severity 1 or 2 bugs
 Reviewed by Product Owner
 Passes acceptance criteria for the PBI
 Known deployment & rollback plan
 Deployment plan reviewed by Ops
 Database changes reviewed by DBAs
 Load tested
 Deployed to Production
 A written DoD helps deflect
blame and annoyance when you
say ‘no’.
Next up let’s talk about doing less.
I think you should do less.
More precisely, do less at one time.
 Scrum Board for the Sprint
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C

Product
Tasks
Backlog Items
 Scrum Board for the Sprint
TO DO IN PROGRESS DONE

Product
Backlog Item A PBI A
Status

Product
Backlog Item B PBI B
Status

Product
Backlog Item C PBI C
Status
 Scrum Board for the Sprint
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Scrum Board for the Sprint
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Scrum Board for the Sprint
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Scrum Board Danger
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
Why is that so dangerous?
Too much work in progress.
 ‘Work In Progress’
commonly abbreviated as
‘WIP’.
 Sprint: Day 1 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 2 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 3 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 4 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 5 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 6 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 7 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 8 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 9 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 10 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 11 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 12 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 13 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 14 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
Sprint: Day 15 of 15 (in your dreams)
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 14 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
Sprint: Day 15 of 15 (in reality)
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C

Plenty left to do
What went wrong?
 Too much WIP.
Not enough Done.
Most of the Sprint Looked like This
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C

Lots of 0.00 Items are Done

Work In Progress 0.00 PBIs are Done
 A Better Approach to WIP
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
Huge Benefit: Risk Management
 Sprint: Day 5 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 10 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 13 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 14 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Sprint: Day 15 of 15
TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
Where’s the good news in that?
 Sprint: Day 15 of 15 At least you got
one PBI done.

TO DO IN PROGRESS DONE

PBI A

PBI B

PBI C
 Do less at once 
Decreased risk of delivering
nothing in this Sprint
Doing less at once !=
Doing less overall
 Same pile of work.
Different way of delivering it.
 Whole team is going to
work on one PBI as a team.
Helps team to focus.
Team’s focus is on details of
a single PBI rather than
details of a bunch of PBIs.
 Summary
 Do less at once

 Minimize your Work in Progress (WIP)

 Focus on your Definition of Done (DoD)

 Deliver PBIs to DoD throughout the Sprint

- (not just at the end)
What’s your team’s Velocity?
Velocity is the measure of amount of functionality
that has been delivered to Done.
 Day 15 of 15: Work Planned for Sprint
PBI Size Status
Update payment system to 5 Done
handle PayPal
Mark a transaction for fraud 3 Done
audit
Upgrade site layout to support 13 Done
Internet Explorer 11
Create a lasting world peace 8 Not Done
 Day 15 of 15: Work Planned for Sprint
PBI Size Status
Update payment system to 5 Done
handle PayPal
Mark a transaction for fraud 3 Done
audit
Upgrade site layout to support 13 Done
Internet Explorer 11
Create a lasting world peace 8 Not Done

5 + 3 + 13 = 21  Velocity = 21
The velocity for Sprint is 21.
For right now, don’t worry about
how we got those size numbers.
We’ll cover that in more detail
later in this module.
 Just bare with me and remember that
1is really small and 120 is ridiculously big.
 Day 15 of 15: Work Planned for Sprint
PBI Size Status
Update payment system to 5 Done
handle PayPal
Mark a transaction for fraud 3 Done
audit
Upgrade site layout to support 13 Done
Internet Explorer 11
Create a lasting world peace 8 Not Done

5 + 3 + 13 = 21  Velocity = 21
The velocity for Sprint is 21.
 Velocity is the measure of
what the team was
able to deliver in a single Sprint.
Velocity isn’t perfect but…
1) it’s actual hard data that’s
based on something real
2) it’s way better than nothing
A known velocity helps you
to plan future sprints.
Why does velocity help you
to plan future sprints?
I’m assuming that you & your team
aren’t complete incompetent
non-stop stumbling failures
when it comes to estimating.
(If you’re an incompetent failure,
keep watching this module.
I’ve got suggestions.)
 If you’re even a little bit ok at estimating,
you can use your velocity to
help determine how much work you should
reasonably try to pull in to a Sprint.
There will be variability in your
Sprint Velocity numbers.
Tip: Track your velocity over time
 Track Your Velocity Over Time

Sprint Velocity
Sprint 1 21 21 + 25 + 15 + 19 + 20 = 100
Sprint 2 25
100 / 5 = 20
Sprint 3 15
Sprint 4 18 Average Velocity = 20
Sprint 5 20
 Plan Your Sprint with Velocity
Average Velocity = 20
Product Backlog Item (PBI) Size
Update payment system to convert 8
USD to Bitcoin
Fix layout and click problems on 3
Safari under iPhone 6
27 > 20
Create a lasting world peace 13 Total: 27 Almost definitely too
for all humanity much work
Update payment system to support 5
ApplePay
Report: Orders by Payment Type 3
 Plan Your Sprint with Velocity
Average Velocity = 20
Product Backlog Item (PBI) Size
Update payment system to convert 8
USD to Bitcoin 11 < 20
11
Not enough work
Fix layout and click problems on 3 24
Safari under iPhone 6 24 > 20
Create a lasting world peace 13 Possibly too much work
for all humanity
Update payment system to support 5
ApplePay
Report: Orders by Payment Type 3
 Plan Your Sprint with Velocity
Average Velocity = 20
Product Backlog Item (PBI) Size
Update payment system to convert 8
USD to Bitcoin
11
Fix layout and click problems on 3
Safari under iPhone 6
Create a lasting world peace 13 19
19 < 20
for all humanity Probably do-able

Update payment system to support 5

ApplePay
8
Report: Orders by Payment Type 3
You don’t have to do it this way.
This is a way rather than The Way.
So many teams don’t track
their Velocity.
Blindfolded.
No data.
With a known Velocity
you’re planning using
empirical data
rather than guessing.
Without a known Velocity, it’s
virtually impossible for
the Product Owner to do
medium or long term
forecasting.
If you don’t have a
known Velocity,
you’re missing out.
 The Next Question:
Is your Product Backlog ‘ready’?
The Product Backlog is the list of
every feature you might ever do.
My style is to put everything on the backlog.
Write something down so I don’t have
to remember to not forget it.
It’s filled with every conceivable feature.
Got a halfway decent idea for a feature?
Toss it on the Product Backlog.
New suggestion from a customer?
Toss it on the Product Backlog.
A really great idea for a set of features?
Toss it on the Product Backlog.
 As you can imagine,
your Product Backlog
can get a little
tangled & messy.
 Somewhere in that
tangle there are
moments of genius &
clarity.
There are also moments
of complete lunacy.
 Do you remember that
Product Backlog is prioritized?
 Stuff that’s more valuable and
higher priority is towards the top.
The stuff that’s higher priority
is going to get done sooner.
 So how do you turn that
tangle into something useful?
Well, that’s going to take some work.
That work is called “Backlog Refinement”.
You’re trying to make your backlog “Ready”.
If the PBIs towards the top of the Backlog are
understandable and do-able by the Team in a
single Sprint, those PBIs are deemed
‘Ready’.
 Two keywords:
‘Refined’ and ‘Ready’.
"Great. Refined and ready. Why do I care?
Why does my Product Owner care?"
Here’s a real world scenario.
3 months ago.
 A stakeholder says to the
Product Owner,
“I’d like to get a feature that
does XYZ in the product.”
3 months go by.
 “Hey there.
How’s that feature
coming along?”
Two ways to handle this.
The Good Way.
The Good Way.
 “SWEET!
YOU ROCK!”
The Bad Way #1.
The Bad Way #2.
“(sigh) You don’t know
what you’re doing, do
you?”
 The “wrong way” is probably setting
off some negative emotional alarm bells.
 Humans want to be heard.
Humans have a fear of loss.
Humans want their needs to be met.
 They’re probably thinking
(consciously or not consciously )…
1) Did you hear them when they asked for the feature?
(Probably not.)
2) Are they going to get their feature?
(Doesn’t look like it.)
 3) I wanted that feature.
Now I’m not going to get it.
So what happens next?
Dude has a lil’ mini
freak out.
They go tell your boss that
the Product Owner is
clueless.
Unhappy stakeholders are bad for your team.
Your team needs trust.
Freaked out, skeptical stakeholders
don’t make great partners.
As a Scrum Master, you can help.
 The Right Way to Answer That Question
1. The Product Owner pulls out the Product Backlog

2. Finds the PBI on the backlog

3. Points to it and shows the Stakeholder

4. Does a little math with the known Velocity

5. Says “you should get it in about X sprints.”

 The Benefits
 Feels heard

 Feels like you care about their needs

 Has a sense of control because they have an idea

when they’re going to get the feature

 Thinks the PO is competent

What do you need to do this?
1) A ‘ready’ product backlog
with estimates.
2) A known velocity.
In order to get that ‘ready’ backlog,
you’ll need to start doing
Backlog Refinement Meetings.
 Backlog Refinement Meetings
 Not officially required by  Discuss priorities & dependencies
the Scrum Guide between PBIs

 Product Owner, Scrum Master, &  Goal: Top PBIs are…

Development Team  Understood
 Estimated
 Discuss items on the Backlog  Small enough to be done in a
single Sprint

 Estimate Product Backlog Items

 Goal: 3 to 4 Sprints of ‘Ready’ PBIs
(PBIs)
You need 3 to 4 sprints worth of
‘Ready’ PBIs.
 You’ll need to do
Backlog Refinement Meetings
regularly.
 Why Regular Refinement Meetings?
 Makes the refinement meetings easier

 Enables the “where’s my stuff” trick

 Lets the team think in their sleep about PBIs

 Makes Sprint Planning Meetings more productive and much less boring
Here’s more detail on the “where’s my stuff” trick.
There are two variations.
1) When will I get Product Backlog Item X?
2) How much done stuff will I have by Y date?
 Product Backlog
Name Size
Update payment system to convert USD to Bitcoin 8
Fix layout and click problems on Safari on iPhone 6 3
Sprint 1
Forecasting
Update payment system to support ApplePay 5
Request PDF receipt delivered by email for past purchase 2
Generate report to see orders by payment type 3
Update payment system to take PayPal payments 5
Mark transaction for fraud audit 8 Sprint 2
Upgrade site layout to support Internet Explorer 11 8 Question:
Refund in-store mobile purchase from administrator device 5
Fix bugs related to jQuery upgrade (Defect #123, #456, #321, etc.) 3 When does “Update Android app to use
Fix bugs related to declined transactions using debit cards (Defect
#132, #821) 3
new logo and color scheme” get done?
Book pre-paid appointment 2 Sprint 3
Request PDF summary of all purchases for date range 3
Redeem gift card for in-store purchase 2 Average Velocity = 21
Redeem gift card for mobile purchase 3
Update public-facing website to use new logo and color scheme 5
Update paid-user website to use new logo and color scheme 3  Group PBIs into groups that total to 21
Update Android app to use new logo and color scheme 2
Update iOS app to use new logo and color scheme 1 Sprint 4
Real-time in-store purchase notification for managers on mobile admin
app 5
Request printed receipt after in-store mobile purchase 5 Sprint Length = 2 weeks
Feature XYZ 13
? Sprint 5 ?
Feature ABC 13
Use mobile camera to scan UPC and do a price comparison 21 ? Sprint 6 ? PBI probably gets done in Sprint 4
Create a lasting world peace 21 ? Sprint 7 ?
Feature QWERTY 21 ? Sprint 8 ?
Reporting dashboard for iOS & Android 40
Federated Identity using external authentication providers 40
4 sprints * 2 weeks
Add membership card to Apple Wallet 13
Use mobile camera to scan UPC for product and add to cart for in-store
purchase 8 The Forecast for that PBI:
? Sprint 9+ ?
Complete in-store mobile purchase 8 It’s done at the end of 8 weeks
Teach cats to do tax preparation 80
RFID-based inventory control system 80
Migrate application hosting to external cloud provider 40
Talking unicorns 120
 Product Backlog
Name Size
Update payment system to convert USD to Bitcoin 8
Fix layout and click problems on Safari on iPhone 6 3
Sprint 1
Forecasting
Update payment system to support ApplePay 5
Request PDF receipt delivered by email for past purchase 2
Generate report to see orders by payment type 3
Update payment system to take PayPal payments 5
Mark transaction for fraud audit 8 Sprint 2
Upgrade site layout to support Internet Explorer 11 8 Question:
Refund in-store mobile purchase from administrator device 5
Fix bugs related to jQuery upgrade (Defect #123, #456, #321, etc.) 3 What can we ship at the end of
Fix bugs related to declined transactions using debit cards (Defect
#132, #821) 3
60 days?
Book pre-paid appointment 2 Sprint 3
Request PDF summary of all purchases for date range 3
Redeem gift card for in-store purchase 2 Average Velocity = 21
Redeem gift card for mobile purchase 3
Update public-facing website to use new logo and color scheme 5
Update paid-user website to use new logo and color scheme 3 Sprint Length = 3 weeks (21 days)
Update Android app to use new logo and color scheme 2
Update iOS app to use new logo and color scheme 1 Sprint 4
Real-time in-store purchase notification for managers on mobile admin 60 days = ~ 2.85 sprints
app 5
Request printed receipt after in-store mobile purchase 5
Feature XYZ
Feature ABC
13
13
? Sprint 5 ? That’s somewhere inside of Sprint 3
Use mobile camera to scan UPC and do a price comparison 21 ? Sprint 6 ?
Create a lasting world peace 21 ? Sprint 7 ?
Feature QWERTY 21 ? Sprint 8 ? (Hint: There isn’t a perfect answer.)
Reporting dashboard for iOS & Android 40
Federated Identity using external authentication providers 40
Add membership card to Apple Wallet 13 The 60 Day Forecast:
Use mobile camera to scan UPC for product and add to cart for in-store Sprint 1 & Sprint 2 is highly likely.
purchase 8
Complete in-store mobile purchase 8
? Sprint 9+ ? Probably some of Sprint 3, too.
Teach cats to do tax preparation 80
RFID-based inventory control system 80
Migrate application hosting to external cloud provider 40
Talking unicorns 120
 Reminder:
Both of these ‘tricks’ require
1) a known velocity and
2) a ready product backlog.
As a Scrum Master, you’ll run into people
who are skeptical of Scrum.
One of the most common misperceptions
is that you have no clue when anything
is going to be done in Scrum.
 Use these two ‘tricks’ to
help you to prove them wrong.
 In Summary
 Track your team’s Velocity in each Sprint

 Start doing Backlog Refinement Meetings

 Estimate your PBIs

 This gives you a ‘Ready’ Product Backlog

 A ‘Ready’ Product Backlog helps you to plan and forecast

 Next up:
How to estimate your PBIs.
Estimating.
If you want a known Velocity and a
Ready Product Backlog,
you need to estimate your PBIs.
 My suggestion:
Don’t try to estimate your PBIs using hours.
 Nearly everybody’s suggestion:
Don’t try to estimate your PBIs using hours.
Use ‘Story Points’.
“Story Points? But I want to estimate in hours.”
First off…
DON’T PANIC.
Take a deep breath.
It’ll be ok.
 If you feel faint,
put the video on pause and
sit down for a bit.
Have a sip of water or some juice or something.
 When it comes to estimating PBIs,
you’re never estimating them in hours ever again.
Did you pass out?
You’ll be ok.
We’ll make it through this together.
Why not hours?
 Because estimating PBIs in hours
is a nightmare and a waste of time.
It doesn’t work.
It just doesn’t work with
any degree of accuracy.
One person delivering something simple?
Accuracy of Estimate in Hours: OK.
One person delivering something moderately complex.
Accuracy of Estimate in Hours: Wobbly.
A team delivering something moderately complex.
Accuracy of Estimate in Hours: Garbage.
You can spend more time trying to make your hour-
based estimate more accurate…
…but that probably isn’t a good use of time.
You’re trying to make your estimate better so that your
estimate isn’t wrong rather than actually just
DOING THE WORK.
 Scrum Masters, your team will tend to
want to just not be wrong. Help them focus on
delivering something instead of not being wrong.
You can spend a near infinite amount of time
trying to estimate your PBIs in hours and your
accuracy is still going to be pretty bad.
Story Point estimation gets you a
‘good enough’ estimate
with a lot less work.
The Goal of Story Point Estimation:
get a team-based estimate of the
rough level of effort/complexity.
How?
Compare estimated effort of
undone work against
the complexity of work
you already did.
 You aren’t trying to be exact.
You’re trying to be pretty close.
Software is hard.
 Life of a Software Developer

I hate when
What?
Coding…coding…coding… this
Black hole?
Happy…happy…happy… happens.

“Oh. A logical corner. I guess I have WARNING:

to change direction a bit.”
BLACK HOLE
 The only way to find logical
black holes is to trip over them.
Things sometimes take longer than you expect.
That makes those hour-based estimates
kinda tricky.
You don’t know how long something
is going to take until it’s done.
 You usually have a feel for how
complex something is going to be.
Use done pieces of work to estimate
undone pieces of work.
 Story Point Estimation:
“This feels like roughly the same amount
of effort as PBI XYZ that we did last month.
Therefore, I’m going to give it the same
Story Point value.”
Another thing.
In Scrum and in story point estimation,
you’re estimating how long it takes for
THE TEAM to deliver the PBI to
Definition of Done.
You’re not estimating how long it’ll take
an individual to deliver the PBI.

It’s always the team.

 Getting started with
story point estimation.
 Your available values:
1, 2, 3, 5, 8, 13, 21, 40, 80, 120, infinity.
 ‘Buckets’ of Estimation
Story Points Description
1 Tiny
2 Small
3 Small-ish
5 Medium
8 Medium-Large
13 Large
21 Extra Large
40 Huge
80 Extra Huge
120 Bonkers
Infinity Size of the Universe; Too big to comprehend
 How to Estimate for the First Time
Story Points Description 1. Get the team together
1 Tiny
2. Pick a medium-sized PBI that you’ve already done
2 Small
3. That PBI  5 Story Points
3 Small-ish

5 Medium 4. Establish some context by estimating more PBIs

you’ve already done.
8 Medium-Large

13 Large Are they the same, bigger, or smaller than the

already done PBI?
21 Extra Large

40 Huge 5. Start estimating PBIs you haven’t done.

80 Extra Huge
Is it the same, bigger, or smaller than the
120 Bonkers already done PBI?
Infinity Size of the Universe; Too big
to comprehend Always estimate undone PBIs in the context of
already done PBIs!
 Next:
A technique for team-based estimation.
Estimating is something
you should do as a team.
You’re all going to do the work together.
So you should estimate it together.
 The estimates that you give to a PBI
are for the team to deliver the entire PBI to Done.
Planning Poker
 Everyone gets a set of cards.
1, 2, 3, 5, 8, 13, 21, 40, 80, 120, infinity, & question.

1 2 3 5 8 13 21 40 80 120 ∞ ?
 The Planning Poker Process
1. Someone reads off the PBI
2. Brief discussion
3. “Ready to vote?”
4. “1..2..3..vote”
5. Everyone displays the card that represents their story point estimate for
the team to get the entire PBI to Done
6. Discuss high and low values
7. Repeat 3 – 6 until you’ve reached consensus
 I can’t stress this enough.
Each person is estimating the amount of
effort it will take for THE TEAM to
deliver the entire PBI to DoD.
Here’s a random
picture of a cat.
Did that snap your brain back into focus?
This is super important.
Let me remind you…
 The card that you throw is *not*
for only *your* effort on that PBI.
The card you throw is for what you think
amount of effort will be for THE TEAM to
deliver the entire PBI to
the Team’s Definition of Done.
“Implement security system for website”
Planning Poker Round 1

Person Vote
David
Rafiq
Anna
Brian
Esther
“Implement security system for website”
Planning Poker Round 1

Person Vote
David 2
Rafiq 21
Anna 13
Brian 8
Esther 13
“Implement security system for website”
Planning Poker Round 2

Person Vote
David
Rafiq
Anna
Brian
Esther
“Implement security system for website”
Planning Poker Round 2

Person Vote
David 8
Rafiq 13
Anna 13
Brian 8
Esther 5
“Implement security system for website”
Planning Poker Round 3

Person Vote
David
Rafiq
Anna
Brian
Esther
“Implement security system for website”
Planning Poker Round 3

Person Vote
David 5
Rafiq 8
Anna 5
Brian 5
Esther 5
Use this with your teams.
Take advantage of the
Wisdom of Crowds.
Helps you to discuss differences
of opinions.
Helps you to come to a
pretty good estimate
without a lot of effort.
 Summary
 Tighten up your existing Scrum  Keep your backlog ‘Ready’
process
 Start estimating with Story Points
 Define and refocus on Done instead of hours

 Do less work at one time  Planning Poker

 Measure your Velocity