Tribus

35
Agile Foundations
Housekeeping

• Name Tags

• Please give your full attention

• Turn cellphones off & check them during breaks

• Same with computers – please put them away

• This is interactive experiential learning

• Get involved, Ask questions

• Its ok for us to deviate from the slides!

• Give Actionable Feedback

Traditional Software Development
System
Requirements

Software
Requirements

Analysis

Program
Design

Testing

Coding

Operations
Traditional Approach

• Future is Predictable
• Nothing will substantially change
• We know everything ahead of time

Predict & Plan Therefore…

• Plan everything up-front
• Make most decisions ahead of time
• If we build according to spec, we’ll get
what we expect
 Traditional Value Delivery

Value Delivered

100% of Customer Value

Delivered at Product
Launch

Analysis Design Development Test

0

Week 2 4 6 8 10 12 14 16
How Was That Working?
Project Success Rate
Standish Group Chaos Report, 2004

Failed
15%

Challenged
51%
Succeeded
34%
 Agile
Something Different
Snowbird Utah, 2001
Four Agile Values

Agile Manifesto
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

http://agilemanifesto.org/
Efficient or Effective?

There is nothing quite so useless, as

doing with great efficiency, something
that should not be done at all.
― Peter F. Drucker
Do we know what’s needed up front?
Never Rarely Sometimes Often Always

7%
13%
45%
16%

19%

Always / Often Rarely / Never

Used 20% Used 64%
VALUE WASTE
A Different (Agile) Approach

• We can’t predict the future

• Change is to be expected
• We can’t know everything ahead of time

Sense and Respond Therefore…

• We plan as we go
• We make decisions based on what we’re
learning
• Everything is done empirically
Agile Value Delivery

Frequent Convergence Generates

Learning &
Creates Transparency
Value & Learning Created

Value is Delivered Incrementally

With Each Release

Sprint 1 2 3 4 5 6 7 8
We must learn what
customers really want, not
what they say they want or
what we think they should
want.

- Eric Ries
The Lean Startup
 Agile
Principles
 12 Agile Principles

1. Our highest priority is to satisfy the

customer through early and continuous 7. Working software is the primary measure of
delivery of valuable software. progress.
Customers

Culture
2. Welcome changing requirements, even late 8. Agile processes promote sustainable
in development. Agile processes harness development. The sponsors, developers, and
change for the customer's competitive users should be able to maintain a constant
advantage. pace indefinitely.

3. Deliver working software frequently, from a 9. Continuous attention to technical excellence

couple of weeks to a couple of months, with and good design enhances agility.
a preference to the shorter timescale.

4. Business people and developers must work

together daily throughout the project.
10. Simplicity--the art of maximizing the amount
of work not done--is essential.
Environment

5. Build projects around motivated individuals. Excellence

Give them the environment and support
11. The best architectures, requirements, and
they need, and trust them to get the job
designs emerge from self-organizing teams.
done.
12. At regular intervals, the team reflects on how
6. The most efficient and effective method of to become more effective, then tunes and
conveying information to and within a
adjusts its behavior accordingly.
development team is face-to-face
conversation.

http://www.agilemanifesto.org/principles
Incremental
What assumptions do
we make when working
this way?

Source: Jeff Pa tten

Iterative
Now what assumptions
are we making?

Source: Jeff Pa tten

Incremental & Iterative

In practice we blend
both
Leonardo actually did this

Iterations of “Lady with Ermine” discovered through Layer Amplification

Prioritized
Deliver the Highest Value Early

Copyright Tobias Mayer/Agile Thinking

Don’t Neglect the Big Picture

Real Teams Have Singular Focus
Group accountability
• Succeed or fail together
• Work on stuff together
• All for one and one for all!
Communication
The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
Transparency
Agile calls for teams to be “self-organizing” and the business to
“trust” the teams this requires complete transparency
• Release & Iteration Plans
• Progress –
• Burn-down / Burn-up Charts, Regular progress reviews, Demos of working
software
• Metrics
• e.g. Quality, cycle time, issue resolution, working shippable functionality
• Impediment Lists

Status is published naturally & continuously

