Dr.P.M.MANOHAR, DEPT.

OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM

AGILE SOFTWARE DEVELOPMENT – MODULE-2

19ECS451: Agile Software Development

Module II: Extreme Programming:

Extreme Programming: Introduction, core XP values, the twelve XP practices,
about extreme programming, planning XP projects, test first coding, making
pair programming work.
Learning Outcomes:
After completion of this unit, the student will be able to:
1. Define core XP values(L1)
2. Explain the twelve XP practices(L2)
3. Identify different XP projects(L4)
4. Justify extreme programming(L5)
5. Construct test first coding and pair programming(L6)
Extreme Programming
Introduction
• In this module, we explore Extreme Programming (XP) and its application to programming.
• XP is part of the agile movement, focusing on writing software for implementing systems,
including Java code, Smalltalk, C++, C#, database tables, and XML files.
• XP is often misunderstood for its hacking, lack of planning, and avoiding documentation.
• XP emphasizes planning and simple software production, aiming to help other developers
understand the code. However, understanding the code often requires good commenting,
clarity of implementation, and consistency.
• It is not a hacker's paradise, as many practices restrict or even abolish hacking capabilities.
Good commenting, clarity of implementation, and consistency are essential for a successful
XP development experience.
• XP is a lightweight process, making it easy to create projects that are neither XP nor agile.
• Stories of dense code with complex methods, no comments, and few tests resulted in a lack
of understanding for new developers. This was due to the complex design, lack of guidance,
and difficulty in retesting, integration, and failed to follow best Java coding standards.
• This breaks XP guidance and makes the project unadvanced, indicating that the company
was not following XP and could not be considered agile.

Core XP Values
Core to this are the four values that underlie the whole of XP. These values are presented as:
1. Communication
2. Simplicity
3. Feedback
4. Coverage

1
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

Communication:
• Many problems or defects within software systems can be traced back to poor
communications during the development of the system. This may be poor communication
between programmers, between end users and the development team, between
developers and manager, etc.
• Communication to solve the disputes while building the code to avoid redundant code
and effort going mere waste.
• Communication should help break the barrier and support mutually for the development
of the code, e.g., providing test manuals.
• Projects undertaken in a University Computer Science degree actively encourage group
working or communication of any sort.
• Communication is everything
Simplicity:
• Keep things simple i.e. if a simple solution is adopted, then it is easier for all to understand.
• The simplicity value underlying XP is the simpler the implementation, the easier it is to
implement, test, understand, maintain, and easier to find and correct bugs in the
software.
• The solution is not necessarily simple or trivial; rather that it is the simplest solution to the
problem in hand.
• The simplest code may actually be harder to write in the first place. It is also hard to
ignore tomorrow and not to engineer in features that would be great if you need this
function in a future iteration
Feedback:
• It is good to get feedback. Projects should get feedback early, and often, from the
customer, from the team, from real end users, from other project stakeholders, etc.
• Identify problems early on, deal with unknowns and clarify issues and avoid nasty shocks
later on.

• Feedback can be at many different levels, by running unit tests every time any new code
is integrated into the system, any problem introduced by the new code can be identified
immediately.
• Giving frequent small releases to friendly end users, containing just enough new
functionality so they can provide feedback quickly and frequently about the evolving
system.
Courage:
• Courage to adopt XP, as it needs courage to refactor code.
• Courage to throw away code.

2
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

• Courage to code for now and leave tomorrow to tomorrow

• Courage to move management to adopt XP’s way of working.

Twelve Core Practises

