The hardest single part of building a software system is deciding precisely what to build. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. - Frederick P. Brooks
Requirements prioritization has been recognized as one of the most important decision activities in the requirements engineering activities.[10] But in my experience, it’s an area that seems to generate very little discussion among business analysts.
In Business Analysis and Requirements Engineering, the primary prioritization focus is on requirements. But what do we mean by requirements? Are we talking about detailed requirements, user stories, features, use cases, or something else that has been categorized as a set of requirements
?
One of things that I find interesting is that when you go and look at the development of many prioritization techniques, most of what is being prioritized in requirements
prioritization are requirements at a more abstract level than detailed
requirements. The focus is usually at the feature, function, user story, or equivalent level of abstraction rather than at the detailed
level of knowledge.
This page attempts to provide a fairly comprehensive overview of prioritization in the realm of business analysis. As such, it will go beyond requirements prioritization as a specific activity and looks at questions such as:
Prioritization is a seemingly simple concept that I think is among the core concerns of business analysis. But despite its seeming simplicity, I don't think it's that simple at all. The definitions for prioritization
seem relatively straight forward though. You can take your pick from definitions such as:
But both of those definitions rely on the concept of importance
. So what does importance mean?
important; consequence; significance. [3]
Which leads one to wonder what exactly is meant by significance, since that is a common way of defining importance?
So importance = significant and significant = important. So what does important mean?
We are still seeing a bit of circular logic here. But we are also seeing the concept of value, or worth, showing up again. So what does value
mean?
So maybe in the end, a workable definition of prioritization is to arrange or deal with in order of relative worth, utility, or importance
. At least as it applies to Business Analysis.
Now, some of you are probably rolling your eyes and wondering why I went through that whole exercise with the definitions above? The point is that even though we think of concepts like prioritization as self-evident and simple, they really aren’t. They are often vaguely defined and are based around concepts that are just as vaguely defined (like importance). The key point to understand is that the concept of prioritization you have in your head may not be the exact same one your stakeholders have, and sometimes those differences are important.
At its core, prioritization is about enabling good decision-making. On a project stakeholders might say, Why should I prioritize anything? I've told you what is needed, and none of it is negotiable!
But environments change. Goals change. Management changes. Change is almost always inevitable. Even if you have defined the requirements and all stakeholders have signed off; a solution has been designed; a level of effort (LOE) provided; and a budget approved and provided. Change can still happen. The question is how you deal with it.
Prioritization is about having the knowledge and being prepared to make intelligent, rational, and well-informed decisions when things change. When decisions need to made, it is often not obvious which choice is better, because often several aspects need to be taken into consideration.[12] For example, when the choice is between Feature 1 and Feature 2, stakeholders might choose Feature 1 as the best option. But when you factor in the cost to development the features, the impact on development time, and the ongoing support costs, that decision becomes may be much less clear.
Prioritization is about doing the analytical work ahead of time (as much as possible) so that when decisions have to be made, you already have the information you need to make the best decision. You may have even already made the decision, if the change was foreseeable. And if it wasn't, by prioritizing ahead of time you will have usually significantly reduced the work and time needed to enable the best decision to be made.
Among the many activities prioritization supports, the following is just a sample: [12]
The key point is that prioritization is a strategic process and should be treated as such. It should never be treated as an after-thought.
However, please note that if you are going to undertake a prioritization exercise the priority levels have to actually mean more than only the highest priority is going to happen in the next 10 years
. No matter what prioritization method you use, be sure that you actually implement more than just the highest level of priority items. If stakeholders consistently see that only the highest priority items are implemented, then soon they will stop believing that prioritization efforts mean anything other than implemented
or never going to happen
. And if that occurs, then either everything your clients prioritize will be the highest priority or they simply will no longer cooperate because they have lost confidence in the process. Why should they bother to participate in the process (both the prioritization process and the processes of problem identification and solution definition) when they know they are going to only get the bare minimum of what they prioritize? The only logical course on their part is to prioritize EVERYTHING as the highest level and at that point your process is broken, probably for as long as those stakeholders remain with the organization.
The following is a high-level process for prioritization. The main goal is to call out important things you should consider in your prioritization effort and to put them into a logical order. This does not describe a specific Prioritization technique, but rather covers the overall process that includes selecting a prioritization technique.
The first question you need to answer is what is the goal of any prioritization effort? Are you building an analysis plan? Analyzing stakeholders? Providing information for a development plan? Evaluating solution options?
Knowing the goal of your prioritization effort will drive such factors as:
So what are you prioritizing? The items you prioritize should be directly related to achieving your prioritization goal. If it is requirements, what types of requirements? Functional, non-functional, constraints? How are the requirements documented? UML models, user stories, detailed requirements? Different requirements may be better suited to different goals and different prioritization techniques may be more suited to different artifact types.
When you ask Business Analyst’s about prioritization, the discussion rarely seems to move beyond requirements prioritization. And while that is a critical part of the requirements engineering discipline of business analysis, it’s hardly the only situation in which prioritization is important to business analysts.
So what can a Business Analyst prioritize?
Most BA's I know work on more than one project at a time. Therefore, it is a good idea to prioritize your projects and to get agreement from you project managers and your direct supervisor / manager on that prioritization. Prioritizing your projects helps in managing your communications with the project teams and stakeholders you are working with, and ensures that when potential conflicts come up that there is already agreement on which project may need to accept less of your time or effort. But don’t get stuck thinking of this a simple ranking of priority from 1 to whatever. Prioritization of projects can change by the phase a project is in, the level of involvement you as a BA need to have for that phase, the amount of time you need to complete deliverables for those projects, and a number of other factors. So your discussion with your project managers and team manager might be when I am in the requirements phase, project X has a higher priority than project Y, but as soon as we move out of the requirements phase, project Y has a higher priority because of a need for greater interaction with the design team
.
One you are working on a project, potential project, business problem, or other analysis effort; it’s a very good practice to start by prioritizing the projects goals, objectives, and stakeholders involved in the effort.
Prioritizing these items in the project Context phase (or the Enterprise Analysis or similar phase) can help the business analyst(s) in devising the business analysis plan by considering each of the following:
What is the priority of each of the project goals (if there is more than one)? If that goal is broken into sub-goals, what is the priority of each of those? Knowing which goals are most important helps you as a business analyst allocate more time for analysis work. That time can be spent on elicitation, analysis, documentation, verification, and validation of the requirements that ensure those goals are met.
This can be somewhat controversial, but it is also a good idea to prioritize stakeholders. Both overall for project success (however that is going to be measured), and for individual goals and objectives. If you know which stakeholders are they highest priority for different aspects of the effort, then you can develop your analysis plan accordingly. You can also prioritize your response to feedback during requirements work. And lastly, it can help with your actual requirements plan, so that you can ensure that specific requirements activities are scheduled at such a time (and done in such a way) that gets the most value from the highest priority stakeholders.
Requirements Prioritization is what most BA's think of when they hear the term prioritization. Be sure to consider that requirements can be prioritized at many levels, not just the detailed level. You can prioritize user stories, use cases, features, functions, and every level of abstraction there is for requirements. And starting early at the highest level of abstraction (whether you call that level business requirements, stakeholder requirements, goals, or whatever) helps you focus your analytical work on the most important areas.
Prioritization and time-management skills are critical to actually being able to do your job effectively. Yet few BA’s think to consciously prioritize their work. They may say something like, I work on what the project manager / my supervisor tells me to work on
.
But what if stakeholders you need for a certain activity aren’t available when the PM wants you to focus on something? What if you have a (higher priority) task for one of your other projects that you need to work on when you are asked to work on something for another project?
Unless you prioritize your work products around multiple contexts (when something is due in the project plan, availability of resources, your other project obligations, your other work obligations, the amount of time available versus the amount of time required to do something, etc.) it is much easier to miss a delivery date, have a project manager schedule something that depends on your output when it won’t be available, or cause multiple other problems to arise.
Additionally, it is also a good idea to prioritize your time for knowledge acquisition when starting on a new project or endeavor. Should you for example focus more on understanding the current process, the current technology, or the current stakeholders? If a conceptual solution framework is already in place (such as when replacing a BA on a project), should you focus on understanding the new solution concept? You still need to learn about other aspects of the business and project work, but prioritizing your knowledge acquisition helps you be as effective as possible, as soon as possible, given the situation you are working in.
Theoretically, all of this should be part of your analysis plan. But it’s rarely spelled out and most of us are guilty of doing this “on-the-fly” or sub-consciously. I know I still rarely do this (even though I know I should).
In looking at the definitions in What is Prioritization
above, mote that all of the definitions above fail to address context. Important to whom? For what purpose? In what time period? Deriving value or worth from what? These are sometimes known as prioritization criteria or aspects, but I prefer the term context.
These are not unimportant questions. The problem is that most of us tend to think of prioritization as only having a single context. Usually that context is importance to project success
or importance to achieving sponsor happiness
. But something can be of the highest importance to project success (and thus high priority) without having to be done immediately. Or even in the next year. Or maybe it’s of highest priority to the sponsor’s definition of success, but not nearly so high a priority for the user’s definition or project success. Or the Legal departments.
So the key takeaway for me is that Business Analyst’s need to learn to think of prioritization within multiple contexts. The same thing can have different priorities in different contexts. And you as a BA need to know what those different contexts are, what the priority is within each context, and how priorities might change if the context changes. Or at a minimum, you need to know what contexts you have not considered when you prioritize something so that you know where you might have to do additional prioritization work if something changes.
The following are some of the more common prioritization contexts, although not a complete list.
You can’t really say how important something is if you don’t know the important for what
part, or what I call the purpose. This is the one everyone thinks about when considering priority, but they don’t always do it consciously. Is it for project success
? Well, you can often meet the project success criteria while making no one happy. Is it for sponsor happiness with the results
? That prioritizes based on some persons (usually one) success criteria. Is it to achieve the highest value
? Value by what measure? Value in whose consideration? A firm, a regulator, and a client may all see the value
delivered by an analysis effort in different ways. So be sure when you are prioritizing that you explicitly define the purpose for which you are prioritizing. And it’s often a good idea to do multiple prioritizations for multiple contexts to give you a better idea of the real priority of any given item.
The time and schedule aspect of prioritization is most commonly seen in iterative development processes. The items slotted into the next release are the highest priority for further analysis (the just enough
requirements detail idea).
This is also the way most of us prioritize our work. Whatever is due the soonest, based on whatever schedule you are considering, is whatever the highest priority is. As Business Analysts, unfortunately we often aren’t consulted when project schedules are defined. We often aren’t even consulted when analysis and requirements schedules are defined. We are simply told, you have X amount of time to get Y done. The fact that this leads to lower quality results often isn’t considered by stakeholders or project managers. And sometimes trying to argue for more time gets you labeled as lazy
or not a team player
. It sucks, but it’s the reality in some circumstances. And in those circumstances, your analysis work needs to be prioritized by due dates, even if that isn’t the best way to do something.
This same logic can apply for prioritization when certain features of your project solution have deadlines that vary. If Feature D needs Feature B in order to function, and Feature B is low priority from a purpose perspective, you will still need to focus work on Feature B in order to ensure Feature D can be deployed by its deadline.
Prioritization based on the resources context is prioritizing based on the availability of resources (people, systems, or other resources). If you know SME’s or high-priority stakeholders are only going to be available during a certain time period, you probably want to prioritize all activities that require those SME’s for that time frame. This may not be optimal for other prioritization contexts (value, quality, purpose, etc.), but it often trumps other contexts because having some involvement of those resources trumps having no involvement.
And don’t just limit this to human resources. Consider availability of resources such as testing environments, applications, and conference or meeting rooms (especially if you want to have workshops or similar activities).
The quality aspect of prioritization is the one that I think is among the most overlooked. It is explicitly recognized in the iron triangle
of project management (time, budget, quality) but rarely do I hear of prioritization by quality of expected results. Yet this should something every BA considers. Usually (not always), the more time you have to do something, the higher the quality of the results. But it’s also frequently true that the later in the analysis effort something is done, the higher the quality of the result (because you know more about the project, stakeholders, and context). So in cases where the quality of results are of higher importance, you may want to prioritize the amount of time or resources committed to that effort.
Value is the prioritization context that seems to be explicitly used most often by Agile
methodologies. This is the idea of prioritizing work by the highest value of the output. Of course, first you have to decide value by what calculation
and value to whom
. It’s those aspects of the value context that frequently get overlooked. And given that value
(however you choose to calculate it) can vary by stakeholder, prioritization by value is often among the more complex prioritization efforts to undertake.
Risk is another prioritization context that is common in Agile
methodologies. But it also has a central role in non-Agile processes like the Spiral development methodology. Generally, the idea is to prioritize the highest risk items first (or as most important) because they may drive important architectural decisions, or because the way they are addressed may impact the way you address other, more well understood, items.
Or you might focus on risk as a prioritization measure for specifying which items have the largest negative impact if they are not addressed. For example, the technology team may have a good idea of what solution is appropriate for a new regulatory requirement, how much it will likely cost, and how long it will take to develop. In some prioritization processes, this would push addressing this need further down the priority queue. But if the impact of NOT having a well-working technology solution in place for this regulatory requirement is to cease operations, it might be better to make this the top priority for development.
Or you can take the opposite approach and prioritize the lowest-risk activities the as the highest priority. This is especially true if you are not looking for significant or transformative results, but rather more predictable outputs. An example might be an investor is close to retirement and thus begins to prioritize their investments into lower-risk assets like money-market accounts and inflation-protected bonds. Or some continuous improvement processes where the goal is to predictably improve the current processes by eliminating waste or variability might prioritize on changes that have the lowest risk of NOT delivering the expected improvement.
This is prioritizing items simply by the cost in money or other resources to implement or achieve those items. Usually, the lower the cost, the higher the priority. But sometimes you take the reverse approach (highest costs = highest priority) because even small differences in estimated cost versus actual cost can have significant impacts on a development budget. Of course, it's rarely that simple and cost prioritization is usually considered along with a value focus that prioritization is done based on cost per value achieved basis.
The contexts listed above are not an all-inclusive list. The important thing for you as a BA is to be aware of the different contexts, and to realize that when you prioritize you will often have to do so across multiple contexts.Simple prioritization leads to simple analysis which can lead to too simple results.
When you prioritize, there should always be a goal or target audience of some sort in mind. If you are prioritizing business development opportunities, your target audience is likely senior management. If you are prioritizing requirements, your target audience is probably the project and development teams. But how well do you understand the user's needs and wants? And what if you have more than one customer who have different, or conflicting, needs?
If you are doing bespoke development and can talk directly to users, you often have a very good idea of what users want and the specific problem(s) that is being addressed. Prioritization in this case is usually much easier because you have actual users to interact with, managers to work with to make key decisions, and it's often possible to use deeply analytical prioritization techniques to ensure you are prioritizing the solution aspects (whatever they are) to best meet the target audiences goals and problems. The prioritization goal is usually management and/or user happiness with the solution.
But if you are prioritizing requirements for a market-focused solution, the situation is different. You rarely have direct users to talk to or a well-defined solution to solve. You may not even have a specific market you are targeting. In this case, prioritization becomes harder and the goals change. Instead of focusing on solution happiness, the prioritization goal is driven by factors such as time-to-market, sales amounts, feature parity with competing products, and similar factors. Rather than prioritizing for the needs of specific users, you are prioritizing for the needs and desires of as many potential users as possible. This in turn may drive not just the context that you prioritize within, but the techniques you choose to prioritize with.
Additionally, there is the question of knowing which stakeholders will need to be involved in the prioritization effort itself. Knowing the goal and context of the prioritization effort, and what is being prioritized, will largely drive who is involved. And knowing the stakeholders involved will influence what prioritization techniques you are likely to consider due to the type of output you need to meet to the prioritization goal, stakeholder availability (some prioritization techniques take more time than stakeholders may have availability), and stakeholder familiarity with various prioritization techniques.
Berender and Andrews included the table below in their book chapter [12] on the differences between the stakeholders involved in a bespoke development effort and a market-focused development effort, and I thought it was so useful I wanted to include it here:
| Facet | Bespoke Development | Market-Focused Development |
|---|---|---|
| Main Stakeholder | Customer organization | Developing organization |
| Users | Known or identifiable | Unknown, may not exist until product is on the market |
| Distance to users | Usually small | Usually large |
| Requirements Conception | Elicited, analyzed, validated | Invented (by market pull or technology push) |
| Lifecycle | One release, then maintenance | Several releases as long as there is market demand |
| Specific RE issues | Elicitation, modeling, validation, conflict resolution | Steady stream of requirements, prioritization, cost estimating, release planning |
| Primary goal | Compliance to specification | Time-to-market or market share capture |
| Measure of success | Satisfaction, acceptance | Sales, market share |
*Reproduced from Berender and Andrews [12], Table 4.2
Selecting the actual prioritization technique that are going to use is influenced by a number of factors. They include: [10]
In general, prioritization can result in one of three different types of results. They are:
Depending on the number of things to be prioritized, different techniques may be more or less appropriate. For some techniques, the amount of work required to prioritize a certain number of items scales up rapidly. For example, with the Analytical Hierarchy Process (AHP) you need to do about 45 comparative prioritization activities to prioritize 10 requirements. But if you have 50 requirements, you have to do over 1200 comparative prioritization activities.
In addition to what is being prioritized, an important factor is what is the abstraction level of the items you are prioritizing and their related information? At higher levels of abstraction there are fewer dependencies that you may have to figure into your prioritization analysis.
Another question is whether you are prioritizing at a single-level of abstraction (only detailed requirements for example), or at multiple levels of abstraction. Most techniques are only geared to prioritizing one level of abstraction.
The number of stakeholders who will be taking part in the prioritization exercise is a critical factor. The more people involved, the more complex the process tends to be and more appropriate some techniques may become.
The question of how often you expect to re-prioritize becomes important because some prioritization techniques, especially those that produce ratio-scale outputs, require extensive work to prioritize newly introduced items. In the case of most ratio-scale techniques, it can mean running the entire prioritization process again. And with techniques such as cumulative voting, re-running the prioritization process would introduce a substantial risk of gaming
the process by stakeholders.
Depending on the answers to the questions above, you might use different prioritization techniques. The table below gives a recommendation for which technique may be the best choice depending on the number of items you need to prioritize and the type of result you need. Items with (*) after them support multiple levels of abstraction. Those without should only be used when all items being prioritized are at the same level of abstraction.
| Nominal Scale | Ordinal Scale | Ratio Scale | |
|---|---|---|---|
| Small (1-20 items) |
|
|
|
| Medium (21-50 items) |
|
|
|
| Large (51-99 items) |
|
Ranking |
|
| Extra Large (100+ items) |
|
Hierarchical Cumulative Voting(*) |
*** This table is based on a combination of research I have read, my own experience, and some educated guesses
on my part. Do not take it as gospel, it's just something to help you make a decision. Much of the info on the research side came from. [11]
The following are common prioritization techniques. Those that are links have separate pages in the wiki that describe them in detail.
I include this step last because it's a good idea to know why, what, and how you are going to prioritize something before you decide when. This is because depending on the technique involved and the stakeholders involved in the prioritization process you may need varying amounts of time and involvement. And you can't schedule that time well if you don't know those things before-hand.
Part of the question of when is how many times, or how often? Do you do a prioritization as a one off when requirements are finalized? Do you schedule several sessions? The following are all possible times you could schedule prioritization sessions during a project, and what for:
In general, the best practice is for prioritization to be an ongoing, iterative process. Whether prioritizing project work, your personal work tasks, or anything else. The problem with that is that formal prioritization work can be time consuming and ongoing prioritization work is usually only possible with the lightest of prioritization techniques.
The effort involved in a prioritization effort is often of little value unless the results of the effort are communicated and shared with all stakeholders who should be informed. This not only educates them on the results and prepares them for future decision-making, but it also enables a validation of the prioritization process if stakeholders have questions about the results. Those questions can often point to errors, false assumptions, or incorrect evaluations of various factors that went into the prioritization process. And this in turn allows for the prioritization work to be better explained or fixed before it is used for decision-making.