Mark Windholtz from ObjectWind Software Ltd discusses the principles and practices of Extreme Programming (XP), emphasizing the importance of delivering software on a deadline through iterative planning and continuous feedback. The document describes the roles of management and programmers within an XP framework, including methods for release and iteration planning, measuring progress, and ensuring code quality through testing. It also highlights ObjectWind's services in agile software engineering and training.

1. Planning XPPlanning XP
Mark Windholtz
ObjectWind Software Ltd

2. www.ObjectWind.com 2
Who Am I
♦ Mark Windholtz
♦ ObjectWind Software Ltd
♦ 14 years Building Professional Software
♦ Business, Medical, Engineering, Military
♦ First contact with XP in Oct 1996
♦ Started Six XP teams
♦ Consulted for Eight other XP teams

3. www.ObjectWind.com 3
Delivering to Deadline
XP is about delivering to deadline.
Every two weeks you release something
and every two weeks you check your plan.
You get really good at getting stuff done.
- James Grenning, ObjectMentor

4. www.ObjectWind.com 4
A Local XP Team

5. www.ObjectWind.com 5
What Management Gets
♦ Management gets …
– An Overall release plan (What, when, and how much)
– Most value out of each programming week
– Visible Progress: code running repeatable tests
– To Change direction as business changes
– Be informed early of schedule changes

6. www.ObjectWind.com 6
What Programmers Get
♦ Programmers are …
– told what is needed in priority order
– Allowed to produce quality work
– Allowed to ask for help
– Allowed to make and update estimates
– Allowed to accept responsibility

7. www.ObjectWind.com 7
Business to Code Process
Product is a bunch of …
Release is a bunch of …
Iteration is a bunch of …
Acceptance Test is a bunch of …
Task is a bunch of …
Episode is a bunch of …
Test is a bunch of …
Code

8. www.ObjectWind.com 8
Time Scale
♦ Product: Years
♦ Release: Month(s)
♦ Iteration: Week(s)
♦ Acceptance Test: Small piece of Biz value
♦ Task: Technical task
♦ Episode: 1-3 hours then integrate
♦ Test: 1 to 5 minutes
♦ Code: 0 to 20 minutes to satisfy test case

9. www.ObjectWind.com 9
Release Planning Game
(Exploration )
“Too Big”
Split
the Story
(Customer)
Write a Story
(Customer)
Spike
the Story
(Programmers)
Estimate
a Story
(Programmers)
“Don’t Know”
Go to Planning
♦ Goal
– Understand what the system is to do
♦ Result
– A working set of estimates

10. www.ObjectWind.com 10
Release Planning Game
(Planning )
Choose
Scope
(Customer)
Sort Stories
by Value
(Customer)
Declare
Velocity
(Programmers)
♦ Goal
– Plan the next Release so it gives the most bang
for the buck.
♦ Input
– Set of estimated stories
♦ Result
– A prioritized list of stories currently planned to
by included in next release

11. www.ObjectWind.com 11
Iteration Planning Game
( finding a fit )
♦ Biz
– Scope
– Priority
– Features per
Release
– Date of Release
♦ Tech
– Estimates
– Consequences
– Process
– Detailed Schedule
Feature Requests
Estimates & Budget
What’s in / What’s out

12. www.ObjectWind.com 12
Time Scale
♦ Product: Years
♦ Release: Month(s)
♦ Iteration: Week(s)
♦ Acceptance Test: Small piece of Biz value
♦ Task: Technical task
♦ Episode: 1-3 hours then integrate
♦ Test: 1 to 5 minutes
♦ Code: 0 to 20 minutes to satisfy test case

13. www.ObjectWind.com 13
XP Episode Cycle
analysis
test
code
design
( refactor )
discuss with user
integrate or toss

14. www.ObjectWind.com 14
Velocity
♦ Tasks are estimated
– 1 to 3 ideal days
– Measured in relative task points
♦ How many task points were done?
♦ Historical velocity data
– Rough (but real) predictor future progress
– Cost, scope, schedule

15. www.ObjectWind.com 15
What is Progress?
♦ A Task is either Done or Not Done
– 70% done is meaningless
♦ Done means done!
– Done but not tested is meaningless
– Done but not integrated is meaningless
♦ Code is written in small, running pieces
♦ No large leaps forward in a fog …
… and falling off a cliff

16. www.ObjectWind.com 16
Unit Tests
♦ All production code is tested
♦ Tests provide incremental certitude
♦ Test graph
– Rough measure of accomplishment
– Quick indicator of a stalling project

17. www.ObjectWind.com 17
Unit & Functional Tests: 7/30
0
100
200
300
400
500
600
700
800
900
1000
1100
0 23 46 69 92 115 138 161 184 207 230
0
14
28
42
56
70
84
98
112
126
140
154
Total Tests:
Unit & Functional
Functional
Test Count
Iteration 012 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

18. www.ObjectWind.com 18
Unit & Functional Tests w/ Notes
0
100
200
300
400
500
600
700
800
900
1000
1100
0 23 46 69 92 115 138 161 184 207 230
0
14
28
42
56
70
84
98
112
126
140
154
Added many new
team members
Moved from
PC to HP-Unix
Worked
longer
hours
Refactored
some tests
Optimized
How Tasks
were
Determined
Iteration 012 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

19. www.ObjectWind.com 19
Unit & Functional Tests: Feb 2002
0
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
1400
1500
1600
1700
1800
1900
2000
2100
2200
2300
2400
0 25 50 75 100 125 150 175 200 225 250 275 300 325 350 375
Total Elapsed Business Days in Project
0
20
40
60
80
100
120
140
160
180
200
220
240
260
280
300
320
340
360
380
400
420
440
460
480
Iteration 30
(2 weeks)

20. www.ObjectWind.com 20
JUnit TestRunner in Eclipse

21. www.ObjectWind.com 21
Core Practices
Small Releases
Planning Game *
On-site Customer
Open Workspace
Continuous Integration
Collective Ownership
Sustainable Pace
Test-First *
Pair Programming *
Continuous Design Improvement
Simple Design
Coding Standard
Customer Programmer Team .
How to
Define Features Iteratively
How to
Build Features Iteratively
How to
Communicate & Schedule

22. www.ObjectWind.com 22
ObjectWind Services
♦ Agile Software Engineering Practices
– Your team, or
– Outsourced XP Projects
♦ Project Services
– Before: Design Reviews
– During: Project Reviews & Expert Coding
– After: Retrospectives (Lessons Learned)
♦ Training with Object Mentor
www.ObjectWind.com