Planning Extreme programming

Agenda





Planning
Roles in XP
Variables in Project Planning
Estimation approach in XP Planning
Planning stages





The Big plan
Release planning
Iterations
Stories
Tracking



Stand-up meetings
Visible Graphs
Bugs
Planning






To make best use of time available
To do important things first
Coordination between different
departments/people
To reduce stress
Managing exceptional situations
Managing change
Planning goals in XP



Remove fear and increase trust
Instead of big plan, there are constant course
corrections
Business people make business decisions




Technical people make technical decisions


Date
Priority
Scope
Estimates
Person who makes the business decisions is
called the customer
Customer





Understands the domain well by working in
that domain, and also by understanding how
it works
Can understand, with development's help,
how software can provide business value in
the domain
Is determined to deliver value regularly and is
not afraid to deliver too little rather than
nothing
Can make decisions about what's needed
now and what's needed later
Is willing to accept ultimate responsibility for
Planning approach of XP





Break development into two week cycles
called iterations
In each cycle, take up some features
(stories), and do requirement specification,
design, development, testing, release
Keeping cost, quality, time the same, change
the scope of the deliveries
Customer chooses the features to implement
Each Programmer chooses the features that
he/she will take up
Estimation

Use last task to estimate the next task
Scoping a project




Big stories
Rough estimates for each story
The number of people in the team
Any constraints
Release Planning







Allocates stories to releases and iterations
Break bigger stories into smaller stories
Estimate each smaller story
Defer less valuable stories
Done by customer and programmers
Customer defines stories, assigns priorities,
assigns stories to releases
Programmers calculate estimates, warn
about technical risks, measure team
progress to update the estimates
Release planning contd...





The release plan is a snapshot of the current
expectation
It could change based on changing customer
priority, or unexpected technical challenges
Planning should be done for around 2
months, beyond that the effort for updating
plans becomes very high
Stories should center around functionality –
infrastructure like frameworks should be
developed incrementally
Release plan can be stored as a set of cards
– each card contains a story
Iteration Planning






Similar to release planning, but on a finer
level
Done on an iteration planning meeting
Stories for the iteration are broken up into
tasks
Additional “internal” tasks are added
Programmers take up tasks and provide
estimates
Each iteration has a “tracker” who volunteers
to take up the task of monitoring progress
Velocity




The number of tasks the programmer can
take up
It is programmers responsibility to track his
velocity
Programmer should take up only the same
number of tasks as he did in the previous
iteration
In Xplanner Programmer enters details of the
exact hours worked on a task regularly
Tracking the iteration



Stand up meetings
If things are not on track, some features can
be removed – but the date should not be
changed
At the end of the iteration, there is a demo
meeting; where each programmer pair, or the
customer demoes the new features