Comments on: Prioritizing requirements – three techniques

By: Scott Sehlhorst

Scott Sehlhorst — Mon, 05 Mar 2007 15:15:08 +0000

Hey Craig –

I like the Kano model, at a minimum, for classifying what the requirements are. It provides a sanity check – are the “must haves” really the “must haves?” And then utility / value drive the next set of requirements to be scheduled.

In my experience, satisfying the buyer persona tends to overwhelm the user persona’s needs for early releases of enterprise software. For B2C, the buyer is usually also the user – but wearing a different hat. In other words, when making a purchasing decision, the user will evaluate the software differently – a checklist of “can I do X” is what they will use. Or they will get feedback from others – “how easy was it to do X?”

Tough balancing act.

By: Craig

Craig — Mon, 05 Mar 2007 10:12:31 +0000

Prioritising projects in a marketing department yields the same results. I suggested the review board rank them and better results were yielded.

I wonder if this would work for requirements. At the least it should get the most important features built first.

By ranking you have to put some ahead of others, and you probably have a set of mandatory requirements you can’t release with, but it helps in the middle of the pack when resources and time start to become scarce.

Usually I like to use the Kano model but it might be interesting to try.

By: Definition of expected value -Tyner Blain

Definition of expected value -Tyner Blain — Sat, 04 Feb 2006 02:55:39 +0000

[...] Understanding the expected value of a possible future event allows us to make mathematically sound decisions. We can decide if we want to make an investment. We can assign a reasonable price for our services. We can prioritize requirements. Expected value is a calculation that should be used when calculating ROI. How is expected value calculated? Have you ever participated in a 50-50 raffle? This is a common fund-raising technique in the US for school groups, organizations, etc. The group sells raffle tickets (each ticket has a uniquely identifiable number, and there are two copies of each ticket) for $1 each to people. Each person gets one half of the raffle ticket, and the other half gets put into a drawing. After all of the tickets have been sold, the organization randomly picks a single ticket. The person who has the matching number on their raffle ticket wins half of the money collected by the group. The group keeps the other half. [...]

By: Software testing series: Top three measurements of quality -Tyner Blain

Software testing series: Top three measurements of quality -Tyner Blain — Fri, 03 Feb 2006 03:42:17 +0000

[...] 2. How big of a problem is our quality? When reporting quality status to a non-technical manager, we are often asked “OK, there are 100 bugs – how bad are they?” The same issues that we struggle with when prioritizing requirements are also at the root of problems in prioritizing bug fixing. [...]

By: Top five ways to be a better listener -Tyner Blain

Top five ways to be a better listener -Tyner Blain — Mon, 30 Jan 2006 04:59:50 +0000

[...] Interviewing is the primary requirements gathering process in any project. Getting feedback from users and other stakeholders is important to validating and prioritizing requirements. Communicating with people is critical to success in managing requirements. And listening is at least half of communicating. [...]

By: From MRD to PRD: The key to defining a spec --Tyner Blain

From MRD to PRD: The key to defining a spec --Tyner Blain — Tue, 24 Jan 2006 13:54:50 +0000

[...] Organizing, validating, and prioritizing these capabilities is the hard part. The output of this effort is a PRD. A product roadmap (a vision of what a product will be capable of doing, over time) is another potential output. [...]

By: Marcus Ting-A-Kee

Marcus Ting-A-Kee — Fri, 20 Jan 2006 08:07:05 +0000

Great post! ROI with dependencies is the best prioritization methodology, IMHO. Development is really an investment and one would not invest where the expected return is low or minimal (under normal circumstances.)

I am thinking there may be a 3rd reason why a high ROI requirement is implemented after another one – legislation & compliance. For example, dates for the implementation of controls for SOX or privacy policies may be beyond the control of a steering committee. I am not sure if these types of requirements would be adequately covered off in non-functional requirement documentation.

By: Tyner Blain » The best way to improve ROI is with good requirements

Tyner Blain » The best way to improve ROI is with good requirements — Thu, 19 Jan 2006 08:56:23 +0000

[...] One ROI benefit of good requirements is being able to work on the most important stuff first. The top 3 reasons for project failures identified in their poll: [...]