La práctica del equipo completo es la idea de que todos los colaboradores de un proyecto XP se ubican juntos en el mismo lugar, como miembros de un único equipo. XP hace hincapié en la noción de generalizar a los especialistas, en contraposición a los especialistas en roles. En otras palabras, cualquiera que esté cualificado para desempeñar una función puede asumirla; las funciones no están reservadas a personas especializadas en un área concreta. Esta práctica ayuda a optimizar el uso de los recursos, ya que las personas que pueden desempeñar varias funciones pueden cambiar de una a otra según surja la demanda. Esta práctica también permite un intercambio de información más eficaz y ayuda a eliminar la posibilidad de que las personas que desempeñan determinadas funciones estén ociosas o sobrecargadas en determinados momentos del proyecto.

XP tiene dos actividades principales de planificación, o juegos de planificación: la planificación de lanzamientos y la planificación de iteraciones. Un lanzamiento es la introducción de nuevas funciones hasta llegar al usuario de producción.
Un proyecto suele tener uno o varios lanzamientos, pero no más de uno o dos al año.
Durante la planificación del lanzamiento, el cliente define las funciones necesarias y los desarrolladores calculan la dificultad de crearlas.
Con estas estimaciones y prioridades, el cliente establece el plan de entrega del proyecto.
Como es probable que los primeros intentos de estimación sean imprecisos, este proceso se revisa con frecuencia y se mejora a medida que evolucionan las prioridades y las estimaciones.
Las iteraciones son los ciclos cortos de desarrollo dentro de una versión que Scrum llama "sprints", la planificación de la iteración se realiza al comienzo de cada iteración.
El cliente explica qué funcionalidad le gustaría ver en la próxima iteración, y luego los desarrolladores desagregan esta funcionalidad en tareas y estiman el trabajo.
Basándose en estas estimaciones (que son más precisas que las de la planificación del lanzamiento) y en la cantidad de trabajo realizado en la iteración anterior, el equipo se compromete con los elementos de trabajo que cree que puede completar en la presente iteración (aproximadamente por un periodo de dos semanas).

En XP se fomentan los lanzamientos pequeños y frecuentes a un entorno de pruebas, tanto a nivel de iteración, para demostrar el progreso y aumentar la visibilidad para el cliente, como a nivel de lanzamiento, para desplegar rápidamente software funcional a los usuarios inales. La calidad se mantiene en estos cortos plazos de entrega mediante pruebas rigurosas y prácticas como la integración continua, en la que se ejecutan conjuntos de pruebas con tanta frecuencia como sea posible.

Como parte de la definición de las funciones necesarias, el cliente describe uno o varios criterios de prueba que indicarán que el software funciona según lo previsto. A continuación, el equipo crea pruebas automatizadas para demostrarse a sí mismos y al cliente que el software cumple esos criterios.

En XP, cualquier par de desarrolladores puede mejorar o modificar cualquier código. Esto significa que varias personas trabajarán en todo el código, lo que se traduce en una mayor visibilidad y un conocimiento más amplio de la base de código. Esta práctica conduce a un mayor nivel de calidad: con más gente mirando el código, hay más posibilidades de que se descubran defectos. También se reduce el impacto en el proyecto si uno de los programadores abandona, ya que se comparten los conocimientos.

Aunque la propiedad colectiva del código tiene sus ventajas, permitir que cualquiera modifique cualquier código puede dar lugar a problemas si los miembros del equipo adoptan distintos enfoques a la hora de codificar. Para hacer frente a este riesgo, los equipos XP siguen un estándar de codificación coherente, de modo que todo el código parezca escrito por un único programador experto. Los estándares específicos que cada equipo utilice no son importantes, lo importante es que el equipo adopte un enfoque coherente a la hora de escribir el código.

XP utiliza metáforas y símiles para explicar los diseños y crear una visión técnica compartida. Estas descripciones establecen comparaciones que todos los interesados pueden entender para ayudar a explicar cómo debe funcionar el sistema. Por ejemplo: "El módulo de facturación es como un contable que se asegura de que las transacciones se introducen en las cuentas adecuadas y se crean los saldos". Incluso si el equipo no puede dar con una metáfora eficaz para describir algo, puede utilizar un conjunto común de nombres para los distintos elementos para asegurarse de que todo el mundo entiende los conceptos básicos del producto.

La integración consiste en reunir el código y asegurarse de que todo se compila y funciona a la vez. Esta práctica es fundamental, porque saca los problemas a la superficie antes de que se construya más código sobre diseños defectuosos o incompatibles. XP emplea la integración continua, lo que significa que cada vez que un programador introduce código en el repositorio (normalmente varias veces al día), se ejecutan automáticamente pruebas de integración. Dichas pruebas ponen de manifiesto las compilaciones defectuosas o los problemas de integración, de modo que puedan resolverse de inmediato.

Las pruebas son una parte fundamental de la metodología XP. Para garantizar una buena cobertura de las pruebas, de modo que los problemas puedan detectarse en una fase temprana del desarrollo, los equipos de XP suelen utilizar la práctica del desarrollo dirigido por pruebas. Con este enfoque, el equipo escribe las pruebas de aceptación antes de desarrollar nuevo código. Si las pruebas funcionan correctamente, un nuevo código defectuoso que se introduzca no superará las pruebas, ya que aún no se ha desarrollado correctamente. El código pasará la prueba una vez que esté escrito correctamente. El proceso de desarrollo basado en pruebas se esfuerza por acortar al máximo el ciclo de prueba-retroalimentación para obtener los beneficios de una retroalimentación temprana.

La refactorización es el proceso de mejorar el diseño del código existente sin alterar su comportamiento externo ni añadir nuevas funciones. Al mantener un diseño eficiente, los cambios y las nuevas funcionalidades pueden aplicarse fácilmente al código. La refactorización se centra en eliminar el código duplicado, reducir el acoplamiento (conexiones dependientes entre módulos de código) y aumentar la cohesión.

al centrarse en mantener el diseño simple pero adecuado, los equipos XP pueden desarrollar código rápidamente y adaptarlo según sea necesario. El diseño se mantiene apropiado para lo que el proyecto requiere actualmente. El diseño se revisa de forma iterativa e incremental para garantizar que sigue siendo adecuado. XP sigue una filosofía de diseño deliberada que se pregunta: "¿Qué es lo más sencillo que puede funcionar?", en contraposición a estructuras complejas que intentan adaptarse a una posible flexibilidad futura. Dado que la sobrecarga y la complejidad del código están relacionadas con el fracaso de muchos proyectos, el diseño sencillo es también una estrategia de mitigación de riesgos.

En XP, el código lo escriben dos desarrolladores trabajando en pareja. Mientras uno escribe el código, el otro lo revisa a medida que se va escribiendo, y ambos cambian de papel con frecuencia. Esta práctica puede parecer ineficaz, pero los defensores de XP afirman que ahorra tiempo porque las parejas detectan los problemas pronto y hay una ventaja, ya que las dos personas dispondrán de una base de conocimientos más amplia sobre el código. Trabajar en parejas también ayuda a difundir los conocimientos sobre el sistema por todo el equipo.