Summary

This book is often considered to be *the* book on Agile.  I have always had the opinion that this book is appealing to those that want to manage Agile development versus those that want to do Agile well.  As I read, I am constantly amazed at how well written the book is.  There are so many genuine insights in the beginning of the book.  However as the book progresses, it does not provide insights, but goes into very short chapters on individual topics.  Many of these topics have become books with more relevant information or additional insights, so as the book progressed, I found fewer and fewer insights.  The estimating and scheduling techniques that are presented in the heart of the book are well beyond what I have seen most teams do, but are very well explained and defended.  There are some thoughts and ideas that I see presented here that I don’t see in subsequent literature.  Seems odd that things like a feature breakdown schedule and an end of iteration report are not found is later discussions.  I like them and I see a lot of applicability to the government.

Top 3 Things I learned

• When initially estimating a velocity, do it as a range based on factors that come from the cone of uncertainty.  Initially multiple estimate by 0.6 and 1.6, then 0.8 and 1.25 after one iteration, then 0.85 and 1.15 after 2 iterations, then finally 0.9 to 1.1
• Burndown Bar chart.  This chart uses velocity as the size of the bar.  You can infer quite a lot of detail, detail that is only possible if you use both a burnup and a burndown chart together.
• Feature breakdown chart instead of a work breakdown chart.  Looks like a GANTT chart, but feature driven.  The features always span the length of the iteration because the software is not available until then.  Do not assign resources unless you are using multiple teams and then you just give it a team name.
• Okay, I’m cheating by noting a fourth item. Look at the self-assessment in the chapter before the case study.

---

Notes: Chapter 1: The Purpose of Planning

SUMMARY: An introduction to why we plan.  Makes the argument that the purpose of planning is to arrive iteratively at an optimized answer to the ultimate new product development question of what should be developed

QUOTE: Planning is everything, plans are worthless

TERM: Cone of Uncertainty

Why Plan

1. Reduce Risk: Provide insights
2. Reduce Uncertainty: On time, on budget, w/initial requirements misses the reality that you probably got something wrong in the initial req.
3. Support Better Decision Making: How know what to do if you don’t know cost and value?
4. Establish Trust: Reliable estimates drive reliable delivery
5. Convey Information: Work completed, Key assumptions, agree on measure progress

What makes a good plan? Sufficiently reliable to be the basis for decisions

What makes a plan Agile? Plans are documents, planning is an activity.

Agile Planning:

• Focus is on Planning, Off plan
• Encourages change (I would say “enables” or “supports”)
• Results in plans that are easily changed
• Is spread across the project

---

Notes: Chapter 2: Why Planning Fails

SUMMARY: Activity planning fails, feature planning focuses on value to the customer

QUOTE: No plan survives contact with the enemy

Why Planning Fails

1. Planning is an activity not a feature: need to be feature focused not activity focused
   1. Activities do not finish early: work expands
   2. Lateness is passed down: everything early to start a dependent task early; 1 slip and everything later, late
   3. Activities are not independent: Increased UI time means all is more complex
2. Multitasking causes delays through inefficiency
3. Features are not developed by Priority: Assumption is all gets done, so order is not important
4. Ignores uncertainty

Final Point: Estimates are not commitments. <– SO TRUE

---

Notes: Chapter 3: An Agile Approach

SUMMARY: Unlike other chapters this chapter does not provide new insights, it is more of “Just Do It”

QUOTE: A good plan violently executed now is better than a perfect plan executed next week.

Agile Approach to Planning:

1. Work as one team, integrated from Product Owner through everyone else
2. Work in short iteration: have value, usually 2-4 weeks
3. Deliver something each iteration: potentially shippable
4. Focus on business priorities
5. Inspect and adapt

Introduces the “Conditions of Satisfaction” which is like a “Definition of Done”.  Doesn’t go into much detail.

---

Notes: Chapter 4: Estimating Size with Story Points

SUMMARY: Introduces two terms and on concept.  Very short chapter.