Twelve core practises which effectively define XP are summarized
1. The planning game: Planning the next release.
2. Small releases: A software system is developed iteratively with small releases adding
system features and allowing rapid feedback.
3. Simple design: Keep things as simple as possible but not simpler.
4. Testing: Unit tests and acceptance tests must be continually developed and the code
must pass unit tests for development to continue.
5. Refactoring: This involves improving the system (e.g., to aid simplicity) without changing
the functionality.
6. Pair programming: All code is developed by developers working in pairs (at a single
machine).
7. Collective ownership: Everyone owns all the code so anyone has the right to change
any of the code at any time in order to improve it.
8. Continuous integration: New code is integrated and the system rebuilt every time a
task is completed (which may be many times a day).
9. On-site customer: Have a real customer as part of the team, so that they are always
available to answer questions.
10. Coding standards: Have them and use them.
11. 40-hour week: Work no more than 40 hours a week so that the developers are always
fresh and ready for the challenges facing them.
12. System metaphor: Use the system metaphor to guide the whole development. It is a
metaphor for how the system operates (it is similar to the architecture of the system
but typically simpler).
Twelve core practises explained in detail as
1. The Planning Game
What’s in a Name (Planning game)
• XP has framed this practise in terms of a game to help elucidate what should happen
when planning an XP project

3
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

Planning an XP Project
• XP projects involve a great deal of planning.
• In traditional development project, a large amount of time is spent crafting an elegant,
complex and detailed plan using some tool such as Microsoft Project. What happens
next obviously varies.
• In XP, project planning is a more incremental and inclusive process. It is incremental in
that an overall plan of the project is created to determine (roughly) when each release
will occur and what will be in that release (at the level of overall functionality).
• Then at the start of each iteration, what will be in that iteration or release are
determined in detail and an implementation plan for that release is created at that
point.
• The idea behind the planning game is that XP projects need to be planned just as much
as any other software development project, but they need to be planned in an agile
manner. Thus, they should be allowed to respond to changes in requirements, etc.
• Therefore, on an XP project, you initially start off by making a rough plan quickly. This
plan is then gradually refined, as more information becomes available and as required
features change, etc.
Agile Influences on Planning an XP Project
Working on an XP project, planning in an agile manner involves applying agile principles,
resulting in implications for project execution, including:
• Plan for now
• Responsibility
• Dependencies
• Simplicity
Plan for now
• Implement what is needed for today and leave the rest for tomorrow.
• Plan the needs for the next release/next iteration in detail and no more.

• Perform long-term planning, but not in such great detail.

• At the start of the release, consider the user stories to be implemented, different set are
required due to user feedback, or changing requirements, etc.
Responsibility
• The typical project is planned top down. The top-level management try and plan the
project (hopefully with input from the actual developers).
• The end result is a plan for which the developers feel no responsibility and towards
which they feel no trust.
• Agile planning involves the developers the whole way. They should feel that the plan is
as much theirs as it is the managers.
• The person expected to implement a particular feature is the one who must estimate it.

4
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

Dependencies
• When planning an XP project, ignore the dependencies between parts .

• Do not worry about whether task x is required before task y.

• Focus on the highest business priorities first and allow other issues to come out in the
wash.
Simplicity (in planning)
• Plan in time in order to keep things as simple as possible.

• For example, if you are planning to help determine the priorities and ordering of user
stories, then much less detail is required.
• Planning the implementation of a set of tasks for a particular iteration, far greater
details are required.
The Planning Game in Detail
• The planning game relies on user (customer) stories to drive the iterations of the project.
These user stories are used to determine which features will go into which iterations. From
this, appropriate releases can be identified.
• The primary output of the Business Game is the plan, it:
o Allows customers to make business decisions,
o Allows developers to make technical decisions.
o To combine the results into the iteration-oriented plan.
• Within this framework the customer determines:
o Scope – what is in and out of the system.
o Priority – what is more important, less important, must haves and nice to haves, etc.
o Composition of releases – what will be in each release.
o Release dates
• In turn, the development team decides
o Estimates of how long various features will take.
o Consequences of for example, using a particular technology, for example,
o Linux versus Microsoft Windows XP, Java versus C#, J2EE (Java 2 Enterprise Edition)
versus .Net.
o Team and Project Organisation (e.g. the organisation of the tasks)
o Risks associated with different features (e.g.will MySQL provide the required level
of performance or should an Oracle database be used).
o Detailed scheduling – which features are to be done when and in what order.

5
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

