Mike Cohn (1) (1962–)

Proven, ​100% Practical Guidance for Making Scrum and Agile Work in Any Organization.

This is the definitive, realistic, actionable guide to starting fast with Scrum and agile–and then succeeding over the long haul. Leading agile consultant and practitioner Mike Cohn presents detailed recommendations, powerful tips, and real-world case studies drawn from his unparalleled experience helping hundreds of software organizations make Scrum and agile work.

„Succeeding with Agile” is for pragmatic software professionals who want real answers to the most difficult challenges they face in implementing Scrum. Cohn covers every facet of the transition: getting started, helping individuals transition to new roles, structuring teams, scaling up, working with a distributed team, and finally, implementing effective metrics and continuous improvement.(moly.hu)… (plus d'informations)

Like many books on agile, much of this book's ideas and tips are only useful if you are using an agile process with sprints, small tasks, team sprint planning and other features of popular agile methodologies. If your team only uses some elements of agile or is using a lighter weight agile approach such as kanban, it is less useful.

Part 1: The Problem and the Goal

A good overview of the purpose of planning. I took away two points: the process of planning is more important than the plan itself, and a plan needs to be a living document if it is to remain useful throughout the project. As a consequence of these two principles, plans should not be laid out in detail from the beginning. Instead, plans should be as detailed as needed any any given time. For example, in a traditional agile flow, the next sprint will be broken down into tasks small enough to work on while future sprints may only have a rough sequencing of features planned.

Part 2: Estimating Size

Overall, I would recommend [b:Software Estimation|93891|Software Estimation Demystifying the Black Art|Steve McConnell|http://photo.goodreads.com/books/1328830202s/93891.jpg|90512] by [a:Steve McConnell|3307|Steve McConnell|http://www.goodreads.com/assets/nophoto/nophoto-M-50x66-f6689175dd57c0b1f6246d198a230cae.jpg] over this book. This section Cohn's book goes into a bit more depth on story points, ideal days, and planning poker than McConnell's book, but overall the content in Cohn's book is a subset of that in McConnell's book.

This book did give some interesting insights into re-estimating. Re-estimating has two purposes: to provide better estimates based on current data and to learn for future estimating. Inaccurate estimates and re-estimation should not be treated as failures. Individual estimates are rarely accurate, it's the aggregation that becomes more reliable. Another reason not to treat re-estimation as failure is that it discourages honest estimation in the future. Given these two purposes of re-estimation, it's rarely worth tracking how well individual estimates matched actual work done.

Part 3: Planning for Value

This part of the book covers figuring out what to do. The chapters on prioritization were useful. Since I am not in an environment where I have to directly worry about financial prioritization, I found most useful the discussion of estimating based on desirability.

In addition to the common knowledge that priority should depend on the "ratio" of desirability to effort, the book discusses how to assess desirability. ("Ratio" is in quotes since desirability is even harder to quantify than effort.) My key takeaway was that to decide how important something is, we should ask two questions: "how happy would you be with this feature?" and "how unhappy would you be without this feature?"

It might seem like these two questions would yield inverse answers, but consider a feature like saving in a text editor: if you just asked people how happy it would make them, it would likely get a middling score, but people would be very unhappy if their editor couldn't save. These are the features that are taken for granted, the things which would be deal breakers if you didn't add them. By only asking the first question, these features might be missed.

Part 4: Scheduling

Not particularly useful if you don't use an iteration based agile process.

Part 5: Tracking and Communicating

Also not so useful if you don't use an iteration based agile process.

Part 6: Why Agile Planning Works

A good summary of the book. Many of the highlights of the book can be gleaned from this one chapter section.

Part 7: A Case Study

Brought everything together nicely. It doesn't show how to deal with things going wrong, but since the purpose was to demonstrate the ideas to reinforce them, that is reasonable.… (plus d'informations)

This short book promises to explain what User Stories are, what they aren't, how to create and utilize them within an Agile/XP approach, and finally how to bring everything together in a short, yet relatively realistic case study. It delivers exactly what it promises and the exercises at the end of the chapters, although not always very well crafted, help the reader to capture the essence of each chapter, as well as focus on the pitfalls. It is not repetitive and does not try to be everything for every type of software developer, and that I consider another positive point.

No matter what methodology you use, software development is a challenging task, and even if your favorite method is Agile or a variation of it, you'll need hard earned experience and probably more than just one book, but if I had to recommend only one introductory book to someone who wants to get the essence of creating User Stories to capture most of the aspects of end user software, then this book would be it.… (plus d'informations)