Prioritizing software requirements – am I hot or not?

Posted on:

Prioritizing software requirements

Jason at 37 signals recently posted about essential vs non-essential requirements – the software equivalent of Am I hot or not? He talks about the prioritization decisions their team went through as part of bringing Campfire to it’s launch. Campfire is an online collaboration application that just launched today. We will talk about how their prioritization

Using ROI For Requirements Is A Risky Business

Posted on:

We’ve talked repeatedly about using ROI to drive prioritization of requirements based upon value. ROI can be used as the basis for prioritization for all decision making.

If we fail to take risk into account, our calculations will certainly be wrong, and we may make a poor decision. When we talk about accounting for risk in this context, we mean that we are accounting for the unlikely, undesired, or unintentional outcomes. We use the term expected value to refer to the risk adjusted approximation of the outcome. In financial circles, this is also called discounting.

The most common mistake people make when calculating ROI is failing to take into account the expected value of the return or the expected value of the cost of a project.

Prioritizing requirements – three techniques

Posted on:

Now that we’ve gathered all these requirements, how do we determine which ones to do first?

The less we know about our client’s business, the more the requirements appear to be equivalent. We’ll talk about three different approaches to prioritizing requirements.

1. Classical. Let stakeholders assign priority to the requirements.
2. Exhaustive. Explore every nuance of prioritization and its application to requirements.
3. Value-based. Let ROI drive the decisions. (hint: this is the best one – scroll down if you’re in a real hurry)
4. [bonus]. A look at how 37signals prioritizes features for their products.