o This involves balancing the technical risks (which will benefit from being addressed
early on) with the business priorities that may be more important to the end user.
• Essentially, the planning game is comprised of two players (the Business and the
Development).
• The business is made up of all those who can make a decision about what the system
should do. The development is made up of all those who will be involved in implementing
the system.
• The game has three phases through which play proceeds. These phases are the
exploration phase, the commitment phase and the steering phase.
• The steps performed during each phase are:
Elaboration phase

• This phases help to identify what the system needs to do. It is compressed of the
following steps:
o Write a story – the business writes a user story describing some behaviour
required
of the system.
o Estimate a story–development estimates how long the story will take to
implement.
If they cannot estimate the story or the story seems too big then they can ask
for clarification or break the story up into smaller chunks.
o Break a story up – the business must break a story down into small chunks if
required.
Commitment Phase
• This phase allows business to determine the scope of the release and when that
release will occur (based on information provided by development and business).
The steps within the commitment phase are:
o Sort by value – business must sort the stories (written on index cards) into
three plies (1) must have, (2) should have and (3) nice to have. This is
effectively applying a relative priority to each story.
o Sort by risk – Development now sorts the stories into three further piles (1)
stories that can be estimated precisely, (2) stories that can be estimated
roughly and (3) stories that can’t be estimated.
o Set velocity – development indicates how quickly they will be able to achieve
the estimates (which have been made in an idealised type of time).
o Choose scope – Business selects which user stories will be in the next release.
Steering Phase
• Allows the plan to be updated as things change over time. This phase happens later on
within an iteration or between iterations as required. The players return to the game to
consider what has been happening during the lifetime of the project (or at least the
lifetime of the current iteration, etc.).
• The steps in the steering phase are:
o Iteration – from each iteration the business picks the stories that will form that
iteration.

6
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

o Recovery – if it is realised that not all the stories can be implemented for a particular
iteration, then Development must ask Business to help determine which stories should
remain in the iteration and which might be moved to later iterations.
o New Story – if Business realises that an important story has been omitted, then it can
introduce that story to Development to be estimated and the iteration re-planned
which may lead to removing of one or more existing stories will be removed from
the current iteration.
o Re-estimate – if it is clear that the current plan was over or under optimistic, then
Development can re-estimate the remaining user stories and adjust the project
velocity and consider the resulting implications.
Types of Planning Games
There are two types of planning games:
1. The initial planning game:
The initial planning game paints with a broad brush and plans the general set of iterations
and roughly plans out the user stories for each iteration.
2. The release/iteration planning game:
The release or iteration planning game, plans out in more detail a single iteration and
explores the high level user stories by breaking them down into lower level stories

2. Small Releases
• The system developed should be released often to the end users so that they can provide
frequent and rapid feedback to the development team. Thus, the smallest possible
releases that can add business value should be identified and scheduled.
• If the set of tasks adds value to the customer, it should be released to that customer.
This not only allows customers to providing feedback frequently, but also makes short-
term planning easier.
• In each instance of the planning game needs to consider only the next few weeks and
thus the level of unknowns and the amount that the team can have diverged from the
plan is limited.

3. Simple Design
• XP does do design! However, it is design with a particular emphasis – the code that is
produced. In pure XP, this design process also happens just as the code is to be
implemented.
• XP does not mandate how the code is designed, it could be done either by the pair
programmers discussing how they would approach the coding or in an Agile Modelling
manner or by using flow charts, etc. XP present the following as being features of a
simple effective design. A simple design is one that:

7
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

• Passes all the tests available for it.

• Has no duplicated logic.
• Ensures that any assumptions, or intentions, made by the developers are explicit to
anyone reading the code (for example by using Javadoc or other comments in the code).
• Has the fewest possible classes and methods.

4. Testing
Test are produced before any code is written, acceptance tests are generated as soon as
requirements (in the form of user stories) are written, unit tests are produced before the code is
implemented, all code must pass all tests from development to progress. Test first coding gives:
• A complete set of tests for all code produced (as you created the tests first).
• Simplest code that passes all tests.
• A clear view of what code should and should not do.
• A simple way of checking that refactored code has not altered functionality.
• A great deal of “documentation” explaining what a particular module should or should
not do.

