KK: Requirements Prioritization: Two Simple Techniques

Rated 4.00 out of 5 based on 1 customer rating
(1 customer review)

Prioritizing User Stories or Requirements Is Essential to Focusing Your Limited Resources on the Most Important Requirements First


Author: Tom and Angela Hathaway
Video Duration: 12:53 minutes

This KnowledgeKnugget™ is part of this instructor-led workshop

Video Overview

In this KnowledgeKnugget™ you will learn how and when to use “needs-based” requirements prioritization versus “release-based” requirements prioritization. Properly prioritizing your business, stakeholder, and solution requirements can save you money, time, and probably even your project.

Video Transcript

Prioritization Techniques for Software Requirements and More

On any given IT project, you may end up with dozens, hundreds, or (heaven forbid), even thousands of requirements under a variety of names. You captured user stories, features, themes, epics, business requirements, stakeholder requirements, solution requirements, or requirements under any other name. To simplify the discussion of prioritization techniques, I will refer to all of the aforementioned as “items”.

Prioritization of the items is critical to recognize where you should focus your efforts no matter whether you are maintaining a product backlog or trying to deliver a Requirements Document. In this KnowledgeKnugget™, I will introduce a couple of prioritization techniques you might want to consider to help you make the critical decision which items are most important.

For starters, make sure that you are working with a valid set of items for your project. This assessment requires someone who has insight into your organization, in particular its risk tolerance, technological maturity, and culture. The goal is to ensure that each of the items you are considering is feasible for your organization. There are three simple questions to explore:

  1. Can you deliver this item with the available technology (if it is not available within the organization, can and will the organization acquire it)? This addresses “Technological Feasibility”.
  2. Are there any reasons you or anyone on the team can think of that might prohibit delivering this item (e.g., cost of acquiring a new technology, risk involved in implementing the item, etc.)? This falls into the category of “Financial Feasibility”.
  3. Is this item acceptable within your organizational culture (assuming that there are no technological or financial impediments, will all of the relevant stakeholders accept a solution based on this item)? We call this “Cultural Feasibility”.

The recommendation here is to document any concerns in any of these three areas and address them before you start to decide which items are most important. Do not waste time prioritizing items that fail the feasibility test.

Needs-Based Requirements Prioritization

Given a list of feasible items, you need to have a repeatable, reliable process for identifying the relative priority so the project (or Agile) team can make sure the solution meets the critical items first. One of the simplest prioritization ideas is “Needs-Based Prioritization”. It distinguishes between what people really need versus what they would like to have. To get started, you need your group of decision makers (stakeholders) who are knowledgeable about the (feasible) items.

… [end of excerpt]

1 review for KK: Requirements Prioritization: Two Simple Techniques

  1. Rated 4 out of 5

    Thanks for the video, this gives insights into how the prioritisation is done in the organisation

Add a review

Your email address will not be published. Required fields are marked *

You may also like…