Agile Estimating and Planning

At last, a pragmatic and insightful book on Agile Planning

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.

Very good and comprehensive book to learn in depth on Agile Estimation and planning

The book is exceptionally well written. People have said that a book about anything 'Agile' should be thin - well this one is - There are about 24 chapters and each one is no more than easily digestible 20-30 pages for a quick 'agile' read. However, that does make it about 300 pages of content. But here are the 'Great' things about the book: - Well written and a light read with real pearls of wisdom - Well explained concepts with examples - Good primer on Estimation - separating 'duration' from the size and showing how/why it really matters in the long run (of the project) - Explaining when to estimate and a good 'tutorial' on planning poker and Kano Analysis for prioritizing features/desirability. - Throws light on the 'Financial Prioritization' - rubbishing the claim that features in agile teams are prioritized as per the whims and fancies of the developers. - Break downs about planning at multiple levels and what details go in them - Monitoring and communicating plans - the 'how' and 'what' to do I keep referring to the book - because it's really NOT about planning & estimating 'agile projects' - it's about how to be agile with the planning/estimating activity itself. You could use a lot of ideas (especially Kano Analysis, Planning Poker etc.,) and augment it with the approach in your organization (or your own planning exercise) to help communicate the plans/ideas more effectively. Do keep in mind, however - this is NOT a silver bullet that'd end the planning woes encountered in today's software development projects. The case study in the end is too idealistic where everybody is just 'willing' to participate and do it perfectly in lock step synchrony! (It's really difficult to find such software developers in the real world). However, the intent of the case study is to elucidate the concepts covered in the book and hence is a good summary of the ideas presented. There is nothing in the book that says what to do if the client doesn't know what he/she wants? IKIWISI = I'll know it when I'll see it - It doesn't cover anything about prototyping to get the requirements/user stories - it probably assumes that you can get them elicited with ease and moves on from there. In my opinion/experience there is a great deal of concurrency/backtracking with the initial prototyping and eliciting the user stories - an iterative exercise. Once you do those you are probably a bit better off with being able to 'guestimate' the story points. Kano Analysis has known to be around for quite a while and I was aware of it's use in KJ analysis (VOC+ KJ + Kano + Conjoint analysis that is part of the 6-sigma process) - however, it was a refreshing thought to be useful for just about every software product and it could be done without much overhead (actually the overhead is there, however, if the planning is done as a team, it'd be lighter :) Creating the questionnaire for Kano analysis itself takes some time/effort - but is easier once the stories are there. But 'shortening' it to be an 'agile' questionnaire DOES take time/effort. More so based on the feedback you get you may want to update it! But it's worth knowing and probably considering during the planning and user-story elicitation - just before prioritizing! All in all a great read with REAL practical and workable advice/knowledge!

Ottimo libro da leggere una volta che si è provato un processo Agile, per avere piena comprensione del perché si fanno certe cose e come andrebbero fatte.