A 5 star review just doesn't mean anything anymore. There are some good ideas in this book, but large stretches of this book are just absurd. This thing reads like homework that was finished on the bus (you can almost see the bumps in the road). The structure of the book is completely haphazard. One minute, we are talking about doing estimates. The next minute we are trying to figure out how a project will pay for itself, then, it's on to how to split up stories that got too big. I was waiting for a sidebar with a recipe for a great chiffon cake. At the end of the chapter on estimating value, the author recommends another book and says that's where his content came from (citational plagiarism is called 'plugging,' Youngster). Then, the chapter on splitting stories made me laugh out loud in places. Things like 'split stories along data lines,' or 'split stories along priority lines' or one of the funniest 'split it along CRUD lines.' Come on.
The good part of this book is the one chapter on estimation and discussion of things like using Fibonacci for bucketing of estimates into story points, the importance of seeing estimates as relative, and the idea of doing planning poker. In short: again, it's an article that was turned into a book by a set of expansion techniques that are astounding for not being illegal, let alone questionable. And all this inside a fortress of testimonials that makes Fort Knox look lightly defended.
on February 11, 2006
Better planning, as Mary Poppendieck (author of "Lean Software Development") points out, results in a higher standard of living for the individual, for the team, and for the organization. With "Agile Estimating and Planning", Mike Cohn delivers a beautifully pragmatic approach for pushing us into the notion that this higher standard of living is completely attainable for our software development projects in this lifetime.
Mike's earlier book, "User Stories Applied" has been one of my most cited books when working with teams new to agile software development. Understanding the usefulness of the story concept as the base unit of function delivery has put these new teams in a good steady stride for being realiably realistic about their work delivery toward feature completion.
With Mike's "AE&P", I now have a fully referenceable guide that moves the team story planning pragmatics to the next level: bringing multiple planning approaches to bear at multiple levels for multiple measures of software feature acceptance and completion. In his usual style, Mike delivers his guidance with wonderfully accessible non-software analogies. For example, "How long is a football game?" and "How long will it take me to move my pile of dirt?" for understanding the distinction between effort (or ideal hours/days)and duration (total calendar hours/days). These simple mental models set the stage for ruthlessly correcting the many misunderstood atrributes of planning and its life partner estimating. Having shattered the myths of task-based Gantt Charts, PERT charts, and Work Breakdown Structures as completely repeatable prediction models for planning and estimation, Mike rebuilds the planning toolbox with practices that truly work. He buoys his practices (such as Planning Poker and frequent replanning) with the de rigueur reinforcements of appropriate metrics (e.g. how many tests did we complete in the last iteration, how many story points did we complete in our worst iteration, how are we tracking today with our estimates of what is left to do) that really guide teams in how to steadily improve their planning acumen.
Because my passion in agile software development has focused more and more on the importance of participatory decision-making in order to make planning commitments stick, I am particularly grateful that Mike sets a high collaborative bar with regard to how team's must work in order to create effective and actionable plans. Guidance on collaboration, high visibility, and continuous inspection are woven into all the practices in Mike's book, start to finish.
If I can leave you with only one piece of advice from "AE&P", take Mike's "Dozen Guidelines for Agile Estimating and Planning" (Chapter 22) and nail them to your team's door. In fact, nail them to your business partner or product manager's door. If you allowed me a second piece of advice: read through his excellent case study that follows in Chapter 23. And then, if you forgave me one final piece of advice: be prepared to start enjoying your new standard of living.
on November 24, 2005
The book is well structured and easy to read. In my humble opinion, it comes with a strong "buy" rating for any Agile practitioner or a current PMI certified person who wants to contribute to the knowledge economy of ever changing requirements. The book is right sized (finish in a coast to coast trip in US). Practical in its content, it provides lots of examples and case studies, from software as well as non software fields to illustrate the concepts. The detailed case study at the end of the book is invaluable.
Several chapters were much thought provoking, specially how to handle team dynamics and cross team estimation. The book did not right fully delve into any details of that, it's a topic for another time.
Part I of the books sets up the context.
Part II details on estimating the size, and the techniques and tools for doing that; in fact it comes with some simple tools, which can be really customized and expanded quickly.
Part III caters to what I call "value add planning" planning the work by prioritizing by business value, The books touches the concepts of financial project analysis, however there are better books for that, and the author provides the references.
Part IV brings in the concept of time, and the handling of "estimating for effort" and estimating for duration" is simply superb. Also an entire chapter is dedicated to Buffering and its need and for multi-team projects.
Part V presents tools and motivations for monitoring and communicating.
Part VI presents why Agile Planning works, and honestly I skipped it, expect the guidelines ( Page 254) which I read to validate my knowledge.
If there is one thing that I would change in the book, it would be the story point example with dogs. It would be a little confusing if you have no idea how a Great Dane would be different from a Duchshund! But hey, I think the book gets the message across very well.
What I would like to see in the second edition-- softcopy of some tools that goes with the book, may be some templates that can be customized...but then again, you should not be in this business unless you are able to cook these tools up yourself !!
on November 15, 2005
Aside from being one of the most highly respected and sought after Agile consultants, Mike Cohn is a prolific writer with a focus on delivering practical information based on years of real-world experience bringing agile into organizations. This book continues in that vein, delivering both high level theory surrounding empirical estimating and planning techniques as well as practical "how-to" implementation details. This book drips of real-world experience; while other books seem largely theoretical, Cohn's experience implementing these techniques comes through very clearly.
If you're implementing agile, I highly recommend this book and the techniques outlined for bringing an empirical approach to estimating and planning. There is a misconception that agile is weak on planning; that's not true, there just hasn't been a practical guide before this book. Buy it, read it, carry it with you where ever you go.
on April 15, 2006
This is an extremely interesting book on how to deal with uncertainty of software projects' scheduling. Mike Cohn describes and compares methods for sizing and controlling project work, estimating the time necessary to complete it, and explains which practices do or don't work and why. He has managed to show not just enormous knowledge and experience on the subject, but also to pass his excitement about it.
Written in practical style, the book covers in great detail the science of estimating project size (by using story points and ideal days), intelligently controlling project's and iterations' scope (by evaluating the value of features and prioritizing them), scheduling work (by controlling features and value in each iteration), and tracking the progress. Every statement is supported by statistic, known theory or experience, or common sense. I learned about the Kano's model, financials of quantifying benefits of software, and found support of my own ideas on why managers and developers see things differently.
This book is for grown-ups. 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.
on April 21, 2006
Many, many books have been written about Agile Software Development - and I love most of them. But also I'm beginning to think, that they are repeating themselves more and more. They are all praising Agile thinking, norms and principles. That's fine - but it isn't very instructive. It doesn't take the reader by the hand and say "come here, this way... Let me show you how to ...".
But now - finally with Mike Cohns "Agile Estimating and Planning" - we have a book that both digs down in a specific discipline and on the same time takes the reader by his hand and help him find his way through the maze of estimating and planning in a highly dynamic environment.
Before I read Mikes book, I didn't realize excatly what it was, that I was doing with estimating and planning in my own Agile projects. I just did it... Now I understand how much there is to learn, when you are new to the planning-challenge in dynamic and Agile projects.
A detail I like particuarly is, that Mike describes both Ideal-Days and estimation-points as two different ways of estimating. I agree with the book, that Ideal-Days is too difficult to use. The idea is, that an "ideal day" is a day, where you can work all day without being disturbed. Everyone knows, that these days does not exist - but we estimate as if they did. Afterwords we add some factor to compensate for disturbance. My personal challenge with this technique is, that people tend to forget the difference between ideal days and reguler days, which of course leeds to too optimistic plans. Mike advocates for estimation points, which have worked well for mee. Reason is - i guess - that estimation points are never mixed up with working days, which makes planning much easier and more reliable...
If you need some great advice on estimating an planning in Agile (and other?) projects - get Mikes book!
Founder of the Danish Agile User Group
on July 11, 2007
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.
on April 26, 2007
Agile Estimating and Planning was just the book we needed. We'd read many books on the topic of lean development but most of those books give you the principles but say very little about actual application. They typically leave it at "see what works for you". Mike Cohn's book deals with how to make those very hard decisions when you first start. What is the norm and what works well. Not only did it provide those guidlines for those decisions it explained the why's behind it. For a non-agile project to transition into agile it is often difficult to hiccup at the beginning specially when skeptics are lerking around to point out things that are not working well. Although iterative improvment is still the name of the game it doesn't hurt to have your first 2 iterations come out as a success which is what happened to us. With Mike's help we were able to make some good decisions from the start that were winners with confidence and ease. We will continue to refine them but having a good base to work from was very helpful.
The book literally goes through how to make key decisions for the most difficult challenges you are faced with when starting an agile project. We couldn't have done it without this book. I highly recommend it and I've ordered several copies for my project managers and team leads.
on February 24, 2008
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.
A methodology for estimating and planning in an agile environment is presented, but it is very limited. In some cases the book raises issues with what is presented, and then ignores them. Some examples:
- Requirements are sized via "story points" based on complexity - the fact that a given number of points may take longer if it involves new technology is mentioned but not addressed.
- In determining what stories can fit into an iteration, the book does not consider balance of functions (analyst, database developer, software developer, tester, etc.). In fact the book goes as far as saying that stories/tasks should not be assigned in iteration planning, and that if a software developer has extra time, he could help with writing stored procedures or testing. Also there is no mentioning of how to plan team composition, and/or whether the team should ever be augmented with contractors when certain functions have too much work.
- In prioritizing, various models are suggested (financial and desirability), but does not present any way to combine the approaches.
- In splitting stories, it is suggested to split into features versus tasks, but there is no mention of the added cost of having to redo more pieces of code (and more tests) more times. Similarly, when editing code, the author recommends against addressing known bugs in the code!
In summary, the book presents a methodology that evidently works well for some, yet has a fair number of holes.