5. Refactoring
Refactoring is that art of refining a system’s implementation without changing its functionality.
Refactoring should occur at:
• Before implementing a new feature. The refactoring performed at this point makes it
easy to add the new feature.
• After implementing a new feature. Refactoring at this point helps to make the resulting
solution simpler.
• The result should be that you aim to produce the simplest solution containing clean
effective code, with fewer potential problem areas/black holes.
• The Test practise helps prove that any refactoring has not broken anything in the system.

6. Pair Programming
The two developers play different roles:
• One focuses on the method, class or interface, etc. being implemented.

8
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

• The second focuses on the more strategic issues such as how well does this solution fit with
the rest of the system, what are its implications, is there a simpler solution, do the tests
cover all possibilities.
The benefits of this include:

• Two brains are better than one.

• Knowledge of the system is spread amongst the team.
• Test coverage may be better as two people will bring two different perspectives
with them.
• Experience is spread amongst the team. If the team is comprised of a mixture of new
graduates and developers with ten years experience within the application domain,
then by pair programmer, the experienced developers quickly share their
understanding of the domain, the technologies and the programming language with
the new graduates.

• All code is dynamically reviewed by at least one other person who also understands
the scenario within which it was developed.

7. Collective Ownership
• Everyone owns all the system code! That is, all code is the shared responsibility of all the
developers on the project. Everybody thus has the right, and indeed the duty, to make
changes to any part of the system whenever they identify an opportunity to improve it.
• This is something quite different from saying that the code is owned by the project (and
thus no individual owns the code) as in this case, typically nobody has responsibility for
the code or has a “duty” to improve it.
• It is also very different from saying that developers must take ownership of their own
code. In this case, each developer “owns” part of the system but not anything outside
their own remit.

8. Continuous Integration
• Every time a task is completed, the resulting code should be integrated into the current
build. To do this, the new code must of course, pass all unit tests (including the new ones
introduced with the new feature).
• Any problem encountered should be immediately resolved.
• In general, any problem will relate to changes made to support the new feature and
will thus be easily identifiable.
• Once all tests are passed, the new code can be released to version control and a
complete new build

9
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

9. On-Site Customer
• How many times have you looked at a requirements document, relating to the task you
are about to work on and thought “what does this mean?” or “yes, but what should
happen if they cancel at this point?” etc. These are questions that an expert customer
(for example, an end user or someone doing the job at the moment) can answer.

• In XP, such a customer should be part of the team so that such queries can be answered
quickly and effectively allowing for rapid responses and rapid feedback.
• On-site customers can also help to resolve disputes (over business issues relating to the
system), help set small-scale priorities (is this feature or that feature more important) and
review the evolving system.

10. Coding Standards

The benefits of following the coding standards
• It avoids wasted arguments over small things such as where brackets should go (on the
same line or the next line) within a Java statement.
• It means that everyone gets familiar with the style of coding to be adopted which makes
code easier to read.
• Simple guidelines such as “All constants in capitals” mean that as soon as such a
convention is seen its meaning is known immediately.
• Helps to create an environment where code becomes de-personalised.
• Helps make activities such as refactoring and pair programming easier.

11. 40-Hour Week

• To put it another way, developers can only focus on developing code successfully for a
certain number of hours a week, beyond this your at best wasting their and your time
and at worst helping to introduce problems into the system.
• The 40-hour rule isn’t exactly a 40-hour rule more a guideline as 35 or 45 hours might
be appropriate, but 60 to 80 hours every week.

12. System Metaphor

• In XP terms, the system metaphor is a story or view that expresses the overall way in
which the system will operate. It is typically less detailed than the architectural design
that you may have encountered.
• Overall, the metaphor should help people understand how the system fits together rather
than provide a detailed (or very accurate) description.

10
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

About extreme programming

