Sometimes you can release much more often, maybe every iteration. This can happen for in-house development and also for application service providers where your users are distant but using thin clients and you have close control over the server.

Most of this is good news. Each iteration is ready for production, and going into production with each iteration is perfectly feasible. This usually means that you need to have high confidence in your tests and a very automated build process, but if you are doing XP you should have these anyway.

With short releases you don't really need any notion of a release at all. You can work iteration to iteration, planning one or two iterations ahead. This allows you to be very responsive to the customer, giving the customer control of the process with rapid feedback to see the results.

However, there is a danger to never having "a release." The customer may lose strategic vision of where the software needs to go. In this case the customer spends so much time choosing features for the short term that she misses important long-term needs.

The release can come back as a longer-term milestone. By the end of the next quarter we hope to be here, and by the end of the following quarter we want to be there. So even if you release into production every iteration, still think about planning out a release on a quarterly scale. Even though the resulting plan isn't very helpful as a predictor of the future, the act of planning those longer releases is vital. (Didn't some general say something like that?)

What happens if you can only release once a year?

Our first reaction to this reality is to question it. Maybe there is some way to release more frequently.

A common case for long releases is in replacing an existing system. Because you have to do all the things the old system had to do, you can't release something with only some of the features.

In this case look for a way to let the old and the new coexist. Manage some contracts with the old system and some with the new, gradually moving the contracts over with each release. This may involve extra work to migrate data between the systems and to integrate the user interfaces, but the resulting drop in risk is usually worth it.

Another case is with shrink-wrap software. Many users just will not want to upgrade their software every quarter, nor will the marketing department cope with the resulting flux. In this case look for a way to send intermediate releases to those customers that may be more interested in these versions. Call them service packs or something. That way at least some of your users will use the system in production, and you'll get the feedback you need.

Frequent releases are good, but if you can't release frequently you don't have to abandon XP completely. You may need to create interim releases that are only available internally. These will be enough for the friendly users to play with in controlled conditions and to provide a focus for planning purposes.

Some teams like to have more smaller stories. Instead of four or five two-week stories, they will plan 25 two-day stories. This gives the customer finer control over the activities of the team, at the cost of some of the flexibility of the team and more involvement by the customer.