Example
Digging through some project notes, I found a great table that succinctly describes a release strategy.
| Release | New Technology | New Business Functionality |
|---|---|---|
| r3 | new SSL network stack | company registration |
| r4 | e-forms w/markdown | e-filing |
| r5 | accounting integration | e-receipting |
Release Guidelines
Planning a great release is hard work. You have to make tough choices. How large should the next release be? What business functionality should be next? How can we implement that business functionality in valuable increments? How can we minimize the technical risk? How can we do all of this in such a fashion that we set the stage for the next release?
Here are some guidelines I like to use:
- Limit release length to (3) months;
- Limit release scope to (6) user level use cases (see example);
- Select use cases with high business value;
- Focus release on one functional area;
- Introduce (at most) one major new technology; and
- Set the stage for the next release.
This is a large release. The number of use cases will double when you work through their variations and failure handling. So don't add more.
And finally, remember that the standard rules apply for that new technology you're excited about: Use Proven Products and No Plumbing.
Lesson Learned: Strategically roll-out large applications as a series of right-sized high business value releases.
