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.

We start by identifying various levels of implementation, first with the simplest, usable level imaginable. Err on the side of under-usable, as you can always hold back on releasing until a later layer, plus the early iteration may expose some questions or pitfalls with your assumptions. Continue to identify levels based on business or customer value until you’ve mapped all iterations from zero functionality to the most complete level. The number of levels you identify likely will depend on the size of the feature, ranging from two to five.

To revisit our example, we might have broken the desired functionality into the following criteria or sub-features:

- Basic keyword search
- Sortable search results
- Search within results
- Category and advanced search
- Fuzzy logic search (misspellings, similar terms)
- Live search count
- Recommendations as you type
- Vote on search results
- Save common searches

Now, let’s see if we can group these items into releasable levels, rank them by implementation time and identify dependencies on other levels. Make sure each of them offers tangible value, no matter how small.

Here is a sample table of our advanced search request broken down by release level:

Search Functionality Release Level Table

As you move through the table, you’ll see that each level brings increased complexity, implementation time and (hopefully) business value. A feature level table will not always require each previous level to be implemented before it can be added. In our example, the only real requirement was level 1: the standard search functionality.

Developing the search feature in levels will allow the business to prove the value that search adds to the product before we move into the higher levels, which might require more senior level engineers, more time and higher implementation cost. It would be perfectly acceptable for the business to re-evaluate the advanced search functionality if it felt it was pushing up against diminishing returns. Or, more likely, the user feedback from the release of the early levels will expose new requirements that prove more immediately valuable than the user-influenced search functionality (level 4).

Allow your customer to set the acceptable release point at any level they see fit, but still fully deliver the software at each level to benefit from internal feedback and iterative releases. I likely could see a product manager not wanting to release the search feature until live search was added (level 2), if that was the competitive benchmark. If the only release point your customer will accept is the last level, try to explain the risk they are unnecessarily exposing themselves to and the opportunity they will miss.

From experience, I can also bet that for all but the most seasoned teams, releasing the search functionality in levels will allow them to reach the fully functional end-level quicker and with less problems than a team who aims to develop the full functionality in one full shot. The value gained from the insight and feedback afforded by releasing software in iterations cannot be understated. If your customer or manager balks at releasing the new feature in levels and insists on a budget and time frame for releasing the full functionality, you might consider planning the software in levels anyway and simply providing the end budget and time estimate. At least you’ll know if you’re on track as you develop the levels, and you’ll be managing your implementation risk.

References and additional information
For additional information on feature levels and planning, see Business-Driven Product Planning Using Feature Vectors and Increments from the November/December 2002 of IEEE SOFTWARE Magazine.

Tags: feature management, product planning, release iterations, release levels

This entry was posted on Tuesday, December 16th, 2008 at 4:02 pm and is filed under Strategic Insights. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.