• As opposed to reported periodically
• All stakeholders are kept informed on progress and challenges

Everybody needs all the information!

Underlying Themes

Agile is iterative in nature in that it assumes that we do not know

Iterative everything at the beginning of a project, and that we will learn as we
explore and refine our understanding together.

Agile is incremental in nature in that it aims to deliver value to the business on

a regular basis, in small increments. And in doing so it allows us to reflect on
Incremental
our work, learn from our shared experience, and modify our priorities to
accommodate changes in our environment.

Agile teams work in a highly collaborative way with a focus on collective

Collaborative
ownership and collective responsibility.

Agile teams understand that by being honest about our current state,
Transparent past experiences, and future expectations, we can make better decisions
and are more likely to achieve the desired project outcome.
Agile – Lots of Options
• asdf
Agility is
more attitude
than process,
more environment
than methodology .
Jim Highsmith, Agile Project Management

Kanban Roll your

Lean Own!

Crystal LeSS

XP SAFe
Scrum
DSDM DAD
Scrum – Practicing “the art of the possible”

[Scrum is] a framework

within which people can
address complex adaptive
problems, while
productively and
creatively delivering
products of the highest
possible value.

Source: Schwaber, Ken and Sutherland, Jeff, “The Scrum Guide” http://www.scrumguides.org
“Scrum” is from Rugby
• The team moves the ball together
• Players have roles, but adjust based on circumstances
• They plan the game one play at a time
• They win or lose as one
Scrum Guide
Reading
Three Roles

• Scrum has only these distinct roles:

• Product Owner
• Scrum Master
• Development Team
Product Owner

“Business people and

developers must work
together daily throughout
the project.”
Product Owner
• Responsible for building to the Project Charter / Vision
• The voice of the customer
• Owns the product backlog
• Guides the team in crafting an effective
solution for the business need
• Approves all functionality
• Communicates plans & progress

Usually non-technical and business focused, the Product Owner

is focused on what the project needs to achieve, rather than the
technical details of how it is implemented.
The “Product Owner” Problem
A single, pivotal, person to be 100%
available to the team, work with the
stakeholders, and also manage a backlog?
ScrumMaster
• Builds a high performing team
• Servant Leader & “Mirror to the Team”
• Facilitator and process coach
• Fends off external interferences
• Communicates teams abilities
• 100% Allocated to a team

Usually non-technical and people focused. The Scrum Master is

focused on creating the right environment for the team to excel.
Works relentlessly to remove impediments for the team and
create the conditions for success.
The “ScrumMaster” Problem
It might look like it sometimes…But by no
means am I the captain of this ship!
ScrumMaster Tips
Does Not: Is Not:
• Direct team-members • Line Manager
• Assign work • Project Manager
• Admin / Secretary
• Perform resource allocation
• Product Owner
• Make decisions for the team
• Overrule team-members
• Report on project progress
• Direct product strategy
• Decide technical issues
• Have authority to stop the
team from failing
Development Team
Cross functional, dedicated Partner with Product Owner to:
5-7 people (small is preferred) • Split and size Product Backlog items
• Identify sprint tasks &
100% allocated to the team estimate effort
BA/Tester • Create simple, valuable,
Designer BA high-quality product

Developer
Development Developer
Team
Development
Developer Team Tester

DBA
IT
Steering
Manager
Committee Development
Scrum Team Product
Master Scrum Owner

Ops Team Architect

Account
Agile
Manager
PM Business
/ Customer

Note: an example team, not a recommendation

The best architectures,
requirements,
& designs emerge from
self-organizing teams.
The Scrum Team (aka “Squad” or “Core” Team)
Joint ownership & collaboration to solve problems
Self-organizing, self-managing
Everyone is:
• Responsible for identifying and BA/Tester

solving impediments Designer BA

• Accountable to each other Development

Developer Developer

Produces high-quality, Team

Development
valuable product Developer Team Tester

DBA
IT
Steering
Manager
Committee Development
Scrum Team Product
Master Scrum Owner

Ops Team Architect

Account
Agile
Manager
PM Business
/ Customer
What makes a good Squad?
• Small Size
• Alignment around Shared Purpose
• Trust
• Right Skills
• Good communication
• Ability to set own Goals & Process

