Good book but I really and not a planning type. Enjoyed for work and where I work this is very applicable. Its the business world unfortunatly.

A must for anyone who wants to understand why and how of planning in agile projects. The book has specific quantitative tools to estimate, plan, track and predict the progress of our projects. The last chapter is worth its weight in gold, and that shows through a case study with all the concepts used throughout the book, showing how agile planning works, from the initial requirements specification to the finishing delivery date. Highly recommended.

Aki meg akar ismerkedni az agilis becsléssel és tervezéssel, az ezt a könyvet olvassa el először. Remek tartalom, jó felépítés, minden fejezet rövid és könnyen olvasható, elegendő példa a témakörök megértéséhez. Persze aztán tovább kell lépni (pl. a User Stories Applied-ra), és közben átültetni a gyakorlatba a tanultakat. Alapmű.

One of the books I looked at while researching for my Master Thesis. Looked like a decent introduction to agile for large enterprises.

Quite complete but rather outdated. Some sections are extremely long. I enjoyed it quite a lot despite it being kind of old on this topic. New folks to this topic will find many things enlightening but probably way too detailed for them.

Defining story points, explaining a disciplined approach to story prioritization, laying out communication plans, defining buffers and much more are included with the nitty gritty details of how to plan and estimate with agility. I particularly liked Cohn's inclusion of graphs based on actual research to drive home the point that there is a right way and a wrong way; one increases productivity and quality, the other decreases quality and productivity. I expect those graphs to come in handy when countering the Agile Light proponents.

Agile Estimating and Planning has jumped to the top of my list of must-read books for Software Engineers. The book covers a huge amount of extremely useful information covering estimation and planning activities at a truly useful and workable level.

The book starts with chapters on defining the problem areas of estimation and plans, which include items like: estimated times being unrealistically precise (or at least giving the impression of being so), plans that are created and forgotten and then pulled out again when blame needs to be assigned, and various other problems with traditional planning methods. It then goes on to lay the foundation and ideas for estimating and planning activities that seem solid, factual and agile in the truest sense of the word.

Some of the biggest pearls of wisdom in the book are that plans are mere snapshots of time that capture a particular moment in the continuous process of planning. Planning goes on continuously in the methods proposed here, starting with feature planning moving onto prioritisation and release plans and down to iteration plans. These aren't then prepared and forgotten, but are revisited at the end of an iteration, or even during an iteration if problems start occurring. The role of plans are moved away from the unrealistic view of 'the plan governs all and must be adhered to' to the much more useful view of the plans capture the important information relating to the current health of a project. This is coupled with extremely useful information on how to monitor releases and iterations and continuous repetition that you are working with estimates and plans and that these can never be 100% accurate. The book also makes a big point of involving the entire team in the planning and estimating activities. After all, these are the people expected to do the work - who is better than them to work out how long it would take them?

The last chapter of the book was a real gem for me. It consists of a case study of the planning methods proposed being put into practice. It is for a fictional company but that doesn't lessen the utility of the chapter. It ties together all the ideas presented previously and turns them into a cohesive whole. It presents the planning sessions in an engaging and readable fashion and although it is a bit idealised it still comes across as realistic. It shows some skepticism to the methods from team members who aren't used to it, but then shows that once the entire team is engaging in and committing to the planning process they start to lend thoughts and ideas to areas where a more traditional process would leave them out. It ends on a slight downer for the team as they are 2 weeks later than their original time estimate, but points out that this is because they made the conscious decision to spend an extra 2 weeks in development to make a better product. This is constrasted to the previous project the team had, which was 6 months overdue and couldn't have been released sooner.

Overall, this book is a great addition to any developer's bookshelf. It isn't something that is 'just' for project managers, or 'just' for developers. Anyone working on a project that is attempting to be agile will gain from reading this book. It is likely that the techniques could even be used outside of software development, although all the examples in the book do deal with software projects so a non-developer reading it would need to either have a passing familiarity with the language, or wouldn't get full advantage from the many examples in the book.

Good detail.

I find this book very helpful with a lot of easy to understand examples.

Good reference.

Comparing with other agile-related books, this one stands out for several reasons:

- it is practical
- it uses the clear argumentation and examples, not playing the old boring song of “bad waterfall”
- moreover, it creates a blend of approaches that can be used in any project independently on the lifecycle model taken.

All in all, old but still gold.

Mike Cohn delivers with “Agile Estimating and Planning” a 360 degree view on estimating an agile project. He explains the topic in a understandable manner and gives you many good insights on what works and why. One of those tips is to separate estimates of size from estimates of duration. This fundamental idea behind story points is explained in a way everyone can follow.

On the other hand I’m not fully convinced that estimating in such a detailed manner is worth the effort. On big projects that are running for years it will work. But after Reading this book I could not tell where the lower limit is. Is a 6 month project still big enough? Or should I reduce the estimating effort as long as the project can be done in a year? A clear cut may not be possible, but an estimate on where to put the line would make this book more useful in the day to day work.