Release year: 2005

Author: Mike Cohn

Link to my handwritten notes

Buy this book

Review

I have been working under the agile method since 2017. It’s a “simple” framework that allows teams to ship better products more quickly. I was curious to go back to the book from which the method seems to have originated. In 2005, Agile Estimating & Planning was the book about how to “do agile” in your organization.

I was already familiar with a lot of the terms coined in this book, as I am sure most of you are too: tasks, stories, velocity, iterations, retrospectives, etc. I didn’t find much that surprised me here. However, I was impressed at the depth in which the author discussed how to be agile in terms of agile project management. Mike Cohn is clearly a master at his craft.

The last chapter was a pleasant surprise. It is a case study of a fictional team using the agile framework to develop their new video game (Havannah , an interesting concept!). It is their first agile project. For instance, their previous release (Go ) was done using the old waterfall methods. We follow them in their discussions from writing their first stories all the way to completion. Consider this chapter the equivalent of what The Phoenix Project is in relation to The DevOps Handbook . It is a fable that shows characters using all the concepts “in real life.” Kudos to the author!

Unfortunately, I think the book is starting to show its age. Agile Estimating & Planning will always remain a very important book, as it is part of the foundational work that made the Agile movement into what it is today. It is also very hands-on, practical. You will be able to follow it. Alas, some of the ways of working are almost 20 years old at this point, and feel a little old-school. The notion of “story” and “task” has been abused to death in the real world, for example. The fact that I am tempted to give this read a thumbs down is through no faults of the book, as I’m sure it was a revelation to Product Owners everywhere when it originally released in 2005. However, nowadays, I would be more inclined to recommend books like Project to Product and Shape Up that bring in fresh new ideas you are likely not to have yet heard about. I feel like too much has been said about Agile at this point and that it’s time to start using new terms to describe our work.

And yet, despite its age, I feel like there is still enough useful knowledge in this book to recommend it. Just remember that agile is not the end of the story (!) when it comes to project management.

Félix rating:
👍

⭐ Star quotes

1. (p. xxii) There are two types of uncertainty:
   • Ends uncertainty: What do we really want to build?
   • Means uncertainty: How are we going to build it?
2. (p. xxii) For most uncertainties (lack of knowledge) the only way to reduce the uncertainty and earn knowledge is to execute (do something, build something, simulate something) and then get feedback
3. (p. xxv) ⭐ Giving a product or project manager sage-like qualities to be able to foresee what others, who are experts in their own work, can really deliver is business suicide. This approach is really a way of saying yes to the business when asked to deliver on unrealistic goals.
4. (p. xxix) Planning is answering the question of “What should we build and by when?”
5. (p. xxix) To answer questions about planning we must also address questions of estimating (“How big is this?”) and scheduling (“When will this be done?” and “How much can I have by then?”)
6. (p. 4) During the feasibility phase of a project a schedule estimate is typically as far off as 60% to 160%. After the requirements are written, the estimate might still be off ±15%.
7. (p. 6) The most critical risk facing most projects is the risk of developing the wrong product.
8. (p. 6) A failed project is often one where no one came up with any better ideas than what was on the initial list of requirements.
9. (p. 8) Far too often a plan is reduced to a single date, and all of the assumptions and expectations that led to that date are forgotten.
10. (p. 8) A good plan is one that stakeholders find sufficiently reliable that they can use it as the basis for making decisions.
11. (p. 9) Plans are documents or figures; they are snapshots of how we believe a project might unfold over an uncertain future. Planning is an activity. Agile planning shifts the emphasis from the plan to the planning.
12. (p. 9) Just because we’re changing the plan does not mean we change the dates. We can:
    • drop a feature
    • reduce the scope of a feature
    • add people to the project
13. (p. 12) Customers get no value from the completion of activities. Features are the unit of customer value.
14. (p. 12) Activity-based planning (as opposed to delivery-based planning) leads to schedule overruns because:
    • activities don’t finish early
    • lateness is passed down the schedule
    • activities are not independent
15. (p. 12) Parkinson’s Law: Work expands so as to fill the time available for its completion (i.e. we take as much time to complete an activity as we think we’ll be allowed).
16. (p. 17) When features are not developed by priority, the team scrambles to meet the schedule by dropping features. Because there was no attempt to work on features by order of priority, some of the features dropped are of greater value than those that are delivered.
17. (p. 17) ⭐ The best way of dealing with uncertainty is to iterate.
18. (p. 18) ⭐ An estimate is a probability.
19. (p. 21) The Four Value Statements of the Agile Manifesto:
    • Individuals and interactions > Processes and tools
    • Working software > Comprehensive documentation
    • Customer collaboration > Contract negotiation
    • Responding to change > Following a plan
20. (p. 21) A well-functioning team of great individuals with mediocre tools will always outperform a dysfunctional team of mediocre individuals with great tools and processes.
21. (p. 23) Critical to the success of a project is that all project participants view themselves as one team aimed at a common goal.
22. (p. 25) For the product owner to have the most flexibility in prioritizing, features must be written so as to minimize the technical dependencies among them.
23. (p. 27)
    • Traditional view of a project: running a 10 km race. You know how far the finish line is, your goal is to reach as quickly as possible.
    • An agile project is to run as far as possible in 60 minutes. The team knows when they will finish, but not what they will deliver.
24. (p. 28) The planning onion:
    • Strategy
      • Portfolio
        • Product
          • Release (this is where the horizon of the agile team begins)
            • Iteration
              • Day
