Having been involved in several agile projects, with various degree of loyalty to the concept, I found reading this book refreshing. Sometimes it gives me terms for something I have done without knowing exactly what to call. Sometimes I also find concepts or tools that have been more evolved than the one described in this classic (2005?) book. I guess I might be a little bored if I hadnt had those experience. However I would say the narrative in the case study at the end of the book may present some illustration for the less experienced.

One of the few "good" agile books out there.

One of the best technical books I have read and an excellent treatise on the subject. If you work with Agile or are interested in it, I highly recommend this educational resource.

Must read for those working in (or wanting to transition to) an agile environment. It’s really cool that it provides questions at the end of each chapter on how to apply the different concepts to your team. The last chapter is a hypothetical project and it illustrates how to put all together using a practical example.

Very good book. The case story at the end was a real exciter because of the style. Recommend for everyone starting on a scrum project or something alike ...

Covers each and every aspect I could think of. Sometimes too much words to express a simple thing. Cross-referencing other frameworks(PMBoK) is incredibly cool idea, but only available in the first few chapters.

Thorough review complementing the book and worth reading too exists on the Internet:
http://www.niwotridge.com/BookReviews...

If you like the part about estimates buffering, see this too:
http://en.wikipedia.org/wiki/Critical...

In some way it's similar to Allen Karr's books - nice to read, but you're not sure if separate pieces do add up to something coherent until the very end, which is exciting phenomenon.

After having read many books on agile software development, this is the book that finally made the entire system hang together for me. Cohn walks through all of the various aspects of agile planning, providing reasoning about why various approaches are taken as well as how to go about executing them. While the flow of the book can be a bit jarring at times, jumping from one topic to a seemingly unrelated one between chapters, I still came away from the book with a much better understanding of the end-to-end agile planning process.

The book only briefly covers multi-team planning so further reading regarding this may be warranted if you have that need. There are also sections of the book that gloss over some rather large topics (Kano studies, as an example) but the light coverage and accompanied references can lead to jumping off points for those who want more information. A few sections do contain essentially throw-away recommendations (such as the section on task breakdown of stories) but such sections are often in areas that real-world teams will have experience anyhow so it wasn't a big detractor for me. Lastly, if you're looking for advice on running an agile process with a distributed (off-shore) team, this book doesn't touch on any of those challenges.

As with most books on agile, this book carries on the tradition of focusing solely on the people processes without any recognition that certain *engineering* processes or practices (test-driven, continuous integration, etc) are necessary for long-term sustainability of an agile process. This is my number one complaint with all agile process books, and I've yet to find one that states, let alone defines, a certain level of software engineering organizational maturity is necessary before embarking on an agile process.

Despite these few drawbacks, this book did succeed in finally making the entire agile planning process click for me personally. After reading several of Ken Schwaber's books on the same topic I understood agile in the abstract but this book really brought it all together into a cohesive, pragmatic approach for me.

One of the most impactful books on the nuts and bolts of implementing agile software processes that I've ever read. A must for anyone that builds software for a living, either as a product person or an engineer.

Book describes scrum project approach in great details. Sometimes even too much. Author even create some calculations to make his thoughts more reliable. But in general book greatly describes how team should operate in the scrum. If you really want to understand how it should be done this is the book for you. Still you need to think if learning scrum is proper way of doing IT projects...

Sometimes it's good to return to the classics. I often think I should have a list of books that need to be read every 5 years. This book would be on that list. For a fifteen year old book on cutting edge software development, it is remarkably current.

Many of the ideas in the book are so common in development teams that you see many different variations: some good and some to be avoided. So returning to basics is an excellent reminder of how things should work. There is much in this book to be admired: separating estimating size and duration (story points and hours), the three planing cycles (release, iteration and day) as well as useful advice on estimating with time and feature buffers.

The final chapter of the book is a fictional case study which is brings all of the ideas together. Reading the case study is like being a fly on the wall on a high-functioning Agile team.

Though the book contains some useful advice on product management, it would be a mistake to consider that Cohn describes the be all and end all of quite a complex discipline. Similarly, Cohn touches on management best practices, delegation and empowerment and makes it sound as if there is a simple set of rules to follow. Both sections do, though, serve as valuable primers.

Was a decent book, most information I already knew from my job though.

Lot os insights about estimating and planning.

If you are starting on agile product development or moving from some role to agile product owner, or even scrum master, this book is for you.

If you are already an agile expert you won't find anything super relevant but it will help you a lot with different approaches about estimation and planning, iterations and releases also.

In my case I have learned several methods and approaches for estimation and planning. Also ideas about how to address technical debts during project with roughs deadlines.

Must read!