Source: Stack Overflow

Not finance. Not strategy. Not technology. It is teamwork

that remains the ultimate competitive advantage, both
because it is so powerful and so rare.
- Patrick Lencioni
Ball Point
Game
The ”Scrum Team” Problem(s)
The Scrum Team (aka “Squad” or “Core” Team)
Many others are vital to the success of the team, but are not
considered part of the Scrum team unless 100% allocated.
This is where the term “Squad” is useful.
BA/Tester
Product Owner must partner with Designer BA

business stakeholders or end

customers. Developer
Development Developer
Team
Development
IT Management & Developer Team Tester

ScrumMaster jointly DBA

IT
Steering
focus on enablement Committee Development
Manager

of the Scrum Team. Scrum

Master
Team
Scrum
Product
Owner

Ops Team Architect

Account
Agile
Manager
PM Business
/ Customer
How does my role change?
Traditional Approach to Dev & Test

Let’s make toast the American

way… You burn, I’ll scrape.

W. Edwards Deming (1900-1993)

T-Shaped People

• Get outside of your roles

• Flexibility = effectiveness
• T-shaped not square!

Source: Valve Inc. Company Handbook

The WHOLE TEAM owns Quality!

“If you really want quality, you don’t inspect after the
fact, you control conditions as not to allow defects in
the first place. If that is not possible, you inspect the
product after each small step, so that defects are
caught immediately after they occur.”

Poppendieck, Mary and Tom, Implementing Lean Software Development: From

Concept to Cash, Addison Wesley, 2007
Even the Manager’s Role Changes

“Build projects around motivated

individuals. Give them the
environment and support they
need, and trust them to get the
job done. “
Even the Manager’s Role Changes

Managing & Directing Designing organizational

People environments (motivation, etc.)

Establishing objectives; keeping

Defining & enforcing attention closer to where things are
policies and rules of engagement happening; keeping necessary
(abstracting out details)
details transparent

Push decision-making down to

Making project decisions
teams

Collaboratively establishing and

Managing to the Project Portfolio managing to broad business goals
and objectives
Even the Manager’s Role Changes

Coordinating project Building trusting relationships with

implementation details business, characterized by transparency
with business and collaboration

Managing Systems & Designing organizational environments

Processes (motivation, etc.)

Understanding what those problems reveal

about underlying organizational
Solving Problems dynamics/structures and our own
thinking; people close to the problem
space solve problems as they arise
Garabatos
The Scrum Framework
Typical Agile Delivery Cycle

release 1 release n

Target
Project System
Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint n
Inception
Discovery Set up Project
Assessment Infrastructure
Incremental delivery in time-boxed sprints
Daily Stand-Up (aka “Scrum”)
• Time-box
• 15 Minutes Daily
• Purpose
• A planning meeting, not a status report
• Only the Scrum Team can speak
• Typical format
• What did we get done yesterday?
• What are we going to get done today?
• What is slowing us down?
• Do not solve problems
• Note them down & address afterward
• Publish all impediments!
Sprint Planning
• Time-box
• Relative to 1 hour per week of Sprint Duration Sprint 1

• Purpose 120

100

• Elaborate requirements 80

Hours
• Identify dependencies and impediments 60

40

• “Get Ready!” 20

• Guidelines
0
1 2 3 4 5 6 7 8 9 10
Days

• Include ALL Team members Hours Remaining

• Formulate a Sprint Goal

• Decompose all work into
bite-sized, testable chunks
(≤ 1day)
• Setup task board & burn-down
Sprint Review (aka “Demo”)
• Time-box
• Relative to 30 minutes per week of Sprint Duration
• Purpose
• Review Sprint Accomplishments
• Demonstrate Product & Collect Feedback
• Review Release Impacts
• Guidelines
• Include ALL Stakeholders
• Only demonstrate completed stories
• Emphasize business value
delivered
Sprint Retrospective (aka “Demo”)
• Time-box
• Relative to 1 hour per week of Sprint Duration
• Purpose
• To inspect and adapt the team’s process
• To brainstorm ways to improve the team, teamwork,
and the process
• Guidelines
• Identify Positives and Changes
• Determine Action Items
Sprint
• Tips Sprint
Execution
Sprint
Plan Results
• Know what “improve” means
• Be S.M.A.R.T
• Be Focused Retrospective
• Follow Through, Publish Feedback
Actions, and Review Outcomes
Every Sprint Ends with a Retrospective

