Date Based vs. Feature Based Releases

There are a few different ways that you can define a release. First, you can specify the functionality that needs to be in the release. If you take this approach, the release is done when you complete the functionality. Alternatively, you can specify a date. When you hit that date, the release is done. Generally speaking, you're much better off taking the latter approach.

There are a few advantages with date based releases. First of all, it is a very clear definition of done. If you base your release on features, there is room for interpretation on what it means to do those features. By committing to a date rather than to features, you can ensure that you meet the commitment by keeping the ability to vary scope. And trust in engineering is often based on your ability to meet commitments.

Secondly, it makes it easier to change your priorities based on what you learn (i.e., be agile). Things change. What you think is important at the beginning of the release might not be what you think is important at its end. Because you haven't committed to specific functionality, you can take things on in priority order and change those priorities as you learn more. You can take on things that weren't even on the list when you started. If you base your release on features, this becomes more difficult. You'll either have to de-commit something or you'll have to push the release date out to take on new items.

Third, it encourages people to really prioritize. Only the top items will make the release. With a feature based release, it is easier to keep adding to it. The cost in terms of schedule is often seen much later.

Now the issue with date based releases is that people want to know what will be in the release. It often isn't good enough to say "the release will contain the most important things that we can accomplish by such and such date". There are a few ways to potentially handle this.

You can give a higher level definition of scope. Say which areas you plan to work in, but shy away from what specific work you will do and / or the amount of investment in each of those areas. See this blog entry for more on this subject.

Or you can share your backlog (or a subset). The further an item is down the list, the less likely it is to make it. By stating your priorities, you change the discussion from whether something is in or out to its relative importance. Shorter releases make it easier since if an item doesn't make this release, the next one isn't too far away.

Finally, you can do a hybrid approach. The release is date based, but it must include these committed features (or the date is pushed). Realize though that the more you commit to, the less agile you will be able to be.