The document discusses planning in XP (Extreme Programming) projects. It describes the aim of planning workshops which is to decide project scope and priorities. Release planning determines features and schedules them into releases. Planning involves sketching the overall project plan followed by release planning to plan specific releases and iteration tasks. Releases are then implemented and fed back into planning. The "planning game" involves two teams - business and development - who work together to estimate features and schedule a release.

1. Planning XP Projects

2. Planning XP Projects
What is the aim of the game/planning
workshop?
• It is to decide on the scope and priorities of
the project and of the releases.
• It is also to estimate the cost of various
features required by the software and to
schedule those features into releases.

3. XP Project Life Cycle

4. • The overall plan of the project is roughly
sketched out.
• This is followed by one (and typically more than
one) release planning process where the
contents of a release is planned and the tasks
performed in the iteration to implement the
release are also planned.
• The release is then implemented and the results
of this process fed back into the planning for the
next iteration.

5. Playing the planning game
• The planning game has only two conceptual players; these are the
“Business” and “Development.”
• The business is formed from those stakeholders who can specify
the operation of the system.
• Development is formed from members of the development team
relevant to the features being discussed.
• The number and size of each “team” may change over time.
• The Business must trust the Developers to give honest and accurate
estimates.
• The Developers must trust that the Business will give them the
information they need and will work with them to create the plan.
• The game also has rules that aim to help the two teams work
together to produce the plan. These rules can help to gain the
mutual trust and respect essential to successful planning.

6. The Goal of the Game
• The goal of the planning game is to maximise
the value of the software produced by the
team.

7. The Strategy
The main strategy of the game is
• to invest as little as possible
• to put the most valuable functionality into
production as quickly as possible, but without
compromising the required product quality.

8. The Game Pieces
• The pieces used by the two players are the
“user stories”
• These are written down on index cards and
moved around during the game.

9. The Players
• There are only two players in the game
“Business” and “Development.
• Business is made up of a collection of those
individuals (project stakeholders) who can make
decisions about what the system should do.
• Development consists of those people who will
be involved in implementing the system.
This includes, but is not limited to, programmers,
database administrators, system support
technologists, networking professionals, etc.

10. The Moves/Playing the Game
• There are three stages to play the game.
1. Exploration – Determine new user stories of
the system.
2. Commitment –Decide which features will be
addressed in a particular release.
3. Steering – Update the plan as development
progresses.
These three phases are iterative and may
interact.

11. The Moves/Playing the Game
(Contd..)
Exploration Phase
1. Write a story.
2. Estimate a story.
3. Split a story.
Commitment Phase
1. Sort by value – must have, should have, nice to have categories
2. Sort by risk – Confident estimates, reasonably sure estimates, and can not
estimate
3. Choose scope -Business must select the final set of user stories that will
form the next iteration or release
4. Set project velocity - This step maps the Ideal Engineering Unit (IDU) into
reality and takes into account the amount of time developers will actually
be productive, their experience, etc. It thus provides a way of mapping
ideal estimate periods into elapsed actual time

12. Steering Phase –
In the real world, plans often change. This may be for a wide variety of
reasons including (but by no means limited to):
• changing requirements,
• new requirements,
• changing priorities,
• incorrect estimates,
• changing resources (developers leave and new developers join a project
with different skill sets).
The steps in the steering phase are:
1. Iteration planning.
2. Project recovery.
3. Identifying a new story.
4. Project re-estimation.

13. 1.Iteration planning: XP states that you should only plan the current iteration in detail.
• Therefore, at the start of each iteration (e.g., every 1–3 weeks) Business plans the
user stories to be implemented and Development plans the tasks needed to
implement those
2. Project recovery: As the iteration progresses, if Development realises that it is
ahead or behind schedule, it can ask Business to help it to re-prioritise the user
stories to implement.
3. Identifying a new story: If a new story is identified and determined to be necessary
for the current release then it can be written, estimated and added to the iteration.
• As a consequence, the remaining user stories will need to be reviewed and some
discarded in order to achieve the release.
4. Project re-estimation: If Development feels that the plan has been shown to bear
little reality to the real world, then the whole iteration can be re-planned, user
stories re-estimated, the project velocity reset and the implications for the project
timetable considered.

14. Planning Your XP Project
A typical XP project might be planned in the following manner:
1. An initial planning game (aims to get overall view of project);
2. Initial elaboration process (focusing on high level user stories);
3. Release 1 planning game;
4. Release 1 elaboration process (if required);
5. Plan iteration 1;
6. . . . . Release 1 iteration/implementation . . . ;
7. Release 2 planning game;
8. Release 2 elaboration process (if required);
9. Plan iteration 2;
10. . . . Release 2 iteration/implementation . . . ;
11. . . .
12. Release n Planning game;
13. Release n Elaboration process (if required);
14. Plan iteration n;
15. . . . Release n iteration/implementation.

15. The Initial Planning Game :
The initial planning game focuses on what the system as a whole should do
• The overall plan for the project should have been roughly planned out.
The Release Planning Game:
• At the start of a release, the details of what will be done in that release
need to be determined. This means that:
1. User stories need to be fleshed out and may need to be broken down into
finer grained stories (in order that they can be implemented).
2. Detailed estimates of the stories need to be obtained.
3. The user stories to be implemented as part of the release need to be
confirmed, revised or modified as required.
4. The project velocity may need to be revised. For example, as the
development team become more experienced in XP and the application in
which you may find development speeds up.

16. The Elaboration Process :
During this phase, research is carried out to clarify user
stories in order to estimate, clarify requirements, or
technical issues.
The aim of this is to:
• Lower the risk of bad estimates,
• Experiment/prototype different solutions,
• Improve the development teams to understand the
domain/technology,
• Ensure procedures and processes required are in
place.

17. Iteration Planning :
Size of an iteration: An iteration needs to be big enough
to allow either a new release to be created that adds
value to the business or large enough that you are able
to make significant progress
• However, it should also be small enough that the
development does not move on too far without being
reviewed
• An XP iteration ranges from 1 to 3 weeks
• XP projects are quiet small involving between 2 and 6
and generally at most 10 developers

18. Planning the iteration: If the release planning game identifies what new
features should be added to the evolving system in the current iteration,
then the iteration plan defines how those features will be achieved
Iteration planning usually incorporates the following phases:
1. Evaluation of the last iterations lessons learned, changes to be made, etc.
2. Review of user stories to incorporate into the iteration.
3. Task exploration during which tasks are written for user stories. These tasks
may be broken down into smaller tasks to help with planning and
estimating.
4. Task commitment during which tasks are estimated, load factors
determined and balancing takes place.
5. Finally, the iteration plan is verified