Product
Inspect and Adapt
Build

Agile Retrospectives: Making Good Teams Great!

Esther Derby and Diane Larsen
Backlog Refinement (aka “Grooming”)
• Not officially part of Scrum, but very beneficial!
• Time-box PRODUCT BACKLOG

RELEASE SCHEDULE
• Typically 1 – 1.5 hours per week

0 - 6 Months *
CURRENT
• Purpose

HIGH
• Size Product Backlog Items
• Decompose Backlog Items

RELEASE SCHEDULE
• Convey requirements

6 - 12 Months *
FUTURE
• Consider Big Picture

Prioritization
• Maintain a flow of “Ready” stories to the team
• Guidelines

RELEASE SCHEDULE
• Hold more than 1 per Sprint

12 + Months *
• One Big Picture, one Near Term

FUTURE
• Discuss the product concept and context

LOW
✴ Examples only
The Scrum Process – Important!
• Sprints are NOT mini waterfalls
• Analysis, design, development and testing is continuous
throughout a product backlog item’s lifecycle

• No Sprints planned around specific functional activities

• No analysis Sprint, followed by design Sprint, followed by
development Sprint etc.

• Tackle stories as cross-functional teams

• Avoid functional hand-offs
• Work as a team and “swarm”
Origami
Tracking at Sprint Level

Alignment

Sustainable
Transparency
Pace
Tracking Needs Granularity: Here is one way…
Product Backlog (Stories) Iteration Backlog (Tasks)
As an investor, I want Define initial test cases 4
3
Iteration 1

to…
Login Happy Path 8
As an investor, I want
5
to… Expired Passwords 12

As an investor, I want Invalid Users 12

5
to…
Iteration 2

Security Lockout 6
As a visitor I want to… 1

As an investor, I want
2
to…

As a visitor I want to… 3

Measured in
Ideal Hours
Iteration 3

As a visitor I want to… 3

Measured in
Story Points
An investor I want to… 2
Easier Alternatives
• Ideal Hours are good to start with
• But they can cause confusion
• Task estimation can consume a lot of time

• Other ways
• Story Points
• Break work into very small stories (1/2 or 1 point)
• Track Story Points Complete / Remaining

• Count of Tasks / Activities remaining

• Requires tasks be somewhat similarly sized
• Ideally ½ day or less
Sprint Tracking – The Burn-Down Chart
• Sprint Progress Dashboard
• Daily sum of “work remaining”
• Is the team on-track to complete planned sprint work?
• Which stories are at risk of not being completed?
• Do I need to add or remove stories from the sprint?
Sprint Tracking – The Burn-Down Chart

Sprint Burn-down

Work Remaining
600
Sum of daily task
estimates
500

400 Ideal Line

Linear target
completion rate
Hrs

300

200

100

0
1 2 3 4 5 6 7 8 9 10

Work Remaining Target

Basic Iteration: Burn-Down Analysis
Basic Iteration: Burn-Down Analysis

Behind Plan
± 200 hours over
Basic Iteration: Burn-Down Analysis

Ahead of Plan
± 200 hours
under
Tracking at Release / Milestone Level

Forecasting

Transparency

Expectations
Management
Estimation, and the Consequences
Velocity Changes over Time

Last Iteration = 36
Mean (planning) = 31
Mean (worst 3) = 29
Velocity (points)

Sprint
Source: Adapted from Mike Cohn, Agile Estimation and Planning
 Updating the Multi-Sprint Plan
End of Sprint 4 (of an 8 Sprint Release) Product Backlog
Running Total Points Feature
8 8 A
30 16 8 B
29 13 D
22

20
20
37 8 F
Velocity

15
42 5 C
50 8 T
10 9
Done &
Ready to Ship! 58 8 G

