Important Points

Write fewer bugs by using a wide variety of technical and organizational practices.
Eliminate bug breeding grounds by refactoring poorly designed code.
Fix bugs quickly to reduce their impact, write tests to prevent them from reoccurring, then fix the associated design flaws that are likely to breed more bugs.
Test your process by using exploratory testing to expose systemic problems and hidden assumptions.
Fix your process by uncovering categories of mistakes and making those mistakes impossible.

Collective code ownership spreads responsibility for maintaining the code to all the programmers.

A typical alternative to collective code ownership is strong code ownership, in which each module has a specific owner and only that person may make changes. A variant is weak code ownership, in which one person owns a module but others can make changes as long as they coordinate with the owner.

Vision reveals where the project is going and why it’s going there.

Release planning provides a roadmap for reaching your destination.

The planning game combines the expertise of the whole team to create achievable plans.

Risk management allows the team to make and meet long-term commitments.

Iteration planning provides structure to the team’s daily activities.

Slack allows the team to reliably deliver results every iteration.

Stories form the line items in the team’s plan.

Estimating enables the team to predict how long its work will take.

The vision statement documents three things: what the project should accomplish, why it is valuable and the project’s success criteria.

Release early, Release often.

A minimum marketable feature, or MMF, is the smallest set of functionality that provides value to your market, whether that market is internal users (as with custom software) or external customers (as with commercial software).

MMFs provide value in many ways such as competitive differentiation, revenue generation and cost savings.

Adapt Your Plans

Keep Your Options Open
Planning at the Last Responsible Moment
The Planning Game

Suppose you are creating a system that gets data from a user, validates the data and writes it to a database.

You might initially create a story for each step: ‘Get data’, ‘Validate data’, and ‘Write data to database’. These are sometimes called horizontal stripes.

A better approach is to create stories that do all three tasks but provide narrower individual utility. For example, you might create the stories ‘Process customer data’, ‘Process shipping address’, and ‘Process billing information’. These are vertical stripes.

There are two basic types of plans: scope-boxed plans and time-boxed plans.

A scope-boxed plan defines the features the team will build in advance, but the release date is uncertain.

A time-oxed plan defines the release date in advance, but the specific features that release will include are uncertain.

XP assumes that customers have the most information about value: what best serves the organization.

Programmers have the most information about costs: what it will take to implement and maintain those features.

Create a risk census,that is, a list of the risks your project faces that focuses on your project’s unique risks.

Risk exposure reflects how much time or money you should set aside to contain the risk.

Risk_adjusted_points_remaining = (iterations_remaining - risk_exposure) × velocity / risk_multiplier

For example, if you are using a rigorous approach, your release is 12 iterations away, your velocity is 14 points, and your risk exposure is one iteration, you would calculate the range of possibilities as:

Points remaining = (12 - 1) × 14 = 154 points
10 % chance: 154/1 = 154 points
50 % chance: 154/1.4 = 110 points
90 % chance: 154/1.8 = 86 points
In other words, when it is time to release, you are 90% likely to have finished 86 more points of work, 50% likely to have finished 110 more points, and only 10% likely to have finished 154 more points.

Some teams have a dedicated phone for emergency support requests; this is, of course, the bat-phone.

The amount of slack you need does not depend on the number of problems you face. It depends on the randomness of problems.

A good rule of thumb is to spend 10% of the iteration on technical debt.

Dedicated research time is an excellent way to encourage learning and adding additional slack into your iterations (People improvement).

Stories represent customer value and are written in the customers’ terminology. (The best stories are actually written by customers.)

Stories describe an end-result that the customer values, not implementation details.

Stories have clear completion criteria. Customers can describe an objective test that would allow programmers to tell when they have successfully implemented the story.

Special type of stories

Documentation stories
‘Non-functional’ stories
Bug stories
Spike stories (Research to do something)
Estimating
Meetings

Velocity relies upon a strict iteration time-box. To make velocity work, never count stories that aren’t ‘done done’ at the end of the iteration. Never allow the iteration deadline to slip, not even by a few hours.

You can have accurate estimates if you:

Estimate in terms of ideal engineering days (story points), not calendar time
Use velocity to determine how many story points the team can finish in an iteration
Use iteration slack to smooth over surprises and deliver on time, every iteration
Use risk management to adjust for risks to the overall release plan

Improving Velocity

Pay down technical debt
Improve customer involvement
Support energized work
Provide needed resources
Offload programmer duties
Adding programmers

Incremental requirements allows the team to get started while customers work out requirements details.

Customer tests help communicate tricky domain rules.

Test-driven Development allows programmers to be confident that their code does what they think it should.

Refactoring enables programmers to improve code quality without changing its behaviour.

Simple design allows the design to change to support any feature request, no matter how surprising.

Incremental design and architecture allows programmers to work on features in parallel with technical infrastructure.

Spike solutions use controlled experiments to provide information.

Performance optimization uses hard data to drive optimization efforts.

Exploratory testing enables testers to identify gaps in the team’s thought processes.

Divergent change occurs when unrelated changes affect the same class. Its an indication that your class involves too many concepts. Split it, and give each concept its own home.

Shotgun surgery is just the opposite: it occurs when you have to modify multiple classes to support changes to a single idea. This indicates that the concept is represented in many places throughout your code. Find or create a single home for the idea.

Data clumps are similar to primitive obsession. They occur when several primitives represent a concept as a group.

When you have a class that contains methods but no meaningful per-object state, you have a wannabe static class.

When you a refactor, proceed in a series of small transformations. (Confusingly, each type of transformation is also called a refactoring.)

You Aren’t Gonna Need It (YAGNI)

‘Don’t repeat yourself’, or the DRY principle.

A spike solution, or spike, is a technical investigation. It’s a small experiment to research the answer to a problem.

Exploratory testers use the following four tools to explore the software.

Tool #1: Charters (Charters are the testing equivalent of a story)
Tool #2: Observation
Tool #3: Note-taking
Tool #4: Heuristics

CRUD: create, read, update, delete

Experience helps you see how Agile methods work. Mindfulness helps you understand your experiences.

Improve the Process

Test-driven development, exploratory testing, real customer involvement, iteration demos and frequent releases all provide information about the project, from code to user response.

Rely on People: (Continuous improvement)

Build Effective Relationships

Let the Right People Do the Right Things

Eliminate Waste (improving)

Deliver Value