Several posts in this blog discuss the order in which new features should be implemented. In this post I try to summarize some of my thinking so far. The following terminology will be used in this post:
- New proposed features are described in “change requests” that are in effect small documents or records in a database describing various aspects of the proposed feature.
- To realize a change request a number of “tasks” need to be completed. Some tasks are related directly to a change request whereas other tasks are more “global” (e.g. system testing).
- Change requests are organized in an ordered list with change requests to be completed first highest up in the list. Change requests are always picked from the top of the list.
- For practical purposes also the tasks (task descriptors) that are derived from the change requests are stored in the product backlog.
Where in the product backlog a new change request and its associated tasks should be put (and thus when it is going to be realized) depends on several things:
- The additional expected income we will get from the new feature. This is, among other things, a function of the customer benefit of the new feature and the certainty that we will be able to deliver the feature. We wish to deliver high value features first everything else being equal.
- The expected cost of developing the new feature. This depends on a large number of things such as the novelty of the technology and the skills of the developers. We want to deliver features that are inexpensive to realize first everything else being equal.
- The level of uncertainty of successful realization or attractiveness of the new feature.
- The dependencies among the features. Several functional features may for instance depend on that we can achieve enough performance on the given hardware platform.
Let’s consider three different development scenarios:
We own a web site to which we add features more or less continuously from a potentially long product backlog. We have a dedicated team that implements and releases new features in an ongoing process where new change requests come in regularly and new features are released incrementally as they become available. The new features are mostly independent from each other and carry low uncertainties. A faulty or useless new feature can easily be removed from the web site without affecting other features.
In this scenario change requests in the product backlog should be ordered strictly based on their estimated income / cost ratio; inexpensive features which bring in a lot of money should be realized first. Since uncertainties are assumed to be low, they can be largely ignored. Also, with low uncertainty, we don’t really need the overhead of a project organization with all the planning, tracking and risk management. A Kanban-style development process is quite sufficient. Since there are no dependencies, it is sufficient to look at each change request and compare its income / cost with that of all the other change requests. See also this post and this post.
“New version of an embedded system
We develop an embedded system for, say medical imaging modalities in a series of projects, adding new features in each project. The product has existed for several years and has a long product backlog. A new project is started based on some signal from the market or based on a predetermined schedule. A new project usually has a “theme” that binds together the change requests. The new features are mostly independent but there may be a few features that are critical to the success of the rest. One example is performance: if we discover that the hardware resources available are not sufficient then we need to scale back on some of the other features.
This case is similar to the first one except that instead of delivering features in a continuous stream, we deliver them in batches, produced in projects. Uncertainty is assumed to be higher so we need to consider uncertainty-weighted expected values of the income and the cost of each feature before ordering the features in a income / cost order.
Ideally, independent high-uncertainty features should in this scenario be evaluated outside the regular product development stream in a research project, concept development project or similar, so that the few high-uncertainty features don’t stall the whole project. High-uncertainty features that are necessary for some other, low-uncertainty features, on the other hand need to be addressed early in the project; there is no use in developing a number of new features if we at the end discover that we can’t get for instance real-time video performance when this is a must-have requirement. The project tasks therefore need to be ordered so that we bring down uncertainty as fast (and inexpensively as possible). See also this post and this post.
We develop a totally new and innovative product based on new technology or new science in general. The product backlog only covers the features for the first project. There are several make-or-break uncertainties within the selected set of features regarding the technology, the market, or perhaps some other area. This means that there is a significant risk that the project will fail.
In this case we assume that all or most features in the product backlog are required for the product to have any value at all (as this is the first version of the product); all features depend on all other features. Selecting change requests for the project is therefore relatively straightforward in this scenario. Instead we need to focus on the order in which we realize the features within the project so as to minimize the expected project cost. We need to order the project tasks so that tasks that give a large degree of uncertainty reduction per unit of cost come first in the project; if we fail, it is better to fail early than to fail late. See also this post.