0
66 8 O
1 2 3 4 5 6 7 8
79 13 I
Sprint
87 8 H
92 5 M
Mean of worst 3 = 14.5 66 + 14 * 4 = 122 100 8 K
105 5 U
Long-term average = 16.5 66 + 16 * 4 = 130
Worst Case 118 13 J
121 3 L
Expected 126 3 N
129 3 Q
131 2 R
Save for Next Release 139 8 S
152 13 X
 Updating the Multi-Sprint Plan
End of Sprint 5 (of an 8 Sprint Release) Product Backlog
Running Total Points Feature
8 8 A
30 16 8 B
29 13 D
22

20
20
37 8 F
Velocity

15
13
42 5 C
10 9 50 8 T

Done & 58 8 G

0 Ready to Ship! 66 8 O
1 2 3 4 5 6 7 8
79 13 I
Sprint
87 8 H
92 5 M
Mean of worst 3 = 12.3 79 + 12 * 3 = 115 Worst Case 100 8 K
105 5 U
Long-term average = 15.8 79 + 15 * 3 = 124
Expected 118 13 J
121 3 L
126 3 N
129 3 Q
Save for Next Release 131 2 R
139 8 S
152 13 X
 Updating the Multi-Sprint Plan
End of Sprint 6 (of an 8 Sprint Release) Product Backlog
Running Total Points Feature
8 8 A
30 16 8 B
29 13 D
22
21
20
20
37 8 F
Velocity

15
13
42 5 C

10 9 50 8 T
58 8 G

0
66 8 O
1 2 3 4 5 6 7 8
79 13 I
Sprint
Done & 87 8 H
Ready to Ship! 92 5 M
Mean of worst 3 = 12.3 100 + 12 * 2 = 124 100 8 K
105 5 U
Long-term average = 16.6 100 + 16 * 2 = 132
Worst Case 118 13 J
121 3 L
126 3 N
Expected 129 3 Q
131 2 R
139 8 S
Save for Next Release 152 13 X
 Updating the Multi-Sprint Plan
End of Sprint 7 (of an 8 Sprint Release) Product Backlog
Running Total Points Feature
8 8 A
30 16 8 B
24 29 13 D
22
21
20
20
37 8 F
Velocity

15
13
42 5 C
10 9 50 8 T
58 8 G

0 66 8 O
1 2 3 4 5 6 7 8
79 13 I
Sprint
87 8 H
92 5 M
Mean of worst 3 = 12.3 124 + 12 * 1 = 136 100 8 K

Done & 105 5 U

Long-term average = 17.7 124 + 17 * 1 = 141
Ready to Ship! 118 13 J
121 3 L
126 3 N
Worst Case 129 3 Q
131 2 R
Expected
139 8 S
Save for Next Release 152 13 X
 Updating the Multi-Sprint Plan
End of Sprint 8 – Release! Product Backlog
Running Total Points Feature
8 8 A
30 16 8 B
24 29 13 D
22
21
20
20
37 8 F
Velocity

15
13
42 5 C
10 9
8
50 8 T
58 8 G

0 66 8 O
1 2 3 4 5 6 7 8
79 13 I
Sprint
87 8 H
92 5 M
Mean of worst 3 = 10 100 8 K
105 5 U
Long-term average = 16.5
118 13 J
121 3 L
126 3 N
129 3 Q
Done &
Ready to Ship! 131 2 R
139 8 S
Save for Next Release 152 13 X
 Iter 12
Iter 11
Iter 10
Release
Iter 9
Total Project Size Estimate
Tracking Release – Burn-Up Charts

Iter 8
Iter 7
Iter 6
Iter 5
Points Delivered

Iter 4
Iter 3
Iter 2
Iter 1
Start
Release Forecasting
• Agile planning and forecasting are continuous and adaptive

• Revisit the plan frequently

• At the end of every iteration
• Just like in the previous worked example
• Publish and socialize

• Update plan based on:

• Current understanding of velocity
• Current prioritization of backlog

• Should take very little time – but is highly effective

Plans are worthless, but planning is everything.

– Dwight D. Eisenhower
Product Vision
• Acts as the overall goal
• A sketch of the product at a coarse-grained level
• Communicates the essence of the product
• A shared goal that provides direction but broad enough to facilitate
creativity
An Example, an iPod Elevator Pitch

