Pragmatic Prioritization

The typical release scheduling process works something like this:

1. Stakeholders build a backlog of features they'd like to see in the product eventually.
2. The stakeholders decide among themselves the relative priority of the features in the backlog.
3. The development team estimates the development time for each feature.
4. The stakeholders set a target feature list and ship date based on the priorities and estimates.

The problem here is primarily in step 2; this step tends to involve a lot of discussion bordering on arguing bordering on in-fighting. Priorities are set at best based on a sense of relative importance, at worst based on emotional attachment. Business value is a vague and nebulous consideration at most.

I propose a new way of looking at feature priorities:

1. Stakeholders build a backlog of features they'd like to see in the product eventually.
2. The stakeholders estimate the business value of each feature in the backlog.
3. The development team estimates the development time for each feature.
4. The stakeholders set a target feature list and ship date based on the projected return of each feature - i.e., the estimated business value divided by the estimated development time.

This turns a subjective assessment of relative priorities into an objective estimate of business value, which is used to determine a projected return on investment for each feature. This can then be used to objectively prioritize features and schedule releases.

I've been using this workflow recently for one of my upcoming projects, and I feel like it's helped me to more objectively determine feature priorities, and takes a lot of the fuzziness and hand-waving out of the equation.

Shameless self-promotion: Pragmatic prioritization is a feature of my project scheduling and estimation tool, Rogue Prognosticator.