Minimally Marketable Features and Flow

In the context of software development, flow is the movement of new features from idea to use by a customer. The shorter the amount of time between idea and use (i.e. the faster the flow), the faster value and revenue are realized.

Features are decomposed into stories. Typically, these stories are ordered from most important to least important.

As I was recently monitoring the flow of features through a development system, I was observing many of them sitting in the Develop phase for a long time. When I investigated, I discovered that many of the features had been completed to a certain depth of functionality and then teams had moved on to other features.  If time allowed, the team would come back and complete more of the stories that defined deeper functionality of the feature.

Essentially, the teams had been using the stories within a feature as a negotiating point with product owners.  Initially, I thought this seemed like a perfectly acceptable practice, but there are a few problems with it:

1. The teams weren’t being transparent and predictable about that they’re going to deliver. They said they were going to deliver a feature, but the definition of the feature was ambiguous.
2. It’s difficult for the business to communicate externally what the content of a release is. The name of a feature usually is based on all the stories that define it, including those that are negotiable. When teams don’t complete all the stories in a feature, that leaves the business to try to determine what a feature really does and what it doesn’t do, communicate that to customer, and to plan the uncompleted stories into a future release.
3. Teams end up with a large amount of work in process (WIP). When teams have a large number of features all being worked at the same time, it is difficult to know which is the most important and teams have to do inefficient context switching to float back and forth between them.
4. Features don’t move into and out of the Develop phase in a smooth flow. Teams end up moving large batches of work all at once. This makes the teams less flexible and less transparent. Additionally, if they are able to move items through the Develop phase in a faster, more predictable, more transparent manner, they might ultimately be able to release more frequently which would deliver value to customers more frequently.

A better alternative would be to define features in a truly minimally marketable manner. Don’t include the negotiable aspects of a feature in its definition. Use those aspects to define a different, smaller feature.