Weekly and Quarterly Cycle

XP lists two planning cycles as separate primary practices, but they are one idea at two scales, so they are one note here.

Weekly Cycle. Plan a week at a time. The customer picks the stories for the week from what the team can commit to; the team writes the tests and the code that satisfy them. Beck’s stated rationale is feedback density: one-week iterations of customer-requested features exist “to create fine-grained feedback about progress.”

Quarterly Cycle. Plan a quarter at a time, at the level of themes and bottlenecks rather than tasks. This is where the team lifts its head from the weekly rhythm to ask what the release is actually for, what has silted up, and what to repair. The corresponding release rhythm in the book is short: a few months at most, so that the scope of any slip is bounded.

The nesting is the mechanism

Each cycle is a feedback loop, and XP stacks loops of different lengths so that different classes of mistake surface at their own natural speed. The test-first cycle catches a wrong line in seconds. The integration cycle catches a wrong merge in hours. The week catches a wrong story. The quarter catches a wrong direction. A team that runs only the fast loops ships a well-built wrong thing efficiently.

The dated part is the calendar. Weeks and quarters were 2004 conveniences; the durable intent is nested loops with a deliberate spread of periods. Continuous delivery changed the numbers without touching the argument.

Signal: you can name the length of every feedback loop your team runs, and there is more than one.

Sources

• Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd edition (Addison-Wesley, 2004): Weekly Cycle and Quarterly Cycle as consecutive primary practices in chapter 7. Chapter 1, in the publisher’s free sample, gives the rationale: short release cycles of a few months at most, one-week iterations of customer-requested features for fine-grained progress feedback, and short tasks within an iteration.
• Agile Alliance et al., Principles behind the Agile Manifesto: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”