TERM: Story Point: Relative measure of the size of a user story

TERM: Velocity: Team’s rate of progress per iteration

CONCEPT: Story Points are an estimation of size, duration is derived.

---

Notes: Chapter 5: Estimating in Ideal Days

SUMMARY: Another very short chapter with a few concepts about ideal days.

CONCEPT: Ideal time (do nothing else, 4 quarters of football) vs Elapsed time (everything else included, include commercial time)

CONCEPT: One estimate, not many – don’t breakout by skill set if at all possible.

---

Notes: Chapter 6: Techniques for Estimating

SUMMARY: This chapter is all a lead-in to planning poker, the motivation for it, why it works, and how to do it.

QUOTE: Prediction is very difficult, especially about the future.

CONCEPTS:

1. Accuracy never reaches 100%, rises quickly, then actually goes down as there are further inputs
2. Estimates are shared, though they would be better by the person doing the tasks, but that doesn’t work for Agile
3. Use a scale of numbers with gaps
4. Deriving an estimate
   1. Seek an expert opinion
   2. analogy
   3. Disaggregation: split into smaller chunks
5. Planning Poker
   1. Prep (stories, cards)
   2. Read (product owner or analyst)
   3. Vote
   4. Discuss/Re-vote

ANALOGY: If you are golfing and make an estimate of 3 to 8 shots per hole, you get a score of 54 to 144, but you will never shoot that good or that bad.  Therefore a better estimate is one that says 80 to 110.

---

Notes: Chapter 7: Re-Estimating

SUMMARY: Lots of words to say only re-estimate when the size of a story changes

QUOTE: There is no sense in being precise when you don’t even know what you’re talking about.

---

Notes: Chapter 8: Choosing between Story Points and Ideal Days

SUMMARY: Discussion of pros and cons of Story Points and Ideal Days

CONCEPTS:

1. Story Point advantages
   1. Promotes cross-functionality
   2. Do not decay, as you get better, size goes down
   3. Pure measure of size
   4. Typically faster to get an estimate
   5. Comparing ideal day size can be difficult because of differing abilities
2. Ideal Days
   1. Easier to explain outside of the team
   2. Easier to estimate at first

THOUGHT: Start new teams on ideal days and quickly shift to story points

---

Notes: Chapter 9: Prioritizing Themes

SUMMARY: Establishes and discusses four factors to consider when prioritizing themes.  In my take, more quesiotn are left unanswered then answered when combing the four factors.

4 Features

1. Value: Difficult to calculate on a theme basis
2. Cost: Can vary depending on when in the order it is done
3. New Knowledge: Learning about product (Business), Learning about project (Technical)
4. Risk: Best when combined with value

TECHNIQUE: Risk Value Matrix (2×2)

---

Notes: Chapter 10: Financial Prioritization

SUMMARY: A departure from earlier, easer to read topics, this one uses actual math.  Introduces terems and concept to perform prioritization based on dollars.  Lists terms, pros and cons.

4 Types of Revenue

1. New: New customers attracted by feature
2. Incremental: existing customers who will upgrade
3. Retained: Keep existing cust. from leaving
4. Operation Efficiency: Key with growth, replace older processes

TERM: Present Value: Value of money now

TERM: Discounting: Moving future amounts back to present value

TERM: Opportunity Cost: Rate at which discounting future money

TERM: Net Cash Flow: Cost-Revenue

CONCEPTS:

1. Net Present Value:
   1. DEFINED: Present Value over time
   2. PROS: Easy to calculate
   3. CONS: Weak when revenue streams are different
2. Internal Rate of Return
   1. DEFINED: How quickly a project will increase in value
   2. PROS:
      1. Compare two projects
      2. Don’t have to estimate a discount
   3. CONS:
      1. Does not give you an absolute money
      2. Does have preconditions
3. Payback Period
   1. DEFINED: Amount of time required to earn back investment
   2. PROS:
      1. Simple calculation
      2. Measure financial risk
   3. CONS:
      1. Does not account for time value of money
   4. NOTE: If you apply Discount, then the con goes away

