Beck K., Planning Extreme Programming (2001)

The book on XP planning covers most of what today Agile is in a nutshell. It is a great practical review of Agile Software Engineering implementation.

Summary

The book is exceptionally short ¹ compared to majority of the SWE ² books.

To my view it (with its predecessor - XP) just saves you time making practically redundant the Agile waterfall (pun intended) of information that followed since then.

It is about planning software project done with XP ³. The authors target project managers, programmers and customers playing part in product and project planning. The planning in the book expects the product requirements to change as the product is developed. Hence the plans have to be iteratively revised based on the product knowledge evolved to date.

(p. 8) XP is an iterative development technique. It breaks the long-term projects into a sequence of self-contained, one- to three-week mini-projects. In each of those:

• Customers pick the features;
• Programmers implement the features;
• Programmers and customers implement automated tests to demonstrate the presence of these features;

The careful planning is in place to:

• Choose the best possible features;
• Positively react to the inevitable setbacks;
• Not overcommit (ruining expandability), not under-commit (keep maximizing value/cost);
• Clearly report the progress for the entire business to adjust its plans accordingly;

Concepts

Healthy Planning

[p. 9] We plan to ensure that we are always doing the most important thing left to do, to coordinate effectively with other people, and to respond quickly to unexpected events

Healthy plans drastically lower uncertainty, promote the product quality, make the basis for decision making, healthy sense of urgency, lead to overall satisfaction: customers, doers and the business. The opposite of healthy plans - panic, even in disguise - leads business to variety of losses and dissatisfactions, short and long term.

Healthy plans:

• contain the likely course of events;
• are simple to build and keep up-to-date;
• are comprehensible among all stakeholders to coordinate activities;
• are honest, making difficult to fool anyone by reporting;
• are reactive to life events ⁴

Eliminate Fear

The fear of uncertainty: customers are uncertain if / when the receive the desired value; business fears to let the customers down; engineers fear to not deliver right value at right time;

To defeat the fear:

• Customers should be informed about changes in plans, scope and costs to target the original launch date; expect most value for the cost; have the live transparency on deliverables' can change their mind on substitute functionality and priorities with no excessive costs; cancel at any time and still get the working product reflecting investments to date;

• The business and engineering, the implementers, expect to receive product features clearly prioritized; given resources to produce a quality deliverable at all times; receive help from other stakeholders; update their own estimates; accept responsibilities instead of being assigned to;

This is the kind of culture that allows for the best possible value at right time.

Constant Steering

[p. 18] We use driving as a metaphor for developing software. Driving is not about pointing the car in one direction and holding to it; driving is about making lots of little course corrections.

Note driver wears a blindfold

Balancing Power

The key to XP planning is balancing power between the business (customers) and engineering. Business people making business decisions: dates, scope, priority; Engineering makes technical decisions: estimates;

Balance the power via a simple set of rules: engineering makes technical decisions and business - business decisions.

The business and engineering both should have the single source of truth each - the voice of business and the voice of engineering. Two persons that accumulate the knowledge that allows to decide on the mutually desired course of actions at each point in time.

Customer - is a critical role for the product success. It should be a domain expert to answer engineers questions and estimate the expected value the software is about to bring. The role should accept the responsibility for project success or failure, equally to the business and engineering.

As customer remember these:

• Constantly re-evaluate the value of next functionality to be implemented;
• Trust engineering estimates, yet be ready they get wrong;
• Never let a date slip: use short iterations, on-going feedback, adjust scope and deliver the value at the agreed date;
• Release valuable functionality often: break into smaller valuable pieces;

Techniques

Work Breakdown Tools

XP aligns development with business needs through rapid, iterative cycles, ensuring flexibility, early risk detection, and continuous delivery of high-value features.

• XP breaks work into short cycles—releases (months), iterations (weeks), and tasks (days)—to adapt to changing realities.
• Progress is measured by stories (small, valuable features), ensuring each iteration delivers a fully tested (by customer), production-ready system.
• Prioritization happens at each iteration, with the business selecting the most valuable features to mitigate risks and maximize value.

Top-Level Controls

They are: Cost, Quality, Time, Scope.

• Cost: contains multiple levers - people (postponed and non-linear effect), tools (similar to an extend), people motivation with tools or money (faster effects, shorter impact, quickly diminishing returns);

• Quality: two levers - external (customer perceived: bugs, UI look, non-functional), internal (engineering, testing etc.). Letting the internal quality slip always bites with a snowball of constantly increasing defects; either account for future (most likely increasing) costs (=time =money) to fix the defects, get the throw-away product late or avoid this lever;

• Time & Scope: shorter iterations, scope management make these two to play simultaneously and pretty effectively; use often;

Make Project Scope

• Quickly scope the project using high-level stories and coarse estimates to determine feasibility.

  • Focus on big-picture functionality first (e.g., "Book a flight" = ~2 months).
  • Avoid excessive detail early; refine later.

• When timelines are tight, collaborate with stakeholders to cut or defer lower-value features: launch with core features first, add extras later.

• Use prototypes, expert input, or spikes to ground estimates in reality: if no prior experience exists, test small pieces before committing to large plans.

