エクストリーム・プログラミングの他の要素には、ペアでのプログラミングや広範なコードレビューの実施、すべてのコードのユニットテスト、機能は実際に必要となるまでは追加しない、フラットな管理構造、コードのシンプルさと明快さ、時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する、顧客やプログラマーでの頻繁なコミュニケーションなどがある。この方法論は、伝統的なソフトウェアエンジニアリングのプラクティスの有益な要素を「極端な（エクストリームな）」レベルに持っていくという考えからその名前を取っている。例えば、コードレビューは有益なプラクティスと考えられており、これを極端にすれば、コードを「継続的」にレビューする、つまり、ペアプログラミングのプラクティスとなる。
歴史.
起源.
急速に変化する要件は、製品のライフサイクルの短縮を要求し、しばしばソフトウェア開発の伝統的な方法と衝突した。
クライスラーは、システムののために、著名なSmalltalk実践者であるケント・ベックを招き入れたが、開発プロセスに関するいくつかの問題点を指摘したことで、彼の役割は拡大した。 
ケント・ベックは、手法の初期のコンセプトの説明を残している:
ケント・ベックは、これらの方法の開発と改良の支援のために、をプロジェクトに招いた。
XPの背後にある原則とプラクティスに関する情報は、オリジナルのウィキであるカニンガムのでの議論を通じて、より広い世界に広まった。
このシリーズの著者たちは、XPとそのプラクティスについて、様々な側面から考察をしている。一連の書籍には、プラクティスに批判的な本も含まれている。
現状.
元のプラクティスに求められていた高い規律はしばしば道端に捨て置かれ、厳しすぎると思われていたプラクティスの中には、銘々のサイトで非推奨になったり、縮小されたり、あるいは未完成のままにされるものもあった。
たとえば、各プロジェクトにおける一日の終わりの統合テストの実施を、週の終わりのスケジュールに変更したり、単に相互に合意した日でのテストに減らしたりする。