---

Notes: Chapter 11: Prioritizing Desirability

SUMMARY: Presents two different ways to prioritize based on desirability: Kano’s 3 factor method and Weiger’s relative weighting.

CONCEPT: Kano’s method

1. 3 factors
   1. Threshold: must-have  -> never achieves neutral customer satisfaction
   2. Performance/Linear: linear increase in satisfaction the more we have the feature
   3. Exciters and Delighters
2. NOTE: See chart for the cross-reference for Functional and Dysfunctional rating results

CONCEPT: Weiger’s Relative Weighting

1. Relative rating for having and not having the feature
2. Combine for Total Value
3. Get Value %
4. Estimate the number of story points
5. Determine Cost
6. Calculate priority

---

Notes: Chapter 12: Splitting User Stories

SUMMARY: Some predefined rules on splitting stories

Why Split?

1. Too large to fit into an iteration
2. Fits, but not enough room in the iteration for everything

How to split:

1. Split across data boundaries, logical groupings — logical entities
2. Split across functional
3. Split across CRUD
4. Remove cross-cutting features and make 2 versions of the story
5. Functional, then non-functional (make it run, then make it run fast)
6. Split if there are different priorities
7. Don’t split into tasks
8. Don’t add related unless they have the same priority.

---

Notes: Chapter 13: Release Planning Essentials

SUMMARY: There is not much in this chapter.   It defines a process for release planning, expands on the parts and gives an example.  Doesn’t account for many things I have seen written in other books like the Inception Deck or perhaps that is considered “Project Planning”.

TERM: Release Planning: Process of creating a plan that covers a period longer than an iteration.

CONCEPTS:

1. Conditions of Satisfaction
2. Estimate the user stories
3. Then in any order
   1. Select an iteration length
   2. Estimate velocity
   3. Prioritize user stories
4. Select stories and a release date

---

Notes: Chapter 14: Iteration Planning

SUMMARY: Much more detail than release planning.  Key to iteration planning is tasks.

CONCEPT: Strong preference to cards and other non-tool techniques

CONCEPT: Release vs. Iteration Planning

1. Horizon: 3-6 month / 1-4 Weeks
2. Focus: User Stories / Tasks
3. Measured In: Story Points or Ideal Days / Ideal Hours

CONCEPT: Flow of velocity-driven approach

1. Do in any order
   1. Adjust Priorities
   2. Determine Velocities
2. Set iteration goal
3. Develop all user stories
4. Develop all tasks
5. Estimate all task

CONCEPT: Commitment-driven approach

1. Adjust Priorities
2. Set iteration goal
3. Iterate over User Stories
   1. Select User Story
   2. Develop Tasks
   3. Estimate Tasks
4. Ask yourself if you can commit
   1. If no, remove User Story and try again
   2. If yes, done

CONCEPT: Task size 1 day

TERM: Iteration Goal: Unifying statement on what we will accomplish during the iteration

TERM: SPIKE: Task to gain knowledge or answer a question

---

Notes: Chapter 15: Selecting an Iteration Length

SUMMARY:  A good chapter about what is a simple topic.  Lists factors and explains how.  Gives 2 examples.

RECOMMENDATION: 2-4 weeks with 2 usually being the best.  One amps the pressure up too much and four is not enough pressure.

CONCEPT: Factors affecting an iteration length.

1. Overall length of the release
   1. Want 4-5 minimum iterations
   2. 1 month ~ 1 week iterations
2. Amount of uncertainty.  If uncertainty large, need to decrease iteration length.
3. Ease of getting feedback
4. How long priorities remain unchanged
5. Willingness to go without outside feedback
6. Overhead of iteration
7. How soon urgency is felt

---

Notes: Chapter 16: Estimating Velocity

SUMMARY: Introduces three wasys to estimate velocity and gives an example application of those ways

CONCEPT: Three ways to estimate:

1. Historical Values
   1. Factors can change
   2. Only work if you have them
   3. Use a range
