Reviews for Agile Estimating and Planning (Robert C. Martin)

1. Agile Estimating and Planning may be as close as I ever get to a silver bullet.

   Rated 5 out of 5 stars, March 12th, 2010

   I bought this book because I'm generally rubbish at estimating (I usually under estimate). Also, although we have the technical elements of agile (source control, unit tests, continuous integration, etc) sorted, my agile project management is not all it could be. Agile Estimating and Planning may be as close as I ever get to a silver bullet.
   
   To be honest I expected to be let down and that the scenarios described in the book would not match the situations I find myself in. I was not let down at all. The book covers both planning when features are important and planning when a deadline is important.
   
   It taught me that it was wrong to break stories into tasks when release planning and to leave that for iteration planning. The book discusses the use of both story points and ideal days in estimating, what they both are, the differences between them and then suggests you should use story points.
   
   It described what release and iteration planning are and when to use them. It also discusses how to predict, where necessary, and how to measure velocity in order to calculate the duration of projects. One of the most important things covered from my point of view was how, when and with what to report to the product owner and stake holders.
   
   The book finishes with a 60 page case study. I was tempted not to bother reading this as it goes over the main points covered in the rest of the book again. I was glad I read it and if you buy this book you should read the case study if you read nothing else. It helps put in context how estimating should be done and describes the processes surrounding it.
   
   All I have to do now is write a distilled version for my team, including the project managers, product owners and stakeholder and put it into practice.
   

2. Practical guidance that works

   Rated 4 out of 5 stars, November 12st, 2009

   If you want a book full of useful practical techniques for software project management that actually work, then this is the book for you. It doesn't prescribe a rigid methodology (the one-size-fits-nobody approach); instead, within the generic Agile framework, it presents a number of tools and ideas that have been proven in the industry, and shows how they can be used and combined to improve software project planning, and help with accurate tracking and predictability of delivery. The pace is slightly inconsistent; some sections don't seem to add much, others are invaluable core knowledge. But whether you're new to Agile processes, or an experienced software project manager wanting to learn more, this book will be helpful and informative.
   
   The only part of the book I felt didn't work was the case-study at the end. It is too over-simplified and superficial; a dumbed-down summary of the rest of the book. The main part of the book makes the point eloquently enough, and the case-study just unnecessarily over-states the obvious. Given that the book is aimed at intelligent, competent, software development managers, the tone of the case study just seems inappropriate, and is the reason I give the book four stars rather than five.

3. Best Buy - not just for Agile Projects

   Rated 5 out of 5 stars, May 12nd, 2009

   Cohn's book, as the title suggests, is firmly aimed at the Agile development end of the market. The book contains much useful material that is otherwise scattered throughout the literature - and material that a casual reader would not expect to find in a book on agile development techniques, so the book becomes worth reading for practitioners of all project sizes.
   
   For example, there is a complete chapter on the prioritisation of requirements by desirability using Kano analysis. This technique divides requirements into three groups:
   - Essentials - those requirements that are essential for the stakeholder to even consider using it;
   - Linears - those requirements that are linearly valuable, ie those where doubling an element of the requirement is perceived as being twice as desirable;
   - Delighters - those requirements that delight a stakeholder - usually only a small number being necessary.
   
   The author describes techniques to draw up a questionnaire based on Kano analysis for potential customers to quantify which requirements they categorise into the three categories above. This will also business stakeholders (such as product managers) to prioritise requirements.
   Cohn has a whole chapter on financial prioritisation - techniques that allow the quantitative financial measures be associated with requirements. The measures discussed are: cost (retained revenue, operational efficiencies and net cash flow), net present value, return on investment and discounted payback period. Armed with this information, business stakeholders are able to prioritise the requirements more easily. In addition, this sort of information adds credibility in the eyes of the CFO, who may otherwise remain unconvinced of the benefits of Agile projects.
   
   In addition, Cohn devotes part of the book to estimating buffer size - something that is often missed in agile projects. He deals with both feature and time buffers and the best time to use each - or a combination of both.
   
   The book becomes a "best buy" for all with its in-depth, readable treatment of topics that are rarely seen in a software development book.
   
   

4. Essential for 'agile' Product Owners and Business Analysts

   Rated 5 out of 5 stars, January 12st, 2009

   One only has to read all the comments from the leaders of agile thinking to know that this is an excellent book. It's definitely in my top 10, probably in my top 5 list of essential 'agile' reading. This book takes the agilist into areas often neglected; those topics traditionally dealt with by the Business Analyst; the person who shapes the product being produced, who has his finger on the pulse with respect to value and desirability of all the possible features that may be incorporated in a product; the person who knows which products should be prioritised for development. It brings to this person a toolbox of modern techniques that allow him to interact with a modern product development team. With a good few years experience in BA-like roles, this book taught me quite a few things that I should already have known but did not.
   
   However, this book is not just for BAs and their ilk; as other reviewers have stated, it is also very instructive for developers and project managers.
   
   Mike's style is very accessible without skimping on technical detail; this is a reasonably easy read for those who do cover-to-cover, and also a great book for those who want a desktop reference.

5. A very useful reference guide

   Rated 4 out of 5 stars, September 12th, 2007

   This is a good book for project managers and senior developers who have enough experience to understand that even a practice like agile development needs a framework to work within and a certain number of standard project management controls to be successful.
   
   It deals with some of the practical issues a project manager will face like prioritisation techniques, acceptable levels of functional delivery, inter-dependencies, estimating, padding estimates, monitoring progress, release and iteration planning.
   
   Cohn hasn't written the book specifically around any one methodology (ie SCRUM, XP etc) which is good, as in reality people lift and use ideas from various methodologies. In that respect this book is a good reference guide to dip in and out of, picking the bits that are most appropriate, rather than reading it cover to cover. It is well laid out and easy to read.
   
   As a project manager I am responsible for planning the end-to-end process from requirements through to delivery, therefore I felt that there were some areas that were either not covered in enough depth or omitted altogether:-
   * the writing of user stories, and how to plan for their handover to programmers (if produced by a separate individual or team),
   * while programmer testing is discussed their is no mention of functional (or acceptance testing) of the produced code,
   * scaling up to large (possibly enterprise size) projects is only skimmed over,
   * while the estimation techniques discussed can be applied to user story creation and functional/acceptance test creation and execution it is implied rather than explicitly suggested,
   * personally I didn't feel that the book addressed the area of changing requirements enough, but maybe that's me.
   
   Being a project manager with more waterfall than agile development experience I might be being overly harsh in these criticisms.