Book Notes: Agile Estimating and Planning - Mike Cohn

William Meller - Agile Estimating and Planning - Mike Cohn
Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects with the philosophy of agile that shows you exactly how to get the job done.


Title: Agile Estimating and Planning
Author: Mike Cohn
Themes: Agile, Career, Cases, Technology, Management, Business
Year: 2005
Publisher: Pearson Education
ISBN: 0132703106, 9780132703109
Pages: 368

Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects. 

In this book, Agile Alliance cofounder Mike Cohn discusses the philosophy of agile estimating and planning and shows you exactly how to get the job done, with real-world examples and case studies.

Concepts are clearly illustrated and readers are guided, step by step, toward how to answer the following questions: What will we build? How big will it be? When must it be done? How much can I really complete by then? You will first learn what makes a good plan and then what makes it agile.

"... A good plan is one that stakeholders find sufficiently reliable that they can use it as the basis for making decisions. Early in a project, this may mean that the plan says that the product can be released in the third quarter, rather than the second, and that it will contain approximately a described set of features. Later in the project, in order to remain useful for decision making, this plan will need to be more precise..."

Mike Cohn tries to answer questions like why conventional prescriptive planning fails and why agile planning works? How to estimate feature size using story points and ideal days–and when to use each? How and when to re-estimate? How do prioritize features using both financial and nonfinancial approaches? How do split large features into smaller, more manageable ones? How to plan iterations and predict your team's initial rate of progress? How do schedule projects that have unusually high uncertainty or schedule-related risk? How to estimate projects that will be worked on by multiple teams?

William Meller - Agile Estimating and Planning - Mike Cohn

Agile Estimating and Planning supports any agile or iterative process, including Scrum, XP, Feature-Driven Development, Crystal, Adaptive Software Development, DSDM, Unified Process, and many more. 

An estimate is not the same as a commitment. The aim of an estimate is to be as useful and accurate as possible. This means that padding or being optimistic about estimates is counterproductive.

William Meller - Agile Estimating and Planning - Mike Cohn

A key concern in agile estimation is to separate the estimation of size and the measuring of velocity. In separating these concerns, you can achieve an unbiased view of the size of a project and afterward assess the ability to achieve commitments or a schedule.

"... Agile planning is focused more on the planning than on the creation of a plan, encourages change, results in plans that are easily changed, and is spread throughout the project..."

"... Agile teams use three levels of planning: release planning, iteration planning, and daily planning. The release plan looks ahead for the duration of the release, typically three to six months. An iteration plan looks ahead only the duration of one iteration, typically one to four weeks. A daily plan is the result of team member commitments made to each other usually during a daily standup meeting..."

"... The beauty of this is that estimating in story points completely separates the estimation of effort from the estimation of duration. Of course effort and schedule are related, but separating them allows each to be estimated independently. In fact you are no longer even estimating the duration of a project; you are computing it or deriving it. The distinction is subtle but important..."

"... Story points are purely an estimate of the size of the work to be performed. The duration of a project is not estimated as much as it is derived by taking the total number of story points and dividing it by the velocity of the team..."

"... To arrive at an estimate we rely on expert opinion, analogy, and disaggregation. A fun and effective way for combining these is planning poker. In planning poker, each estimator is given a deck of cards with a valid estimate shown oneach. A feature is discussed and each estimator selects the card that represents his or her estimate. All cards are shown at the same time. The estimates are discussed and the process repeated until agreement on the estimate is reached..."

"... There are three ways of estimating velocity. First, you can use historical averages if you have them. However, before using historical averages, you should consider whether there have been signficant changes in the team, the nature of the project, the technology, and so on. Second, you can defer estimating velocity until you’ve run a few iterations. This is usually the best option. Third, you can forecast velocity by breaking a few stories into tasks and seeing how much will fit into an iteration. This process is very similar to iteration planning..."

This book is organized into seven parts and twenty-three chapters.

Chapters of the Book:

Part I: The Problem and the Goal

1. The Purpose of Planning

2. Why Planning Fails

3. An Agile Approach

Part II: Estimating Size

4. Estimating Size with Story Points

5. Estimating in Ideal Days

6. Techniques for Estimating

7. Re-Estimating

8. Choosing Between Story Points and Ideal Days

Part III: Planning for Value

9. Prioritizing Themes

10. Financial Prioritization

11. Prioritizing Desirability

12. Splitting User Stories

Part IV: Planning for Value

13. Release Planning Essentials

14. Iteration Planning

15. Selecting an Iteration Length

16. Estimating Velocity

17. Buffering Plans for Uncertainty

18. Planning the Multiple-Team Project

Part V: Tracking and Communicating

19. Monitoring the Release Plan

20. Monitoring the Iteration Plan

21. Communicating About Plans

Part VI: Why Agile Planning Works

22. Why Agile Planning Works

23. A Case Study: Bomb Shelter Studios

Mike Cohn is one of the contributors to the Scrum software development method. He is one of the founders of the Scrum Alliance.

Thank you for reading another article here! I hope you enjoyed it!

Here are some related articles you may enjoy:

There are even more good things I've prepared for you!

Subscribe below or click here to receive new posts in your Email!

Do you want to read some book notes and recommendations? Discover more here!

Do you want to have amazing weekly content curation? Discover more here!

Follow me on LinkedIn - Twitter - Instagram

You can support me in many ways. One is to share the content with others so that more people can read it. 

If you want to support my work and perhaps give me a bit more energy for the next article, you can also buy me a coffee:

William Meller - Subscribe

No comments:

Post a Comment