• Extreme Programming (XP) is a set of twelve practices that are often incorporated into
existing software engineering methodologies. So, what is so different, so extreme, about
Extreme Programming is?
1. Extreme Programming is very lightweight – it really only focuses on the programming of a
software system.

2. Extreme Programming takes the best practises to their ultimate conclusions.

The concept of second point in details as follows:
1. If code reviews are good, then review code all the time (pair programming).

2. If testing is good, everybody will test all the time (unit testing), even customers (acceptance
testing).

3. If designing is good, then make it part of what everyone does every day (refactoring).

4. If simplicity is good, then always strive for the simplest effective solution (i.e.,
the simplest solution that works).

5. If architecture is important, then ensure that everyone is involved in creating

and refining the architecture all the time (system metaphor).

6. If integration testing is good, then integration and testing should be an ongoing (daily or
even hourly) thing (continuous integration).

7. If short iterations are good, then make them as short as possible, i.e., hours, or days not
weeks and months (the Planning Game).
Review:

• The interconnected nature of all practices in XP, including allowing team members to change
system aspects at any time, can lead to chaos and anarchy if not supported by practices
like Testing, Continuous Integration, and Pair Programming. This is illustrated in the below
Figure.

Fig. Practises supporting the ability to fix a problem when it is found.

For example, if a problem is noted in one area of the system by John, then:
1. Collective Ownership means that it is John’s responsibility to fix it.

11
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

2. Pair Programming allows John to work with Steve who is an expert in the problem area.
3. Simple Design means that the solution was already the simplest possible and
thus should be clear and easy to understand (relatively).
4. Refactoring allows the change to be made and verified. That is, the revised code can be
guaranteed to have been kept as simple as possible and to have not altered the (as it should
have passed all the tests).
5. Testing guarantees that the system still functions as before and that we have not broken anything
else during the refactoring.
6. Continuous integration ensures that the new code is only integrated once it has passed all the
tests, but that it is then immediately part of the evolving solution.
Planning XP projects
• It is a common misconception that XP projects do not need to be planned. This may partly
be because the planning aspect of XP is known as “The Planning Game” if this is a problem
then consider this as the Project Planning Workshop.
• Secondly, however, they may remain un-convinced because the nature of project planning
changes. Rather than planning out the whole project in great and fine-grained detail, the
overall project plan is left rather vague and high level and detailed plans are only created
on an iteration-by-iteration or release-by-release basis.
• The approach involves more planning, accurate project tracking, and frequent review
compared to the traditional method
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.
The XP project lifecycle is presented in Figure below. This diagram illustrates the
various planning stages and implementation stages within a typical XP project.

Fig. XP project lifecycle

12
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

• For example, it starts with an initial project planning process during which the overall plan
of the project is roughly sketched out.
• This is followed by one or more 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.
Planning process
1. 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.
• A key issue, and one which takes time to achieve, is that both sides must trust
each other. 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
2. The Goal of the Game
The goal of the planning game is to maximise the value of the software produced by the team.
3. 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.
4. 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.
• Only once they are accepted, as genuine user stories are typically entered into
a computer. This is partly as they are harder to view, manipulate, sort, etc. and
partly because once something has been entered into an electronic media they are
often harder to throw away
5. 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. In turn, Development consists of those people
who will be involved in implementing the system. This includes, but is not limited to,
programmers. It may also include database administrators, system support technologists,
networking professionals, etc.

13
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

• The members of the two teams should be distinct. That is, no one person should be a member
of both the Business and the Development.
6. 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. For example, in the steering
phase it may be noticed that some new user stories are required. This may lead
to the exploration phase being re-run for the new user stories, followed by the
commitment phase, before a revised plan is produced by the steering phase.
Each of the three phases will be discussed in more detail below.
Exploration Phase
Within the exploration phase, the game tries to help the team identify what the
system should do. To achieve this, this phase has three steps (or moves). These are:
1. Write a story.
2. Estimate a story.
3. Split a story
• Write a story.
The business discusses system requirements, which can be documented as user stories on
index cards or white boards before being committed to electronic media.
• Estimate a story.
Development then estimates how long it will take to implement a story. If Development
cannot estimate the story, then it can ask for clarification or request that the story be split
up

