Like any other process, Xp addresses specific risks through its practices.

'''What are the RiskManagement strategies within each practice?'''

* ''ProgrammerTest'' 
** RiskMitigation: against the risk that changes might cause errors in already existing code. By writing code which will show where many of those errors are, the programmers can quickly find the problems and fix them as a contingency.
* ''CustomerTest'' 
** RiskAvoidance: against the risk that the specifications might be vague. By transferring the responsibility for writing the tests to the customer, the team ensures that they aren't required to deliver untestable features.
* ''PlanningGame'' 
** RiskMitigation: against the risk that the project is incomplete at the due date. By requiring that the customer put features in business value order, the team can deliver an incomplete yet still valuable version of the software as a contingency.
* ''WholeTeam''
** RiskAvoidance: against the risk that the programmers will waste time due to misunderstanding the customer requirements. By requiring that the customer be part of the development team, they are always available to clear up misunderstanding.
* ''PairProgramming'' 
** RiskReserve: against the risks that individual programmers will affect the productivity of the team. By requiring that all production code is written by a pair, the cost of reviewing that code is automatically included in the schedule.
* ''ContinuousIntegration''
** RiskReserve: against the risk that time lost integrating changes will impact the schedule. By requiring that small integrations happen frequently, the team spreads time lost to integration over the project duration. This means the schedule automatically includes integration time.
* ''DesignImprovement''
** RiskMitigation: against the risk that layers of changes will degrade the design to the point that further changes cannot be considered. By requiring that the design is continuously adjusted for clarity and simplicity, the team reduces the work it needs to do to add new features.
* ''SmallReleases''
** RiskMitigation: against the risk that what is asked for is different from what is wanted. Providing early and frequent releases allows problems to be discovered earlier, and while there is still time to correct them.
* ''CollectiveCodeOwnership''
** RiskAvoidance: against the risk that staff turnover will overly impact the team's productivity. By requiring that no team member will take sole responsibility for a given piece of code, the team ensures that any team member can be replaced.
* ''SimpleDesign, SystemMetaphor, and CodingStandard''
** RiskReserve: against the risk that the mixture of ideas and styles will impact the team's productivity. By requiring that all code should be simple, clear, and following a shared vision as well working, the ReWriting time is included in the ProjectVelocity, and therefore the schedule.
* ''SustainablePace''
** RiskAvoidance: against the risk that productivity will fluctuate, making the schedule unpredictable. By requiring that team members work regular hours, the team ensures that the project velocity remains relatively stable.

----

See RiskManagement, AnatomyOfRisk, WhatIsTheWaterStrategyOfaFish