2. Run an iteration
   1. Observed velocity
3. Forecast
   1. Rarely your goto option

CONCEPT: Ranges based on iterations

1. 1: 0.6 – 1.6
2. 2: 0.8 – 1.25
3. 3: 0.85 – 1.15
4. 4+: 0.9 – 1.1

CONCEPT: Pomodoro technique

1. 25 min work, 5 min break
2. Repeat for up to 5 hours
3. Only super efficient Toyota could reach 80% efficiency

---

Notes: Chapter 17: Buffering Plans for Uncertainty

SUMMARY: Discusses 2 types of buffers, schedule and feature

CONCEPT: Feature Buffer: must have (not greater than 75%) and optional (not less than 25%)

CONCEPT: 

• M ust have (75%)
• o
• S hould have
• C ould have
• o
• W ont have

TERM: DSDM: Dynamic System Development Model

CONCEPT: Schedule buffer: add a block of time to the end

2 ways to develop a buffer

1. Square root of sum of squares.  2d = sqrt [ (wi – ai)2 + …] where wi is the worst (90%) and ai is the average (50%)
2. 50% – Sum average values (50%), divide by 2

---

Notes: Chapter 18: Planning the Multiple-Team Project

SUMMARY: Some cursory thoughts on what you need to do if you have a large team.  Not much detail or thought is given on a complex and challenging topic.

CONCEPTS:

1. Establish a common baseline
2. Add detail to user stories soon
3. Perform lookahead planning
4. Incorporate feeding buffers

---

Notes: Chapter 19: Monitoring the Release Plan

SUMMARY: No great insights or revelations.  Basically explains a Release Burndown chart and some alternatives.

3 ways:

1. Release Burndown
2. Release Burndown Bar (show velocity in the bar, you get the benefits of both a burndown and burnup)
3. Parking lot chart (do a progress bar for completion of themes)

---

Notes: Chapter 20: Monitoring the Iteration Plan

SUMMARY: A very short chapter that basically walks through a version of a storyboard

---

Notes: Chapter 21: Communicating about Plans

SUMMARY: Title and content did not add up much.  Introduces 2 concepts that I liked, feature breakdown chart and an end of iteration report.

CONCEPT: Feature Breakdown Schedule

• Similar to WBS but Feature Based
• All stories go to the end of the iteration because that is when they are available.
• No resource name except with multiple teams, then use team names

CONCEPT: End of iteration report Report

1. Context
   1. Start Date
   2. End Date
   3. # of Working Days
2. Personnel Table
   1. Name | # Days Planned | # Days Actual
   2. Sum
3. Metrics
   1. Build results table
      1. Date | Results
   2. Iteration Burndown
   3. Velocity
4. Contents table
   1. Story | Result | Points Planned | Points Earned
5. Iteration Review table
   1. Action Item | Responsible Part

---

Notes: Chapter 22: Why Agile Planning Works

SUMMARY: A wrap up chapter.  I found the guidelines to be a great self-assessment tool

1. Team Planning
   1. List # of people on the team
   2. List # of people planning
2. Planning at multiple levels
   1. Presence of a Release Plan
   2. Presence of an Iteration Plan
3. Separate size and duration
   1. Show unit of size
   2. Show unit of duration
4. Account for uncertainty
   1. Show how uncertainty is handled
5. Replanning
   1. List replanning dates
   2. Show versions of release planning
6. Show progress
   1. Where are the progress indicators
7. Impact of Learning
   1. Show what was added or changed based on knowledge gained
8. Right Size
   1. List user stories
   2. ID what was changed from the beginning
9. Prioritize Features
   1. Show method
   2. Show evidence it has been applied
10. Impact of Reality
    1. List observed facts
    2. Show impact
11. Leave some slack
    1. Show buffer and how it is calculated
12. Use of Lookahead planning
    1. When using multiple teams, show use of Lookahead

---

Notes: Chapter 23: A Case Study: Bomb Shelter Studios

SUMMARY: A case study.  I only glanced through this section.