Release New Features Early and Often: Part II
In part I, I made the case for looking at features as having many releasable levels vs. just done or not-done. In this second part of the article, we’ll actually exercise the idea against an example to illustrate the nuances and benefits of this approach:
Imagine that a customer calls you to request the addition of search functionality to their case-study catalog. They sell rich content and research to academic customers; the easier the content is to find, the more they sell. She emails you a few links to some reference sites using similar functionality and sketches out how the results might appear. The result is the same if you iterate the design with them into a mature spec. You wind up with a detailed and all-encompassing vision of the new feature.
Once the end concept is relatively clear and both sides agree that the designed functionality has business value and is feasible, it’s time to look at this feature through a different lens. This neatly divides the robust feature into self-contained release levels, each resulting in value to the user or business.
continue reading this article >