Techniques for Prioritizing Requirements
Ulf Eriksson
JAN 23, 2014 05:00 AM
A+ A A-

Why is prioritization important? Because you never have enough time to satisfy every requirement, you need to find the most important ones. Even managers on large projects sometimes prioritize requirements based on their gut feeling, without thinking through a more systematic approach. Users and buyers often feel that prioritization means making everything "important" because lower priority requirements will never get implemented – they'll just get put onto an endless to-do list and never see the light of day again. In this article you'll learn two common techniques for prioritizing requirements.

There are several reasons why prioritization is important, depending on who you are:

• For project managers, the priority list is a valuable aid in planning which features are to be delivered in the next (or final) version of the system.

• For system owners and project managers, systematic prioritization makes it easier to assign the right resources to the right tasks. You can only put more resources on an important requirement if you know it's an important requirement.

• As a developer or supplier, prioritization helps you demonstrate that you understand the customer's priorities. This makes it easier to dedicate time to the top-priority functions first.

Common prioritization techniques

Most people use some sort of value hierarchy in prioritization, such as "high", "medium", "low"; or "must" and "could". The simplest approach is just going through all the requirements and indicating the priority for each. If the requirements are documented in a requirements management tool like ReQtest (www.reqtest.com), you can go through the requirements one by one. Every company and every project has a different way of determining who participates in the prioritization process, but representatives from the client organization are almost always involved.

You can prioritize requirements using a value scale in groups, as well as individually. If a larger group of people is participating in your prioritization process, you might want to try the "three points" technique. Write up the requirements on a whiteboard in a conference room, and have each person draw a point next to the three requirements that are his/her highest priorities. You can then prioritize the requirements based on the number of points they earn. If you use this technique, make sure that the requirements are such that they can be prioritized against each other. You can't prioritize "high security" over the requirement "it must be possible to add customers" because these are two completely different kinds of requirements. However, you might prioritize "add Customer functionality" over one like "advanced search".

 

A lot of times, you need to manage requirements that you won't introduce for some time. I mark these as "future requirements" in the requirements documentation. This keeps the developer from backing himself into a corner by building features that he'll just have to rebuild later if everything is ready to go on the customer side. For example, you might have "advanced search" as a future requirement in a system where the current version will include basic search functionality. If the developer reading the requirements thinks that the advanced search function will only take a little extra effort, he might propose doing it now in order to minimize unnecessary work later.

Pros and cons of value scales

You can prioritize requirements very quickly using one of the scales above; prioritizing as many as 30 or 40 requirements in less than an hour is not a problem at all. However, simplicity is also a limitation of this technique. Client groups tend to rank every requirement as "highest priority," and the value scale is subjective: a requirement that you think is important might be perceived as unimportant by other people with different needs or rationale.

The biggest problem with value scales is that they don't take development cost into account. Certain "top priority" requirements will take a few hours or days to complete, while others can take several weeks. If your time or budget is limited and you have to choose which requirements you'll implement and which you won't, you should have good information about the time needed for each requirement in order to make the right decisions. What follows next is a technique that solves that problem.

Prioritizing against two criteria

A better way to prioritize requirements is to use two different criteria, e.g. including both development cost and value to users. Other possible criteria include value to clients (who don't always have the same priorities as the users), or technical risk, i.e. the difficulty or the risk that a change in one area will negatively impact other parts of the system. The client organization can assess value for the users versus the value for the organization as a whole using the same value scale as described above. However, technical risk and cost need to be determined by the supplier. To do this effectively, you can set up all the requirements in a table as follows.

You pre-fill the first two columns with the requirements and the corresponding ID; then the clients assess the value to the users, while the supplier estimates development costs.

 

ID

 Heading

Value to users

Development cost

1

List all tasks

4

3

2

Basic search

4

2

3

Advanced Search

2

3

4

Ability to save searches

1

4

 

The scale used is arbitrary; in this case it ranges from 1-4, with 1 being least important for users and lowest development cost, and 4 being most important and maximum cost. If this scale is too coarse for your needs, use a scale with six or eight levels instead. Multi-step scales make it easier to analyze the results, but more difficult to determine the correct value. In this case, we just need a rough estimate, so this 4-degree scale is sufficient. You can also use the MoSCoW scale here: Must, Should, Could and Won't.

When both client and supplier have set their values in the two columns, you can use a requirements management tool like ReQtest to identify the requirements that have the greatest value for users at the lowest development cost. You should introduce these requirements into the system as early as possible, in order to implement quick wins. The tool will also show you which requirements will be most expensive to implement, while being low priority for users; these requirements shouldn't be implemented now, or maybe they not at all. It's just as important to identify the low-priority requirements as the high-priority ones, since you'll have an easier time explaining to stakeholders why you cut certain requirements from the list if you can simultaneously show them the requirements that have been given higher priority and why.

In summary…

In any prioritization exercise, you should exclude requirements that can't be prioritized. These may include requirements for features, without which the system would be useless (e.g. an ordering system where you can't enter orders). They might also be functions that have to be included because of legal requirements, internal requirements, or the IT department's policy regarding system certification. You can't prioritize these requirements so you shouldn't bother including them. They are already "must have" requirements.

It's important to remember that the prioritization you make today serves only as the basis for the next development phase, and it may change. Don't try to prioritize across several future iterations; when a given iteration starts wrapping up, make prioritizations for the next iteration. You might deprioritize certain requirements during development, and new demands are sure to arise. Prioritizations have an expiry date and to keep them fresh you need to begin anew at the start of each iteration, then update them continually in your day-to-day work.

About the author

Ulf Eriksson is one of the founders of ReQtest,  http://www.reqtest.com/, an online bug tracking software hand-built and developed in Sweden. ReQtest is the culmination of Ulf's decades of work in development and testing. Ulf is a huge fan of Agile and counts himself as an early adopter of the philosophy, which he has abided to for a number of years in his professional life as well as in private.

Ulf's goal is to life easier for everyone involved in testing and requirements management, and he works towards this goal in his role of Product Owner at ReQtest, where he strives to make ReQtest easy and logical for anyone to use, regardless of their technical knowledge or lack thereof.

The author of a number of white papers and articles, mostly on the world of software testing, Ulf is also slaving over a book, which will be compendium of his experiences in the industry. Ulf lives in Stockholm, Sweden.

FIRST
PREV
NEXT
LAST
Page(s):
[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment:
 

Computing Now Blogs
Business Intelligence
by Keith Peterson
Cloud Computing
A Cloud Blog: by Irena Bojanova
The Clear Cloud: by STC Cloud Computing
Careers
Computing Careers: by Lori Cameron
Display Technologies
Enterprise Solutions
Enterprise Thinking: by Josh Greenbaum
Healthcare Technologies
The Doctor Is In: Dr. Keith W. Vrbicky
Heterogeneous Systems
Hot Topics
NealNotes: by Neal Leavitt
Industry Trends
The Robotics Report: by Jeff Debrosse
Internet Of Things
Sensing IoT: by Irena Bojanova

 

RESET