
Prioritize Your User Stories, Features, Non-functional Requirements or Other Backlog Items
Prioritizing User Stories or Requirements Is Essential to Focusing Your Limited Resources on the Most Important Requirements First
FREE
Author: Tom and Angela Hathaway
Video Duration: 9:38 minutes
This KnowledgeKnugget™ is part of instructor-led course (live and online classroom).
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 Excerpt
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:
- 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”.
- 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”.
- 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]
Kick-start Your Business Analyst Career
Books, eBooks, and Online Courses at a Reasonable Cost
Written for the aspiring Business Analyst and anyone tasked with defining the business needs, requirements, or user stories for a future IT solution.
Kick-start Your Business Analyst Career
Books, eBooks, and Online Courses at a Reasonable Cost
Written for the aspiring Business Analyst and anyone tasked with defining the business needs, requirements, or user stories for a future IT solution.