• Split a story.
Users are often not good at realising how much work may be involved in a particular system
feature. In turn, developers are often not very good at immediately realising what a user
wants. As a result, user stories may vary in size and complexity. Typically, user stories require
refinement, but large user stories (in terms of complexity or duration) need to be broken
down into shorter less complex stories. As a rule of thumb, no single story should be large
enough that one programming pair would be unable to complete it within one iteration.
Commitment Phase

• During this phase of the game, Business must identify what will be in the current iteration and
when the next release will be. For their part, Development must commit to the agreed
duration and the content of the release. If this situation cannot be met then either the
timescale of the release must be changed, the content of the release altered or the number
of developers increased.

14
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

• The steps presented to reach agreement within the game are:

1. Sort by value.
2. Sort by risk.
3. Choose scope.
4. Set project velocity
The steps presented to reach agreement within the game are:
1. Sort by value.
2. Sort by risk.
3. Choose scope.
4. Set project velocity.

These steps are described in a little more detail below:

Sort by value.
The user stories are sorted by Business into three piles. These piles represent those stories in
the:
1. must have category,
2. should have category, and
3. nice to have category.

• This effectively gives each story a relative priority with regard to the three categories. The
implication is that, from the Business perspective, the user stories in the “must have”
category are more important than those in the “should have” category. In turn, the “should
have” category are more important than the “nice to have” category.
• Thus, an XP project development should focus first on the “must haves” as these will add
the greatest value to the Business.
Sort by risk.
The user stories are further sorted by Development into piles for:
1. confident estimates,
2. reasonably sure estimates, and
3. cannot estimate.
• This is useful because we can then see those user stories that the Business believes are “must
haves” and how sure Development is of the estimates given. The result of this is that the
planning game may return to the exploration phase to try to clarify any issues relating to
the estimation of user stories. Some stories may need to be left for further investigation after
the planning game has concluded.
Choose scope.
• Business must select the final set of user stories that will form the next iteration or release.
The only constraint on what comprises a release is that the first release should be complete
in terms of end-to-end processing (although very limited in functionality) and that each
subsequent release should add something in terms of value to the Business (for it to be
considered a release). Note not all iterations may result in a release.

15
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

Set 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.
• As can be seen from the above steps, this phase may proceed sequentially, with Business
ordering the relative importance of various user stories. Next Development will determine
how well they can estimate those stories. Finally, Business will decide on which of the stories
will comprise a particular release (or releases).
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)

• All this means that over the lifetime of a project, a plan may require frequent and
extensive revision. Indeed, a living project plan should be able to show a history
of changes, otherwise it is likely to be out of date and may be of little use.
• The idea in this phase is that you are helping to steer the project forward. In doing so, you
are encouraged to explicitly address the above issues.
The steps in the steering phase are:
1. Iteration planning.
2. Project recovery.
3. Identifying a new story.
4. Project re-estimation.
These four steps are considered in more detail below:
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 stories.
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.
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.

16
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

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.
Planning Your XP Project
The various types of planning game fit together to help you plan your XP project. There are
actually two forms of the planning game:
1. The initial planning game, and
2. The release planning game.
“Elaboration” phase, allows clarification of user stories to take place outside the constraints of
the game. Thus, 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.
The Initial Planning Game
• The initial planning game focuses on what the system as a whole should do. It considers all
user stories that are in scope (and indeed what that scope is).
• It happens at the start of the project and may reconvene at various points throughout
the lifetime of the project to review the scope of the system, the set of user stories,
their relative priorities, etc.
The Release Planning Game
• The release planning game focuses on the contents of a release or iteration. It has
the same steps as the initial planning game but the level of detail that needs to be
considered is much greater. During the initial planning game, the overall plan for
the project should have been roughly planned out. 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.

17
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

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.
The Elaboration Process

