I have to start by admitting that I purchased this in the Kindle edition. This was very convenient when I was initially reading it. However, now that I have completed the book I wish I had the physical copy for quick reference.

I would buy this book again, and suggest it to others. Mr. Cohn describes it as a book about planning which includes the background in estimation as planning without estimation is impossible. He also points out that the title was very intentional. To have a successful Agile project your planning and estimation must also be Agile. My focus for this book was on the estimation front. I also used it as a reference for my PMI-ACP certification. It is nowhere near a complete reference for the certification, but was never intended to be. In the realm of moving our estimations forward it was a great help. Most of what we currently do for estimation can be traced back to what I learned from this book. If you are interested in knowing simply what each section of the book is about the Introduction is very well written and will tell you exactly what you want to know. In light of this I will be covering what I took away from it in a little more general sense, showing where I found value.

The first section is where I learned some valuable background on estimations, planning, and agile. Previous to this I had not really dug into the business reasons behind estimation. I have understood the concept of ROI and better decision-making, but risk reduction and managing uncertainty were new to me. Planning is another area that I had never approached in the greater context of the whole organization. The idea that planning is a way to build trust had never occurred to me. I have always learned to “plan the work and work the plan.” This is a plan focused method of planning and not considered Agile. The majority of the first section dealt with a background on planning.

The really big take away for the first section is in regards to planning. Planning traditionally has been more focused on plan and process it outlines. In agile planning the focus comes off of the actual plan and process outlined by it, and moves instead to the act of getting a good plan communicated to all stakeholders. Instead of creating a plan and doing everything possible to prevent changes to it delivering it exactly as stated, which generally fails, a plan is created to be flexible within limits agreed upon by the stakeholders. the plan is continually examined and adjusted as necessary. The final goal is not to deliver the exact product as originally specified, but to deliver the best value for the stakeholders within the constraints provided. One way this plays out is a concentration on delivering features in the product as opposed to finishing activities on a plan. The Agile project manager is no longer tied to a schedule of tasks they must drill into their team. They are free to instead help the stakeholders, or product owner, decide what is most valuable as the project goes on knowing that it will likely change. They then help the team deliver that value by removing obstacles.

The second part of the book is where I found the most value for my day to day work. This section was all about estimation. The idea of estimating by effort instead of hours had been floated to our team in the past, but never explained and dropped as a topic before any progress was made. After reading this section and doing some follow up research online I was sold. The first part of this section taught me about the idea of relative estimation. This was all very obvious to me as I read it. That is not to say it was not valuable. It was obvious in a “that’s what I’ve been trying to communicate” way. I have always known I was bad at estimating, and that it followed me to my job. Now I had a frame of reference, and ideas for solving the problems. The rest of this section was very “nuts and bolts” with great examples. These are concrete methods and practices that we were able to start incorporating immediately. A big example would be Planning Poker, which I go into more detail about here (pt 1) and here (pt 2).

Parts three and four were good for me on an intellectual level. I will be referring to them in the future, but currently am not directly responsible for the functions associated to full project planning and scheduling. I do use some if the information from part three, planning, while I coach our business analysts and project manager. Part four, scheduling, is something I have not had the opportunity to get involved with on a larger level as of yet.

Part five has been getting more useful lately as we get into retrospectives and examining our process while looking for improvements. It speaks to monitoring the project progress and reporting it to the rest of the business. We have been getting some pressure from outside of the team lately to account more for what we need, when we will get things done, and how we are progressing. We have been using burn down charts to help show our progress as shown in that section. We have also been working hard to keep management informed via involving them in some of our sprint review meetings, retrospectives, and planning sessions. They are not in all of them, but are welcome at any time.

Part six worked as a nice book end going over Agile again and helping to cement the reasoning and arguments for it. This was a good section for helping to fuel any discussions about why we do what we do,. The last part was a pretend case study of a team trying a new project using Agile. While a good read, it felt a little “to perfect” for me. I would have liked to see the fictional team have some kind of struggle somewhere along the way. I cannot imagine any implementation of Agile anywhere going as smoothly as pictured in it. How the team addressed the problems would be a good source of ideas for when we encounter similar ones.

At the end of the day this book has some value for certification preparation, more value as an idea mill for moving to Agile, and the most value as a desktop reference. Even thought I have this in an electronic version I will likely buy it in physical form when I move completely beyond the developer role to Agile Coaching or Project Management.

I bought this book with no intention of getting any reimbursement and have not received one. This review is not influenced in any way by the author, publisher, or any other parties that may or may not provide affiliate income if you purchase via the links included.

Agile Estimation and Planning by Mike Cohn