• Accept that initial estimates may be wrong; measure progress and adjust scope dynamically: delivering 40% of the original plan can still succeed if it aligns with market needs.

• Unrealistic goals demotivate teams. Base commitments on measurable progress, not optimism.

(p. 27) When you are overloaded, don't think of it as not having enough time; think of it as having too much to do. You can't give yourself more time, but you can give yourself less to do, at least for the moment

• Prioritize, skip some things;
• Reduce the size of things you do;
• Ask someone else to do some things;

Plan Performance

Promote sustainable development by grounding commitments in real past performance, reducing stress, and improving reliability - plan performance using the past experience. Flow from making best guesses at beginning to better estimates as you get the experience with current product.

Stories

Stories ⁵ are small, valuable units of functionality, written in plain language for both customers and developers. They should be testable, independent, and small enough to implement a few in each iteration. The customer defines them, ensuring they deliver real value, while developers estimate effort and feasibility.

Stories evolve through collaboration—customers clarify needs, developers estimate, and both refine scope. If a story is too big, split it; if unclear, add just enough detail when needed. Prioritization focuses on what to build first, not rigid rankings. Acceptance tests validate stories, replacing heavy documentation. Stories are never "final" — they adapt as the project progresses, ensuring the software stays aligned with real needs.

Estimation

Estimation here is about pragmatism, not perfection. By keeping it simple, relying on past data, and continuously learning, teams can develop reliable estimates that support effective planning without unnecessary stress.

Find a comparable past story, adjust for size differences, units don’t matter. Estimates are a team effort, they are not commitments

Notions:

• Ideal time: Uninterrupted, fully productive work time (e.g., "3 ideal days").
• Calendar time: Actual elapsed time (e.g., "5 business days").
• Why use ideal time?: It removes noise from interruptions, making estimates more comparable.

Process:

• Track actuals: Record how long stories really take to refine future estimates.
• Encourage learning: Early estimates will be rough, but they should improve with experience.

Release Planning

Approach

Release planning is a dynamic, customer-driven process—embrace change, deliver value iteratively, and avoid over-engineering. The first plan is the hardest; accuracy improves with experience.

– Release planning aligns business needs (scope, deadlines) with technical reality. Customers choose what to build (based on value), while developers estimate effort and flag risks. Plans are flexible and updated frequently.

• Break large stories into smaller, actionable pieces. Focus on 1-2 releases/iterations ahead to balance agility with predictability. Build infrastructure only as needed for current features to avoid waste.

• Use lightweight tools to visualize the plan ⁶. Measure team velocity (output per iteration) to ensure realistic commitments.

Events

Release planning is flexible — customers can adjust priorities or add new stories at any time. Stories are estimated in "ideal effort," and the customer decides where they fit without exceeding the team’s velocity. This adaptability ensures the project stays aligned with business needs while managing scope creep responsibly.

A full plan rebuild is needed when:

• Too many stories are deferred, making the original plan unrealistic.
• The team’s velocity changes significantly, breaking previous assumptions.

During a rebuild, developers re-estimate stories using updated knowledge, and the customer selects a feasible scope for the release. Rebuilding every 3-4 iterations keeps the plan accurate without excessive overhead.

First Release Plan

• The first plan is a rough starting point—expect adjustments.
• Velocity and story estimates improve with iteration history.
• Short iterations balance feedback and overhead.
• Adapt based on team dynamics, not rigid rules.

Iteration Planning

Iteration planning in XP involves breaking down stories into tasks, maintaining strict deadlines, and deferring scope rather than slipping dates to ensure predictability and discipline.

Basics

• Iterations (typically two weeks) allow for new features, refactoring, infrastructure work, and recovery.
• Developers own the iteration plan, while the customer monitors progress and adjusts scope if needed.

The Planning Meeting

• Stories are broken into 1–3 day tasks, with programmers signing up for tasks rather than whole stories.
• Promotes specialization, handles dependencies, and enables shared work across stories.

Tracking & Communication

• A tracker monitors task completion and flags imbalances (over/under-commitment).
• Daily stand-ups ensure team alignment and transparency ⁷.

Never Slip the Date

• XP enforces fixed iteration deadlines — scope is adjusted instead.
• Slipping dates is addictive and erodes credibility; deferring "essential" features trains the team for tough trade-offs.
• Customers must practice cutting scope to retain control and make informed decisions when critical deadlines arise.

The Value of Discipline

• Time-boxing forces prioritization and prevents uncertainty from compounding.
• Only at iteration’s end can progress be accurately assessed, making deadlines non-negotiable.

Red Flags

Common red flags, counter-measured by "slow down until you are under control, then speed up again":

• Missing estimates
• Customers won't make decisions
• Defect reports
• Not going end to end
• Failing daily builds
• Customer won't finish

Your Own Process

[p. 105] No two XP projects will ever act exactly alike. Once you get comfortable with the basic process, you will grow it to fit your situation more precisely.

I considered the following chapters either outdated, obvious, not specific enough, or redundant content: Chapter 21. Visible Graphs, Chapter 22. Dealing with Bugs, Chapter 23. Changes to the Team, Chapter 24. Tools, Chapter 25. Business Contracts. That is why I did not include these in the review. Read and decide on the value yourself.