• The elaboration process follows the initial planning game, and typically on a smaller scale,
a release planning game. 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:
o Lower the risk of bad estimates,
o Experiment/prototype different solutions,
o Improve the development teams to understand the domain/technology,
o Ensure procedures and processes required are in place.
Iteration Planning
There are two issues to consider when planning an iteration. These are
(1) determining the size of an iteration;
(2) determining what should be done within an iteration to implement the user stories.
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.
4. Task commitment during which tasks are estimated, load factors determined
and balancing takes place.
5. Finally, the iteration plan is verified.

Test First Coding

• When you write code you should also write the unit tests that go with it to verify that code.
• you should write the tests before you write the code.
• Test first coding also ensures, of course, that all code produced does have a relevant set
of unit tests available for it.
How to Write Tests First?
• how do you decide what to program first
1. Initially, focus on the code's purpose and ignore its implementation. This can be
challenging for programmers, as they often focus on the "how." However, persevering
and understanding the "what" can lead to a more effective approach. Writing down the
test's actions, such as Javadoc, can help eliminate the need for existing code and
methods.

18
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

2. Write a test using unimplemented classes and methods by determining class names,
method signatures, and parameter values. This test case will not compile but will be ready
at a later date, and using tools like Eclipse simplifies this process.
3. If you haven’t already done so, then write the stub code for the class(es) being
tested. As mentioned above, tools such as Eclipse may do this for you, however,
if you are using tools such as Emacs you will have to do it yourself.
4. Now put the code you have created for the test into whatever project code
repository you are using. This includes your test code. If you are using a
framework such as JUnit then add your test to that as well.
5. Run your test against the stub code, ensuring it fails if you haven't implemented the
methods yet. This step validates the test's success and ensures it fails. If the test passes, it's
likely missing something, like checking if the value set for the text was the get method's
return.
6. Write the implementation of the tested methods, potentially creating additional methods.
Focus on writing enough code to pass the test, ignoring future features. Produce the simplest
code that meets all requirements, as passing all tests ensures it meets requirements.
7. Re-run your tests against the newly implemented methods. If all the tests pass, then
continue. If not returned to step 6 and revise your code as necessary.
8. Now re-run the tests for the entire system. If all tests pass, then add the changes in your
current test suite and implementation to your code repository. Now you can continue. If one
or more of the tests fail then you must return to step 6 and revise your code as necessary
(as it must have been your changes that caused any tests to fail).
9. Refactor your code for clarity and to remove any duplication. Return to step 7 if you are
sure that no refactoring is required, then you have finished the current test. Return to step 1
for the next test.
What to Test?
• Testing is essential, but it's not necessary to test every method or major subsystem in an
application.
• As with many things in software, there are no hard and fast rules for what you should test,
but here are some XP-oriented guidelines:
1. Write tests for any tasks being implemented.
2. Write tests for any classes or combinations of classes that are non-trivial and could easily be
broken. For example, if one particular class implements a complex algorithm to find sneak
circuits within electronic relays, then write tests for that class even though it may only be one
element of a larger module.
3. Avoid writing tests for methods that just call another method, e.g. delegate methods, if the
called method already has a test written for it.
4. Assume that more tests are better then less and that no one will complain about having too
many tests, but that people will complain if an important test is missing.

19
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

5. Write tests that instil confidence in the system. For example, if one area of the system is
invoked by many others (such as a data access management subsystem), then having a set of
tests for that area adds to the confidence of those using it.
6. Add tests that will help cover areas of the system being modified. If you are refactoring some
code, and feel that one or more tests are missing then add them.
7. If you happen to notice that a suite of tests for a particular module, subsystem or class appears
to be missing in one or more tests, then add them.
Confidence in the Test Suite
• The developers must have confidence in the test suite created. Not only is this important for
their belief in the system but it is also particularly important for two other importance
practises, namely:
1. your ability to refactor and prove that you have not changed the functionality of the
system;
2. the guarantee that if you code in a test first manner, that you have produced the
simplest code that covers the requirements.

Making Pair Programming Work

