What do you think?
Rate this book
Planning Extreme Programming
Planning is critical; without it, software projects can quickly fall apart. Written by acknowledged XP authorities Kent Beck and Martin Fowler, Planning Extreme Programming presents the approaches, methods, and advice needed to plan and track a successful Extreme Programming project. The key XP Planning is not a one-time event, but a constant process of reevaluation and course-correction throughout the lifecycle of the project. Students will learn how planning is essential to controlling workload, reducing programmer stress, increasing productivity, and keeping projects on track. Planning Extreme Programming also focuses on the importance of estimating the cost and time for each user story (requirement), determining its priority, and planning software releases accordingly.
139 pages, Paperback
First published October 26, 2000
13 people are currently reading
627 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 20 of 20 reviews
March 6, 2014
The original manifesto for XP, this book finally codified a lot of the project management knowledge that came to me from quite a number of different sources. This is a fast book to read through and it does not waste your time with any of its material. I would recommend that every developer read this book for the shared vocabulary it offers.
That being said, some parts of the book left me dissatisfied. I think because I spent so much time in product-design oriented classes, I consider myself, fellow developers, ops people, management, and everyone interacting with the software to be stakeholders in its design.
This manifesto abdicates all responsibility for generating end-user value stories to the nebulous "customer" entity. While I agree that having the customer involved is imperative and that they should be generating the vast majority of the end-user oriented stories, I also believe that developers interests should align with the customer and that over time they should be able to generate stories with end-user value as well. The developers should work to learn the customer needs and work with the customer to generate stories that can be delivered quickly and correctly, rather than relying on a potentially non-technical customer's imagination and intuition in a constantly changing field.
That being said, some parts of the book left me dissatisfied. I think because I spent so much time in product-design oriented classes, I consider myself, fellow developers, ops people, management, and everyone interacting with the software to be stakeholders in its design.
This manifesto abdicates all responsibility for generating end-user value stories to the nebulous "customer" entity. While I agree that having the customer involved is imperative and that they should be generating the vast majority of the end-user oriented stories, I also believe that developers interests should align with the customer and that over time they should be able to generate stories with end-user value as well. The developers should work to learn the customer needs and work with the customer to generate stories that can be delivered quickly and correctly, rather than relying on a potentially non-technical customer's imagination and intuition in a constantly changing field.
January 18, 2019
If you’re doing Scrum, 99% of this book is still relevant. Despite a few bits of clangy prose, it carries buckets of earned wisdom.
May 1, 2024
it's good to re-read the bible every once in awhile
July 27, 2017
Outstanding overview of how to interact with engineers and plan in XP.
October 2, 2018
Well, there were definitely some interesting ideas but if you have read XP or Scrum books, most of it would come as new material.
February 6, 2020
Excelente y conciso resumen de cómo planificar un proyecto en forma ágil
June 15, 2020
Was written so long back, people still haven't learnt much of what was known then.
October 3, 2011
Two authors for whom I have immense respect and a foreword by Tom DeMarco. I finally got around to reading this one. I delayed because the other XP books already covered the planning game as far as I'd care. But hopefully these authors can make it interesting still.
I was pleasantly surprised that something apparently so simple as the planning game could have almost infinite subtleties. The authors have streamlined it somewhat but the original intent stays. Divide the work into manageable chunks and let technical people make the technical calls and the business people (customer) make the business calls. This is not only when to schedule stories, but when to split them and actually when they are done. Well worth the small investment in time.
Incidentally, I met Kent Beck at a local event the day after I finished reading this book, on 2004-11-17, and I got him to sign my copy.
Update: I met Martin Fowler at a local event on 2010-05-12 and I got him to sign my copy too. Two for two.
I was pleasantly surprised that something apparently so simple as the planning game could have almost infinite subtleties. The authors have streamlined it somewhat but the original intent stays. Divide the work into manageable chunks and let technical people make the technical calls and the business people (customer) make the business calls. This is not only when to schedule stories, but when to split them and actually when they are done. Well worth the small investment in time.
Incidentally, I met Kent Beck at a local event the day after I finished reading this book, on 2004-11-17, and I got him to sign my copy.
Update: I met Martin Fowler at a local event on 2010-05-12 and I got him to sign my copy too. Two for two.
August 12, 2015
The book is thought provoking and filled with easy to understand examples. Still I remain somewhat ambivalent towards it. Certainly, the point that the customer is the one who should be making decisions with regards to what should be done and in what order was strongly and reasonably made. The same is true of the idea that the source of estimation should come from the developer and be balanced by the theory of the previous days weather. I wish I could articulate what makes me conflicted with regards to the book, but I can say that it feels like an earnest and well meaning salesmen just tried to sell me and I still have just enough doubts to not go with the sale.
May 26, 2011
Well written, easy to follow book with great examples. Lots of ideas to try and hints and tips of common pain points. Have been adapting our current agile-ish process based on my readings so far, and will continue to do so to ensure we have a process that works for out team/product.
Favourite takeaway is probably:
"As the basis for your planning, assume you'll do as much this week as you did last"
which just makes sense
Favourite takeaway is probably:
"As the basis for your planning, assume you'll do as much this week as you did last"
which just makes sense
May 28, 2012
Great complement to the classic "Extreme Programming Explained", but more targeted to the XP management side of things.
Planning and managing XP projects had been already covered to some degree in Beck's previous work but this book goes into much more detail, and will probably prove useful for the aspiring manager of an XP team. Plus, it's a relatively light and easy read.
Planning and managing XP projects had been already covered to some degree in Beck's previous work but this book goes into much more detail, and will probably prove useful for the aspiring manager of an XP team. Plus, it's a relatively light and easy read.
July 28, 2007
I read this sometime ago. I was very excited about XP and still think it is a wonderful practice. I was able to work on a team for a few months where XP was used and was definitely a productive enjoyable time. It is difficult to get management interested in this.
January 23, 2008
This is a book that focuses on how to do release planning when you have instituted XP. There is little, that isn't in Extreme Programming Explained, but it is a little bit better organized and a little more focused on the Customer (i.e., the Product Manager in XP lingo) rather than the Engineer.
January 25, 2010
Provides some very practical advice if you've read "Extreme Programming Explained" and now have to put all those high-level ideas and new practices into action on a real project - I keep it very close to my desk.
April 2, 2011
First great approach to understand what's behind an agile project development.
April 22, 2011
A great book with a unique take on planning and steering software development projects.
August 23, 2011
Читал в 2004 году. В те годы XP была в диковинку и все боялись внедрять эту методику. Сейчас обычное явление.
April 8, 2015
Quick nice followup on planning techniques for Extreme Programming, in terms of estimates, scope adjustments and so forth.
January 25, 2016
Another way to see development projects, much more people oriented. It seems risky, but worth trying when traditional management tools keep failing on and on
April 29, 2017
This book was written by two very big names of modern software development. This is the recipie for a masterpiece. Somehow, it's very good, but not a masterpiece. It even coul be considered as superficial on many topics. At this point, you may call it a gentle introduction to cohn's "agile estimating and planning".
Displaying 1 - 20 of 20 reviews
Can't find what you're looking for?
Get help and learn more about the design.