I have read both books, XP Installed and Planning XP and if you only want to buy one of them, buy XP Installed. Planning XP is well written, but you can find most of it in XP Installed. If you are using XP as your software development process, you might want to give Planning XP to your manager or planner, so that he has an overview of all the planning tasks. These books are well written and easy to read. The books repeat themselves a bit too much to my taste.

I found the last remark in the Afterword by Dan Rawsthorne quite to the point; '... XP is the first popular process with the focus on validation built in. It won't be the last. I hope'. That is my feeling as well. The core principles of XP are very interesting, especially if you have seen various projects fail miserably. I am however not yet completely convinced that XP would work for all projects. It would have been nice if the books would have given some advice when applying XP works and when it is better not to apply XP.

Extreme Programming Installed

Extreme Programming makes a clear distinction between the rights and tasks of the customer and programmer. The customer chooses the user stories that are to be implemented for every release and prioritises them. Releases are frequent because they give the customer the possibility to provide early feedback. The customer has the right to change his mind. XP relies heavily on unit tests, acceptance tests and frequent integration. The book explains that a test, to test the intention of the code, should be written first, only after which the real code is written. The book explains how one makes estimates and refines them. Estimates will become more and more accurate with experience.

Planning Extreme Programming

You have all the planning guidelines together in the little book of 139 pages. You would not read this as your first book on XP, but rather after you are acquainted with the basic ideas and are applying XP to your software process. The book covers how to write the user stories, estimate them and prioritise them. The book discusses how to plan the iterations and the releases and how you can track your efforts for each iteration. There is hardly much to it, XP is advocated as a lightweight process, to stop producing mountains of unnecessary documentation.

It would be interesting to read some case studies of companies applying the XP process. Companies who apply heavyweight processes and try XP for one project and 'Cowboy' companies who use no process at all, who start applying XP. Maybe an interesting topic for the next book in the XP Series? One thing which I found missing was the concept of documentation. The argument of XP against documents is that they get outdated. My opinion is that in most companies it is still useful to have some basic documentation. However, I doubt that it is possible that the design stays in the heads of people.