Binary Choices are Better When Choosing Software Features

prioritiesIn the world of agile software development, there’s a lot of emphasis on things like story estimates, daily standups and team retrospectives. Those things are important but there’s a serious problem that none of them address — feature set. What features should the software have in the next release?

Waterfall development practitioners tend to include everything they can in their requirements specifications — if anyone requests it, put it on the list. Is it any wonder that those software projects take many months or even years to deliver anything of value?

Agile development practitioners talk about minimums — minimum viable product (MVP) or minimum marketable features (MMF). Both concepts appear reasonable but a critically important question is left unanswered. How is the minimum determined?

Try a Simpler Approach

The simplistic answer is that it’s up to the product owner. Someone has to have the final say, right? Feature requests come from many sources including software developers, product managers, marketing experts, senior managers, and customers. Every one of them has a unique perspective and different needs. The product owner can help sort it all out but it’s never easy.

Let’s not forget the adage that people often don’t know what they want until they see it. The PO may spend many hours deriving MVP or MMF only to find out later that customers (the only opinions that really matter) either disagree with the choices or changed their minds.

I suggest approaching feature prioritization as an iterative process. Don’t devise elaborate priority matrices or scoring systems. They are confusing and subject to manipulation. Instead, take all the features of interest and let the sponsors, stakeholders and end-user representatives classify them using just two categories like:

  • Vital
  • Non-Vital

Let everyone know that only features marked vital have any chance of making the next release. In the unlikely event that the vital feature list is short enough after one pass, you’re done. If not, you’ll need to repeat the process using the vitals only. If the list is still too long, do it again.

If you get stuck, that is, everything left is vital but there’s too much to do, let everyone know that the PO will make the final decision. Once the list is final, there is still one thing left do to.

The development team needs an opportunity to review the final list and look for inter-dependencies. For example, vital feature ‘A’ may require that non-vital feature ‘Z’ be implemented. Don’t skip this step!

photo credit: Pete Reed via photopin cc

Updated: February 24, 2013 — 8:23 pm