This is the eBook version of the printed book. Praise for Agile Estimating and Planning "Traditional, deterministic approaches to planning and estimating simply don't cut it on the slippery slopes of today's dynamic, change-driven projects. Mike Cohn's breakthrough book gives us not only the philosophy, but also the guidelines and a proven set of tools that we need to succeed in planning, estimating, and scheduling projects with a high uncertainty factor. At the same time, the author never loses sight of the need to deliver business value to the customer each step of the way."
—Doug DeCarlo, author of eXtreme Project Using Leadership, Principles and Tools to Deliver Value in the Face of Volatility (Jossey-Bass, 2004)
"We know how to build predictive plans and manage them. But building plans that only estimate the future and then embrace change, challenge most of our training and skills. In Agile Estimating and Planning, Mike Cohn once again fills a hole in the Agile practices, this time by showing us a workable approach to Agile estimating and planning. Mike delves into the nooks and crannies of the subject and anticipates many of the questions and nuances of this topic. Students of Agile processes will recognize that this book is truly about agility, bridging many of the practices between Scrum and ExtremeProgramming."
—Ken Schwaber, Scrum evangelist, Agile Alliance cofounder, and signatory to the Agile Manifesto
"In Agile Estimating and Planning, Mike Cohn has, for the first time, brought together most everything that the Agile community has learned about the subject. The book is clear, well organized, and a pleasant and valuable read. It goes into all the necessary detail, and at the same time keeps the reader's burden low. We can dig in as deeply as we need to, without too much detail before we need it. The book really brings together everything we have learned about Agile estimation and planning over the past decade. It will serve its readers well."
—Ron Jeffries, author of Extreme Programming Installed (Addison-Wesley, 2001) and Extreme Programming Adventures in C# (Microsoft Press, 2004)
"Agile Estimating and Planning provides a view of planning that's balanced between theory and practice, and it is supported by enough concrete experiences to lend it credibility. I particularly like the quote 'planning is a quest for value.' It points to a new, more positive attitude toward planning that goes beyond the 'necessary evil' view that I sometimes hold."
—Kent Beck, author of Extreme Programming Explained, Second Edition (Addison-Wesley, 2005)
"Up-front planning is still the most critical part of software development. Agile software development requires Agile planning techniques. This book shows you how to employ Agile planning in a succinct, practical, and easy-to-follow manner."
—Adam Rogers, Ultimate Software
"Mike does a great follow-up to User Stories Applied by continuing to provide Agile teams with the practical approaches and techniques to increase agility. In this book, Mike provides time-proven and well-tested methods for being successful with the multiple levels of planning and estimating required by Agile. This book is the first to detail the disciplines of Agile estimating and planning, in ways that rival my 1980 civil engineering texts on CPM Planning and Estimating.
After having read many books on agile software development, this is the book that finally made the entire system hang together for me. Cohn walks through all of the various aspects of agile planning, providing reasoning about why various approaches are taken as well as how to go about executing them. While the flow of the book can be a bit jarring at times, jumping from one topic to a seemingly unrelated one between chapters, I still came away from the book with a much better understanding of the end-to-end agile planning process.
The book only briefly covers multi-team planning so further reading regarding this may be warranted if you have that need. There are also sections of the book that gloss over some rather large topics (Kano studies, as an example) but the light coverage and accompanied references can lead to jumping off points for those who want more information. A few sections do contain essentially throw-away recommendations (such as the section on task breakdown of stories) but such sections are often in areas that real-world teams will have experience anyhow so it wasn't a big detractor for me. Lastly, if you're looking for advice on running an agile process with a distributed (off-shore) team, this book doesn't touch on any of those challenges.
As with most books on agile, this book carries on the tradition of focusing solely on the people processes without any recognition that certain *engineering* processes or practices (test-driven, continuous integration, etc) are necessary for long-term sustainability of an agile process. This is my number one complaint with all agile process books, and I've yet to find one that states, let alone defines, a certain level of software engineering organizational maturity is necessary before embarking on an agile process.
Despite these few drawbacks, this book did succeed in finally making the entire agile planning process click for me personally. After reading several of Ken Schwaber's books on the same topic I understood agile in the abstract but this book really brought it all together into a cohesive, pragmatic approach for me.
The bible of agile planning. True classic. Even if personally I don't agree with some statements, this book is a MUST read for anyone who's interesting in REAL-LIFE aspect of agile approach. This book is exactly about the actual bread and butter of agile projects in the COMMERCIAL environment - where risk and predictability have to have some harness.
For me personally it's kind of a shame that I've read it so late and who knows - maybe even I'd skip it completely, but I've decided to read it as a part of my preparation to PMI-ACP exam. I think it was a good choice.
People are, in general, bad at estimating with any definition or accuracy.
That's pretty much the core of this book; and it puts across that message quite well. It then puts forth some good ideas on how to work around this. Using the Fibonacci sequence is a stroke of brilliance and is pretty much the de-facto standard in all agile projects.
The book hasn't, however, held up well over time. It can lack coherence, and once you understand the core message, there's not much additional value in reading the whole book.
Ļoti koncentrēta informācijas ziņā grāmata. Tiek doti visi nepieciešamie pamati agile plānošanai un darbu novērtējumiem - gan kā vērtēt stāstījuma punktos vai ideālajās dienās, kā noteikt plānoto izstrādes ātrumu (velocity), kā saplānot iterāciju un relīzi. Katra nodaļa it kā būvē māju tālāk uz iepriekšējām nodaļām un dotās informācijas. Man patika, ka informācija ir skaidri izklāstīta, bez liekvārdības, bet arī ne pārāk sausi. Ļoti palīdz arī kā pēdējā nodaļa iekļautais "reālais" projekts, ar plānošanas sesijām, projekta apjoma aprakstiem, plāniem utt. Par labu grāmatai saka arī tas, ka man uzreiz gribējās pārskatīt iepriekšējā projekta gaitu (ko es arī uzsāku darīt), identificējot kļūdas (kuru bija daudz) un mēģinot atrast risinājumus, kā arī uzreiz ķerties pie jauna projekta plānošanas, iemēģinot piedāvātos risinājumus. No vienas puses žēl, ka šī grāmata neatnāca pie manis ātrāk, no otras - jau esot ar kļūdainu praksi, vieglāk saskatīt, kā ir pareizi un kā tas varētu strādāt.
Recommended book for project manager/scrum masters or whoever interested in planning and estimating. The book gives guidelines and tools that can help to succeed in planning, estimating, and scheduling projects while having high level of uncertainties in the project. Mike gives detailed examples with practical approaches and techniques to increase agility and shows how to produce software of high business value.
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.
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.
Book Review: Agile Estimating And Planning By Mike Cohn: A Must Read For All Agile Aspirants
This is an excellent book written by Mike Cohn who is the founder of Mountain Goat Software. The title of the book Agile Estimating And Planning says it all for estimating and planning of an Agile Project. It says if the planning and estimating is not done in an agile way, the agile project is not relevant to this estimating and planning. Without taking agile into account while planning and estimating of your projects, you cannot run your projects in Agile way.
Mountain Goat Software is a legendary, over 20 years old company engaged in consulting in process and project management. The company is a leading training organization for many global corporate. Mike Cohn has clientele ranging from small start-ups to a large number of top 40 Fortune companies. Mike is also a founding member of well known Agile Alliance besides being a regular contributor to a number of related magazines and a renowned speaker at a number of conferences. Mike has also written a good amount of books like User Stories Applied in 2004.
Agile Estimating and Planning talks of a number of important features like planning, estimating and scheduling thereby answering the questions like - What to plan to build and its timelines, sizing of estimations and when to do what with a quantitative answer to "How much?". The book has 7 sections and 23 chapters. At the end of each chapter you will find a well organized set of key learning points from that chapter to be imbibed in real life scenarios. The book has intelligently taken care of global companies without being focused on a specific country.
Part 1 of the book focuses on importance of planning, problems arising out of wrong planning and how to set goals in an agile atmosphere. A good plan needs to be built in a crisp manner to make is agile planning. Whereas Chapter 1 explains above, chapter 2 talks about the difference between traditional, orthodox project approach where estimating and planning go usually haywire, thus resulting in project delays or failures. In chapter 3 we learn about the meaning of agility and the broad level significance of agile estimating and planning that is further explained to micro level in further chapters.
Part 2 talks in depth about project estimation, estimation sizing and estimation duration. Story building is well explained in chapter 4 & 5. Chapter 6 deals with story points with a fantastic explanation on planning poker. Chapter 7 further focuses on alignment of story points with estimations and thus reviewing at the end of each story point so as to go for re-estimating.
Overall a must read for all agile aspirants to experts so as to gain a great deal of insight on the subject.
Excellent resource for agile project management. I'd call it a must-read for product owners and agile team managers, and I'd absolutely encourage scrum masters and development team members to read it - it could only make them better. This book has the obligatory coverage of scrum and agile basics, but differentiates itself with topics on broader and longer-term planning, like themes, milestones, and communicating schedules. I found all of this useful and plan to reread it in the future. I disagreed with a few very specific tactical recommendations in this book (scrum basics stuff), so I wouldn't recommend starting with this one alone. I still recommend starting with Essential Scrum.
Um bom guia tanto pra quem ainda não tá acostumado com o conceito ágil de desenvolvimento, como pra quem tá habituado mas sofre por não entender por que uma coisa acaba sendo feita do jeito X e não Y. Tem bastante explicação dos motivos de cada cerimônia e dos processos relacionado ao planejamento do projeto. O final tem uma narrativa fictícia de uma release sendo feita que ilustra bem a maioria dos conceitos apresentados no livro. Achei que fechou bem, reforçando e relembrando ao leitos os pontos discutidos de uma maneira mais prática.
Автор розглядає під мікроскопом всі еджайл процеси, роздумує над ідеальними днями, пунктами, годинами та іншими болями цифрового робочого життя. Дуже кумедне завершення книги, де він наводить приклад гіпотетичної компанії, що мала попередній досвід каскадної організації праці й перейшла на еджайл. Описує як в них все класно, все вдається, все всім подобається, замовники щасливі, працівники теж, така собі еджайл утопія. Якщо не враховувати цієї кумедної прикінцевої реклами методу, то кн��га дуже класна й корисна.
This book answered lots of things I've wondered about for years. The writing is a little dense at times but there's so much great info. DEFINITELY read the case study at the end. It made it all come together for me.
One of the best technical books I have read and an excellent treatise on the subject. If you work with Agile or are interested in it, I highly recommend this educational resource.
as most books on the topic, lacks on data and citations for the statements done, and is only aplicable for certain kind of companies, but completely ignores others such as software factories.
Good book that summarize the best approaches of applying estimation and planning in Agile projects. Even people with experience in project management will find it useful
This book helped me develop the mindset how to succeed in planning, estimating, and scheduling projects with a certain level of approximation. It also helped me know about the guidelines and tools that we need to succeed with limited Planning & scope Estimation that is just enough to deliver business value to the customer every Sprint.
The book emphasizes on accepting change late in the Release in Agile Manifesto and this book dwells into how to build such a mindset within a Team which I found quite enlightening and have used the knowledge gained in this book to share with Teams when we sit for Sprint Planning. especially with new Teams or members. It also underlines the value of estimating when it is needed & now rather than sitting over it for very long- which is another constituent of fail-fast approach.
The book, by providing real time examples & sharing workable solutions for Estimation & Planning software projects with some uncertainty provided me and other readers with improving my T skill set, providing with reasoning for various approaches and deepening my understanding Estimation process without diminishing any Business value. It also tackles Technical debt and introduced me to some novel of handling tech-Debts in Sprint that I use in my projects.
There is a great emphasis on making readers understand that the Estimation & Planning should be Agile & light footed as well and not just the Project that should Agile. This was a great distinction that took me some time to imbibe and I have used this insight to ensure stakeholders & Teams understand that all estimation & Planning, though essential, is only an approximation to predict future and should not be considered as written in stone even if the Team estimating it has the most stable velocity or is a seasoned Agile Feature team that always estimates correctly. Using Fibonacci hence makes sense, it being non linear sequence, in sync with risk involved in estimation especially with larger backlog Items.
“Сподівання, що менеджер продукту чи проекту зможе магічним образом передбачити можливості інших, що є експертами в своїй роботі — це самогубство для бізнесу.”
“Чому Agile-методи оцінки та планування ефективніші за традиційні методи? Бо вони зосереджені на створенні цінності й формуванні довірчих відносин між бізнесом і проектними командами. Забезпечення цілковитої прозорості та наявність постійного інформування про зміни в міру їх виникнення дозволяють бізнесу приймати найкращі рішення.”
“Без гнучкого оцінювання та планування не можуть існувати будь-які гнучкі проекти.”
“Планування — це все. Плани ніщо. Фельдмаршал Гельмут фон Мольтке”
“Оцінка та планування мають вирішальне значення для успіху проекту з розробки ПЗ будь-якого розміру або масштабу.”
“Оцінка й планування — це не лише визначення термінів або календарних графіків. Планування — і перш за все безперервний ітераційний підхід до планування — це пошук цінності. Планування - це спроба знайти оптимальне рішення загального питання розробки продукту: що ми повинні створити? Для відповіді на це питання команда аналізує функціональність, ресурси й терміни. На таке питання не можна відповісти миттєво — на нього треба відповідати ітераційно й поступово.”
“Вдалий процес планування підтримує це шляхом: 1) скорочення ризиків; 2) зменшення невизначеності; 3) підтримки ухвалення кращих рішень; 4) встановлення довіри; 5) розповсюдження інформації.”
“при визначенні Agile-планування ми виявили, що він: 1) фокусується переважно на плануванні, а не на плані; 2) заохочує зміни; приводить до складання планів, що легко змінюються; 3) розподіляє процес планування по всьому терміну виконання проекту.”
Definitely the book that I was looking for when faced with the task of how to be _agile_ in a traditional corporate setting where estimations are treated as commitments and written in contracts between businesses.
As the title suggests, this book discusses the practical and concrete steps on how to be agile when asked for estimations and how to plan around them - and more importantly, the rationale behind them. From defining an a unit of measure like a story point, which IMO is a complex concept that has been simplified too much, to abstract concepts such as ideal days and separating estimations for sizes and time.
Though of course not all practices and ideas mentioned in this book will be applicable to every organisation, this is a good place to start to get ideas on how to improve the agility of any team _(reading blogs and agile pamphlets just won't cut it_).
Rated four stars because any book or practice that wants to form the agile mind set into a framework or set of processes should always circle back to the original manifesto and principles of agile.
Overall I enjoyed reading this book. I started reading this with the need to learn estimating and planning in an organisation that wants to be agile but won't and finished it with wanting to learn everything the book has to offer even if I already left my original organisation.
Sometimes it's good to return to the classics. I often think I should have a list of books that need to be read every 5 years. This book would be on that list. For a fifteen year old book on cutting edge software development, it is remarkably current.
Many of the ideas in the book are so common in development teams that you see many different variations: some good and some to be avoided. So returning to basics is an excellent reminder of how things should work. There is much in this book to be admired: separating estimating size and duration (story points and hours), the three planing cycles (release, iteration and day) as well as useful advice on estimating with time and feature buffers.
The final chapter of the book is a fictional case study which is brings all of the ideas together. Reading the case study is like being a fly on the wall on a high-functioning Agile team.
Though the book contains some useful advice on product management, it would be a mistake to consider that Cohn describes the be all and end all of quite a complex discipline. Similarly, Cohn touches on management best practices, delegation and empowerment and makes it sound as if there is a simple set of rules to follow. Both sections do, though, serve as valuable primers.
In this book you will find two descriptions of what is pretty much the "standard" agile estimation and planning process: the first one as a set of topic-focused chapters that you can read or refer your colleagues to as independent topics; the second is as a short story in the line of The Goal or The Phoenix Project, with less detail but more hollistic.
Apart form explaining the canon, Mike Cohn is referring to the why behind some of the practices (Parkinson's Law, queuing theory, research on what type of estimation tasks are naturally easier for humans...) and adding some touches from less common sources like the feature buffer derived from the MoSCoW model and schedule buffer from Goldratt's Critical Chain.
I think it's nice read for developers and team leaders with the only cons being that you might want to change the process at your work and find yourself unable for environement causes. But that's not Mike's fault!
Clear and concise but I have to admit I did not read the last part. I have an aversion to technical writers entering the world of creative writing and therefore skipped this last section. My apologies to Mike Cohn, who may be a fine fiction writer but I could not overcome my phobia.
I found the preceding work admirable and as I have just become involved in a product development project (as nominal product owner) I hope to put what I have learned into practice and I am sure I will be revisiting the work more than once.
If you are starting on agile product development or moving from some role to agile product owner, or even scrum master, this book is for you.
If you are already an agile expert you won't find anything super relevant but it will help you a lot with different approaches about estimation and planning, iterations and releases also.
In my case I have learned several methods and approaches for estimation and planning. Also ideas about how to address technical debts during project with roughs deadlines.
Right, this is a great agile planning book full of good ideas which talks through the basics, gives strategies on prioritisation, and ideas on syncing up multiple teams. There’s even a short story at the end to illustrate some of the basics.
So why have I only given it four stars? I have to admit, compared with other agile and/or DevOps books I’ve read this one was heavy going. It took a lot of effort to reach for it towards the ends and I found myself putting it down for months in end. Maybe personal taste but probably a book I’d use for reference rather than read cover to cover...
The author walks a very thin line when comparing story points to ideal days that doesn't make much sense given the explanation he provides. Additionally there are cases where he contradicts when he says or changes his stance on something (for example going from relative to absolute value for a given metric).
Informative and useful, written from author's own experiences and opinions. The author presents all known tools/approaches, then explains which ones are appropriate in which scenario, why/how so, and his preferences if any. Having lots of author's own experiences and fictional stories makes this book easily comprehensible.
Estimation is a tricky part of Agile process, and there is much misunderstanding about it. The book goes through estimation process in details. A big lesson is focusing on implementing concepts is more important than sticking with specific practices. It concludes with a realistic study case that summarizes most of concepts.