After reading the discussions on continuous frequent delivery, I was reminded of some misconceptions regarding the "two weeks" rule that's mentioned in FDD.
Firstly: what is it? When building the features list in process #2 we decompose the domain into a Subject Area (SA), Business (BA) and Feature hierarchy. The guideline for the granularity of features is that it should take no more than two weeks to complete, i.e. to put through processes #4 and #5 (design and build by feature). If it's bigger than that we break it down further.
The first common misconception is that all features are two weeks long, and that we perform processes #4 and #5 for a single feature that lasts for two weeks. This isn't how we do it. There's a discussion of workflow elsewhere on this site, but bascally the Chief Programmer (CP) bundles up a set of features into a work package, forms a feature team, and then takes the package through processes #4 and #5. The size of the work package is not fixed, and depends on a lot of factors. There is no hard-and-fast rule about how big a work package should be.
Another misconception is that the results of a work package are "delivered" to the client, perhaps as a partial working system for them to play with and test. While there may be some milestone demo's along the way, these are not what work packages are about. The end result is that the code is promoted back into the build. That's all. Of course you have all the other artifacts that go along with it (e.g. design sequences, code inspections, JavaDoc etc.) but ultimately we're just coding away implementing the design.
And a final note on feature granularity: what's the lower limit? We don't specify a lower limit on the time taken to build one, but instead look at the functionality. The level of "getter" and "setter" methods is too low - we want just above that level. A trivial feature might be "generate the unique number of an order", which might take only hours to cimplete. That's fine - the CP will most likely bundle it together with a number of other features in a work package when it's time to build it.