“In your pocket”

The iPod will be a portable digital music player
that will hold 5000 songs. It will have a battery
life measured in days, not hours. You will navigate
the thousands of songs with a single finger. You
will sync all your music from your computer to
the iPod in minutes automatically, so you can
have all your music in your pocket.
Elevator Pitch

FOR <target customer>

WHO <statement of the need>
THE <product name>
IS A <product category>
THAT <key benefit>
UNLIKE <primary competitor>
OUR PRODUCT <further differentiation>
(From Geoffrey Moore, Crossing the Chasm)
Example Elevator Pitch, Silicon Graphics

For post-production film engineers, Who are

dissatisfied with the limitations of traditional
film editors, Our (the) workstation is a digital
film editor That lets you modify film images
any way you choose. Unlike workstations
from Sun, HP, or IBM, We (our product) have
assembled all the interfaces needed for
post-production film editing.
(From Geoffrey Moore, Crossing the Chasm)
Example Elevator Pitch, Intuit
For the bill-paying member of the family
who also uses a home PC, Who is tired of
filling out the same old checks month after
month, (the) Quicken is a PC home finance
program That automatically creates and
tracks all your check-writing. Unlike
"Managing your Money," a financial analysis
package, Our (product) system is optimized
specifically for home bill-paying.
(From Geoffrey Moore, Crossing the Chasm)
Requirements

Two things are known about

requirements:
1. They will change!
2. They will be misunderstood!
Michael Jackson
International Conference on Requirements Engineering
User Stories

“Simplicity--the art of
maximizing the amount of
work not done--is
essential”
Stories – “A Ticket to a Conversation”

• Placeholder for conversation

Card • Stories traditionally written on index cards
• Cards annotated with estimates, notes, etc.

• Actual discussion between dev team and user

Conversation • Underlying details emerge during conversations with
Product Owner

• Acceptance criteria to determine when the story is

Confirmation finished and to confirm proper implementation

Ron Jeffries’ 3 Cs – Card, Conversation and Confirmation “A ticket to a conversation” – A. Cockburn

The Card
The Conversation

I want the toast to pop up

when it’s done.

That’s really expensive. The

popping part is easy –
that’s just a spring. But
knowing when the toast is
done requires an optical
sensor – new technology.
The Conversation

But what about all the other

toasters out there?

Oh, they use a timer. They

don’t really know when the
toast is done. It’s a kludge.
The Conversation

Our customers don’t need a

super toaster. They’d be happy
with a regular toaster, with a
timer, like everyone else.

Oh, that won’t be expensive

at all. That’s easy.

Great!
The Confirmation (Acceptance Criteria)
Tips: Avoid Story Detail!
• If it reads like a spec, people treat it like a spec
• The Conversation doesn’t happen!
• Results in attribute-driven story instead of goal-driven
• Results in misunderstanding the written word

• Fill in the details later

• When stories are Refined
• When we do Sprint planning
• As we build out the tests and code
Tips: INVEST Model

Independent
Epic
Negotiable
Valuable
Big
Story Estimable
Small
Detailed
Story
Testable
Tips: Understand Users

First Step to creating user stories

• What types of users will use this software?
• What goals will they hope to achieve?
• What tasks will they need to perform?
• Which of these tasks will we support?

Source: Jeff Patton. “Personas, Profiles, Actors & Roles. Modeling users to target successful product design”
SD Best Practices Conference and Expo 2007.
Tips: Understand Users Through Profiles/Personas

• Enhance common understanding & enrich user stories

• Help with adding or removing functionality from scope
• Make better tactical design decisions
• Compare with actual users to validate assumptions
• Avoids self-referential design – We’re not building the
software for ourselves?

Adapted from: Jeff Patton. “Personas, Profiles, Actors & Roles. Modeling users to target successful product
design”. SD Best Practices Conference and Expo 2007.
 Story
Writing
Does it mean what you think?

SHIPPABLE
Has this ever happened to you?

Hey, is that done yet?

Yeah, basically.

