Customer Reviews
Excellent 
2008-09-04
This book has all the information needed for start working and refining scrum estimation. The only complain I have is the chapter over deciding between story points and ideal days, you should skip it(just use story points) and everything else is very valuable.
Great book...Helped me on the PM concepts of Agile. 
2008-05-13
I enjoyed this book...I found it helped with the project management aspects of Agile while keeping grounded in common sense.
Agile Planning bible... 2008-05-07
Mike takes agile planning to a new level with this one of kind book. Its a pretty simple read, not to high level but enough detail to get you through in the weeds of your day.
Great, but it could have 100 pages less. 2008-05-03
I've read this book because of the "Planning" in the title. It does cover planning, but not in the depth that I was looking for.
It shows a lot of good concept ideas, like prioritizing based on mandatory, linear and exciting features. Or when it talks about using a story as tracer bullet to provide more info to the team. I really like the idea of the theme parking lot.
For someone that uses scrum on a daily basis, the idea of creating tasks just before comitting to a story sounds silly, but it makes a lot of sense.
The book gets really very good after page 200. It's where most of the "planning" is.
The Case Study on last chapter is really very good.
I would recommend this book to everyone interested in agile development, but it's not a introductory book. It's more for the middle practitioner.
For project managers and developer who want to fullt under the agile methodology 2008-04-30
This book is a well written synopsis of how an agile methosology should work, with adhering to a hard and fast methodology ( be it XP or SCRUM or Crystal). I would recommend this book to anyone who is using or is planning to implement an Agile setup. This book shows that Agile, does not mean 'no' planning, far from it, but shows that estimating project size is key to delivering on time and what is expected.
I recommend it to project managers and developers who are mature enough to understand that guess work makes everyone's job harder and that software is developed to support business needs that must lead to profit
Spot on 2008-04-12
I have been acting as the Scrum master for my team for about 6 months. We have gotten pretty good at planning and executing an iteration at a time. Our customers have always wanted to see a longer-term plan. I've read several other books but none of them have come close to this one. It has been invaluable in helping us to prioritize, estimate, plan, and communicate several iterations in advance.
Agile and not scrum 2008-03-29
I've been doing scrum for quite a while and really appreciated this book as it is *not* specifically scrum and adds other very interesting techniques to use. My favorite is planning poker, which basically all my teams use now with great success.
A must to round out your Agile understanding.
A Pseudo-Quantitative Method for Estimation 
2008-02-25
This book presents a pseudo-quantitative method for estimation for so-called agile development. Cohn suggests subjectively estimating relative size of user stories on some arbitrary scale (within one order of magnitude) in a round-table approach called Planning Poker. Getting input from key stakeholders is a good strategy....not only does it develop buy-in, it sets expectations and clearly defines the scope. However, caution must be taken when using Planning Poker; these roundrobin techniques are often used as a way of influencing a group to agree on a predetermined conclusion. In addition the team must guard against "Groupthink," where individuals intentionally conform to what they think will be the ultimate conclusion of the group as a whole. During this Poker process, Cohn suggests estimating relative sizes of user stories on a Fibonacci sequence scale (1, 2, 3, 5, and 8). The problem with using this--or any numeric scale--is that there is an inherent implication that the effort required to implement each User Story is proportionate to the scale. (I.e. a user story estimated at 8 Story Points will require 4x the effort of a User Story estimated at 2 Story Points). In estimation false precision is the enemy of accuracy. Any computational methods applied to these Story Points (such as the calculation of velocity, essentially a delivery rate, in terms of story points implemented per unit time) is much less valid than the number imply. Agile development is much more adaptive than waterfall and even more so than iterative. With its Timeboxed deliveries on the order of weeks (rather than months) and responsive nature with respect to requirements change, I can see how predicting this type of fluid development would certainly qualify as nontrivial.
With that said, the advantage of relative size, according to Bozoki, is that very early on, estimates of relative sizes are more accurate than estimates of absolute sizes. Cohn's methods also leverage another fact of life: the Law of Large Numbers (LLN). The LLN provides a tendency for errors inherent in a bunch of small estimates (like User Stories) to cancel each other out to a limited extent.
My primary concern with this method is that we have an qualitative method disguised as a quantitative method with out adequate consideration of estimate uncertainty/error propagation.
Excellent agile companion text to "Software Estimation - Demystifying the Black Art" 2007-12-23
This Robert C. Martin Series text by Mike Cohn has been unfairly criticized by previous reviewers. The content in general is very well written, and the subject matter flows very well from topic to topic. In my opinion, there is some missing detail that could have served well those readers new to the topic of estimation. In light of this observation, I think that "Software Estimation - Demystifying the Black Art" (see my review for that work) can be seen as a companion text to "Agile Estimating and Planning". Mike Cohn simply focuses on agile projects, so if such projects are the primary focus of the reader, they might otherwise get caught up with detail that is not necessarily within their domain. From my experience, however, it will serve the agile practitioner well if they understand some of the theory behind the practice of general software project estimation. Of course, Mike Cohn also provides a considerable portion of the book to agile planning in general, and this topic is what makes the book unique in 2007. While other books of this genre can be expected in the near future, the seven parts of the discussion cover the subject matter well: "The Problem and the Goal", "Estimating Size", "Planning for Value", "Scheduling", "Tracking and Communicating", "Why Agile Planning Works", and "A Case Study". Each of these parts build upon its predecessors, finally culminating in a case study. I found especially valuable the discussions on agile planning in general, the different methods of agile estimating, how to prioritize deliverables, project schedule iterations, velocity, and tracking. Throughout the text, the author provides dozens of examples with just the right amount of tables and diagrams to aid the discussion. This book is a relatively easy read for a wide audience, and the quotes shared at the beginning of each of the chapters provide a humorous (although usually unintentional), realistic look at the philosophy of estimating and planning by individuals not in the software industry. My favorite quotes of the lot: "Planning is everything. Plans are nothing."; "A good plan violently executed now is better than a perfect plan executed next week."; "In a good shoe, I wear a size six, but a seven feels so good, I buy a size eight."; "Prediction is very difficult, especially about the future."; "There's no sense in being precise when you don't even know what you're talking about."; "It is better to be roughly right than precisely wrong."; "To be uncertain is to be uncomfortable, but to be certain is to be ridiculous.".
A must read for today' technology executives 2007-07-11
Mike Cohn comes up with another gem of a book to assist technology development teams in creating the right products in a timely fashion for today's fast paced world. If you're in the web 2.0 space where continuous innovation is the norm, then this is a must read book. Even if you're in the more traditional industries developing products, this book will be a great help for you whether you've already made the jump to agile development or are considering it.
One thing not covered in this book, but is a must for making any significant change in the way that your staff performing their jobs is to make sure that you're prepared for it. If you're considering making the jump to agile development, I strongly urge you to first consider the people side of change management to make sure that your company and teams have the support that they need to make and then maintain the change. I guarantee that there will be resistance to switching to Agile development from some portion of your team, so be prepared for it by doing your own research into change management. A possible suggestion would be a Prosci Change Management course, but there are others.
Once you've done your preparation for managing the people side of change management, then Mike's book is then a great cookbook on the methodology of succeeding at Agile development. It contains real world examples and suggested best practices to help your teams succeed and have fun doing it.