• Pair programming is a method where two developers work together, with code reviewed
by at least one person. However, it can be challenging to get two developers to pair
program, especially when most programmers prefer working alone. Change to pair
programming is difficult and requires training, as most people need to learn or be trained
to do so.
• Pair Programming involves inter-personal skills, pair dynamics, communication, tolerance
and trust.
• There are no hard and fast rules to how to do this, there are things that can help:
1. Engage in a dialogue. The “driver” should try and explain what they are doing. The
“navigator” should ask questions in order to understand what is being done. This is not as simple
as it sounds.
2. Listen to each other. If one member of the pair is doing all the talking then it is probably isn’t
working. The one who isn’t saying much might not be clear on what is being done. Try swapping
roles, or have a break, or take time out to review where you are.
3. Take frequent breaks. Pair programming is intensive. It is intensive in terms of the little grey
cells and also in terms of inter-personal communications and dynamics. Have regular breaks,
talk about other things, see how others are getting on, catch up on the news, etc. Don’t take a
break and discuss the code!
4. Don’t be a back seat driver. Back seat driver syndrome is a common issue where the navigator,
who is more experienced, constantly instructs the driver, causing frustration. This is not pair
programming, but acting as the virtual driver. Instead, swap roles and discuss proposed solutions
with the driver, allowing them to learn more.

20
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

5. Make pair programming practical. Providing comfortable workspace for two developers can
be achieved through desks large enough for two to sit next to each other or special double-
sized workstation environments.
6. Use a common environment. Developers often have their preferred development environment,
such as JCreator, JBuilder, NetBeans, Eclipse, or Emacs. Choosing a single environment simplifies
pair programming, but it can be difficult for developers to change due to their investment in
learning tools. Careful handling of this can prevent friction.
7. Shared language and vocabulary. Developers with a shared vocabulary of design and
programming concepts tend to work better together, as it avoids questions like "what do you
mean by Factory Method?" This helps build trust and confidence in each other. Understanding
domain and application-specific terms and technical vocabulary is also crucial. Books like the
Gang of Four1 Patterns book, Buffalon et al.'s Pattern Approach, Fowler's Pattern Analysis,
Larman's Larman, and Metsker's Patterns Movement can help guide developers in this area.
Additionally, a dedicated web page dedicated to the patterns movement offers tutorials and
example patterns.
8. Allowing non-pair time. There are some situations where allowing a pair to work alone can
be beneficial. This may be a little controversial for some in the XP community, as they will argue
that it is always between to work in pairs. However, in the following situations, flying solo may
be an alternative (but it should be the rare exception to pair programming):
a. Exploring completing alternative solutions,
b. Following multiple competing lines of investigation during debugging (but not bug fixing).
9. Change partners often. Pairs should not be permanent. Instead, pairs should change as and
when required. The typical point at which to change is at the start of a new task. However, if a
task ranges over a number of areas, then a “driver” developer may pair with several
“navigators” in order to benefit from their different areas of expertise.
The typical pair programming workflow is illustrated in Figure below. It illustrates a number of
important features of pair programming.

• Firstly, pairs are not permanent (and indeed should be changed regularly). A pair forms to
carry out a particular task. At the start of the task, they have a brief meeting to discuss what
it is they are about to do and how they might approach it, what the options are, etc. This
helps to ensure that no one is along just for the ride.
• They then work on the code in a test first manner, proposing a test, implementing the business
classes that will meet the requirements of that test and then running the test.
• If the test is passed, then they move onto the next test. If the test fails, then they review the
code and determine what is wrong.
• Once the tests are completed, they integrate the code with the current build. If this causes
any tests for the whole system to fail, they must revise the code and determine why the test
failed, etc. They can only finish integrating once all the tests have passed. The task is then
completed and the pair breaks up.

21
Dr.P.M.MANOHAR, DEPT. OF CSE, GITAM SCHOOL OF TECHNOLOGY, VISAKHAPATNAM
AGILE SOFTWARE DEVELOPMENT – MODULE-2

Fig. Pair-programming workflow

22