25. (p. 45) Managers are able to work an average of only 5 minutes between interruptions.
26. (p. 61) We should re-estimate size only when we believe a story’s relative size has changed.
27. (p. 67) ⭐ Failure to learn is the only true failure.
28. (p. 69) If you tell people where to go, but not how to get there, you’ll be amazed at the results.
29. (p. 70) An estimate expressed in story points has a longer shelf life than an estimate in ideal days, because ideal days can change based on the team’s experience.
30. (p. 81) The best way to reduce the cost of change is to implement a feature as late as possible.
31. (p. 82) The flip side of acquiring knowledge is reducing uncertainty.
32. (p. 85) Prioritization of features:
    1. The high-value, high-risk features should be developed first. These features deliver the most value, and working on them eliminates significant risks
    2. Next are high-value, low-risk features. Since they are less risky, they can be done later in the schedule.
    3. Finally, do low-value, low-risk features. They will have less impact on the total value of the product if they are dropped.
    4. ❌ Skip low-value, high-risk features completely.
33. (p. 95) The drive to improve operational efficiencies often comes from anticipated growth.
34. (p. 123) Typical ways to split a story:
    • along the boundaries of the data supported by the story
    • along the boundaries of the common CRUD operations
      • create
      • read
      • update
      • delete
    • along priorities, if the smaller stories have different priorities
35. (p. 126) ⭐ Make it work, then make it faster.
36. (p. 128) Delivering a cohesive subset of all layers of a feature is almost always better than delivering all of one layer.
37. (p. 134) During release planning, don’t plan which dev will work on which user stories or tasks, or the sequence in which the work will be performed. These details are best left to the individuals working on those tasks and best deferred as long as possible.
38. (p. 134) Items in a release plan are user stories, which are descriptions of the functionality to be delivered, not individual engineering tasks to be performed.
39. (p. 137) A good PO will accept ultimate responsibility for prioritizing but will listen to advice from the development team, especially about sequencing.
40. (p. 150) ⭐ The Iteration Review Meeting is held after an iteration is finished. New functionalities and capabilities added during the iteration are demonstrated to the people below. They may be seeing the results of the iteration for the first time. They will often have good new ideas that could preempt previously high-priority items:
    • stakeholders
    • the extended project community
    • anyone else interested
41. (p. 151) An iteration review will typically take 30 to 60 minutes.
42. (p. 152) The iteration goal is a unifying statement about what will be accomplished during the iteration. It does not have to be very specific, e.g. “Make progress on reports.”
43. (p. 153) The goal of each iteration is to:
    • produce a potentially shippable product
    • take care to include tasks for testing
    • documenting the product
44. (p. 169) It is important that the product owner not change priorities during the iteration and that she help protect the team from others who may attempt to change priorities. The length of time that priorities can go unchanged is a factor in selecting the iteration length.
45. (p. 169) ⭐ The time from “new idea” to “working software” will be an average of 1.5 x the length of the team’s iteration.
46. (p. 177) Questions to ask to know if you can trust historical velocity:
    • Is the technology the same?
    • Is the domain the same?
    • Is the team the same?
    • Is the PO the same?
    • Are the tools the same?
    • Is the working environment the same?
    • Were the estimates made by the same people?
47. (p. 177) ⭐ The cone of uncertainty says the actual duration of a project will be between 60% and 160% of our prediction. To multiply a single-point average velocity into a range, divide it by 0.6 and 1.6.
48. (p. 182) Individuals spend 55% to 70% of their time on project activities.
    • A large bureaucracy will be at the low end
    • A start-up will be at the high end
49. (p. 183) Plan on completing ten pomodori (5 hours) per day.
50. (p. 183) Select stories until one skill set on the team can’t handle any more work. Add up the story points or ideal days for the work selected and that is the team’s possible velocity.
51. (p. 187) ⭐ To be uncertain is to be uncomfortable, but to be certain is to be ridiculous.
52. (p. 189) Dynamic Systems Development Method: Requirements are sorted into 4 categories (below). No more than 70% of the planned effort for a project can be targeted at Must Have requirements.
    • Must Have
    • Should Have
    • Could Have
    • Won’t Have
53. (p. 217) “Complete” means code that is:
    • well written
    • well factored
    • checked in
    • clean
    • complies with coding standards
    • passes all tests
54. (p. 231) ⭐ On a project, it is far more useful to know how much remains to be done rather than how much has been done.
55. (p. 232) Do not track individual velocity. Measuring individual velocity gives the incentive of finishing one’s own work over helping someone else. Individuals should be given every incentive possible to work as a team.
56. (p. 232) Most user stories should be written such that they need to be worked on by more than one person.
57. (p. 235) ⭐ The more elaborate our means of communication, the less we communicate.
58. (p. 235) Frequent communication about plans is important because of how often an agile plan is updated.
59. (p. 241) End of iteration summary
60. (p. 253) Eliminate all WIP at the start of each iteration. Work on a feature not fully implemented in one iteration will not necessarily be continued in the next (often will be, but no guarantee). Each iteration is planned afresh253) Eliminate all WIP at the start of each iteration. Work on a feature not fully implemented in one iteration will not necessarily be continued in the next (often will be, but no guarantee). Each iteration is planned afresh.
61. (p. 254)
    • End uncertainty (about the product ultimately being built) is reduced as product increments are shown to potential users and other stakeholders at the end of each iteration.
    • Means uncertainty (about how the product will be built) is reduced as the team learns more about the technologies in use and themselves.
62. (p. 254) ⭐ The more responsibilities are shared by the team, the more success the team will have to share.
63. (p. 254) Keep estimates of size and duration separate by using different units.
64. (p. 254) Estimating size in story points and translating size into duration using velocity is an excellent way of doing this.
65. (p. 254) Be sure to include an expression of uncertainty (either the functionality or the date) in any release plan you produce.
66. (p. 255) Take advantage of the start of each new iteration to assess the relevancy of the current release plan.
67. (p. 288) Note who is planning to be gone during the iteration, and for how many days.