When you plan the next release of your application you have to answer one important question: when will I release? You can answer this question in two ways: you simply define a release date (i.e. it is a time-oriented release), or you define a set of features the new release will contain (i.e. it is feature-oriented). That means in the first case the time is fix, but the features are variable, whereas in the second case the time is variable and the features are fix. Quite common is also the situation that both, time and features, are fix.
Let’s have a closer look at those options we have at our disposal when planning a release.
Time-oriented releases have a fix release date. If we see we cannot make it, then we either have to delay features to the next release, or we have to switch features, i.e. an “easier” feature gets implemented instead of a planned feature. On the other hand, if there is some time left until the release date you can implement additional features.
The challenge with time-oriented releases is to find the right time frame. Is it too short, it is difficult to implement something of value. Is the release date too far away, then there is no release “pressure” and people slow down.
An example for time-oriented releases is the Scrum process, there you have at the end of each iteration a release (i.e. every two to four weeks there is a new release).
With feature-oriented releases you define a set of features you want to have implemented before you release. There is often no release date announced, or it is rather vague like “we plan a release for spring 2008”.
The challenge here is to find the right set of features. If you select too many features, then the implementation takes “forever”. In the other case you may have too many releases with not much value.
As an example for feature-oriented releases we probably can take CakePHP, as its releases follow the motto “it is done when it is done”.
A combination of the two aforementioned approaches are time-and-feature-oriented releases, where you have a fix release date plus a set of features the release must contain.
The challenge here is that you often need a variable element you can adjust to deliver the release at the planned date with the planned features. You can add more people to the project, work longer, and/or decrease the quality.
Examples for such time-and-feature-oriented releases are projects which have to be live at a certain date, e.g. an advent calendar application has to be ready at the first of December.
As you see, each approach comes with its own challenges. There is no best approach. It depends on your specific situation/project.