• Many times, something as innocent as “done” is subjective

• We need a common, shared perspective to collaborate as a
team
• Definitions vary and are dependent upon the priorities and
context of a given situation
• A team’s definition of done (DoD) should evolve over time
Examples: Definition of Done (Story Level)

Tested & Defect Free

Deployed to Dev

Code Reviewed

Checked-In to Harvest

Reviewed by PO or Proxy

Wiki updated w/ design

spec
Estimation Psychology
Actual Estimates…Really Hard Relative Estimates…Much Easier
Imagine…
You want to change careers…

New Profession?
House Painter

First Job?
Paint the Exterior of a House

How might we estimate how

long this would take?
How might you estimate this?
One way:
• Estimate the exterior surface size
• Begin painting
• After an hour, see how much has been
painted
• Extrapolate the total duration

I think that’s approximately 2,500 ft²

After an hour I’ve painted 250 ft²
So, I should be done in a total of 10 hours
Velocity – a measure of capacity
• In Agile teams we measure our capacity for work
• How much we can get done per week / month / Sprint as a team

• We use this to aid forecasts of what we can accomplish

next iteration

• We also use it to derive the length of the project

• Thus we ensure:
• Quality
• Predictability
• Sustainable pace
Story Points
• The “bigness” of a task
• The amount of effort
• Not the duration! Story Points

• Influenced by: User Story

• How hard it is B
2 Points
• How much of it there is User
Story A
8 Points
• Psychological advantage

• Relative values are what is important

• A login screen is a 2
• A search feature is an 8
• Means the search feature requires about 4x effort
• Points are unit-less and unique to a team
Planning Poker
What is it?
• It is a tool to facilitate group sizing

What do you need?

• Entire Scrum Team – including Product
Owner/customer
• Deck of planning poker cards with point sizes (or a
virtual equivalent)
• Product Backlog Items to Size
Planning Poker
Commonly use modified Fibonacci as advocated by Mike Cohn
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinite (or too big)

A 1-point and 2-point story are easily distinguishable

The 2-point story will be twice the size of the 1-point story

A 17 and 18 story are not very distinguishable

What’s the difference between 17 and 18 anyway?
Planning Poker – How to Play
1. Each team member is given a deck of cards – each card has a point size
written on it
2. Customer/Product-Owner reads a story
- Customer must be knowledgeable enough to discuss each story
3. The story is briefly discussed, questions answered etc.
- The discussion should be sufficient to determine the complexity and relative
size of the work
4. Compare story to other, previously sized stories
- Use analogy and triangulation techniques
5. Each team member secretly selects a card that is his or her estimate
- Sizes should be presented together
6. Cards are presented to the group at the same time
- Each person’s opinion is represented
7. Differences and outliers are discussed
- Discuss why some people think a story is bigger than what other people think
8. Re-estimate until estimates converge
- Sometimes the exercise needs to be time-boxed, sometimes some
negotiation is needed
- If the team can’t agree the PO may need to further define or refactor the
story
Final Words on Story Points
• Benefits:
• Point sizes don’t decay
• Sizes don’t change based on estimator
• Are independent of the implementer
• Measure of size, not duration
• Encourage cross-functional behavior

• Shortcomings:
• Can be difficult to get started
• Must estimate initial velocity
• or you can easily get it after 1 iteration
• It can be a difficult concept to communicate to the business
• Language & Variability
• Points are unique to a Project & Team
Play Planning
Poker
Pajarraco
Something from the Agile Capability
Capability Lead: Rafael Bulfon
Agile.ADC.Certification [email protected]
Agile.ADC.Leads [email protected]
Agile.ADC.Training [email protected]
Agile.ADC.RFPSupport [email protected]

If you want to get involved, feel free to contact any of the initiatives.

Also we are allways looking for new candidates for our Train The Trainner
program.
Next steps
After the training you will recieve a summary email with the Training
contents and some additional info.

You are now ready to get the Agile Professional Certification, you can
register on:
mycertification.accenture.com

The Certification team will also be inviting you to participate of the

certification workshops.

Other Trainings:
We are also providing Scrum.org and SAFe Trainings,
Who is who
Retro
Course Feedback