22 Prioritization
Unless you have enough staff to work on everything all at once, you need to prioritize things. There are a number of factors that go into prioritization, and we go into those below. It would be nice if there was a formula we could apply on those factors and just come up with a sorted ordering, but there’s not. In each business circumstance, you have to weigh the factors against each other to come up with each task’s prioritization, each module’s prioritization, or each individual requirement’s prioritization. Those are ordered from most likely prioritization scheme to least likely.
When you write a requirements specification, you’ll usually include the priorities. Some companies use High, Medium, and Low. Some also add Emergency, Eventually, and even Maybe or the equivalent. Other companies label things as First priority, Second priorities, and so on. Still other companies give items a priority score, 1 to 100, 1 to 10, 1 to 5, or whatever number they find convenient. If your documentation uses numbered priorities, make sure people know what the numbers mean.
22.1. Urgency
Urgency is often the most important prioritization concern. If it’s December 1st, and there’s a year-end piece of work that needs to be done as well as something that has to be done for tax time (usually April 15th in the US), then clearly the year-end work has a higher urgency. So, one way to sort out urgency is by using due dates. However, that won’t always do the job, especially when things don’t have specific due dates. There can also be chain-of-command issues. For instance, if your boss wants Thing A done, somebody else’s boss wants Thing B done, and the CEO wants Thing C done, then political or chain-of-command issues say that the prioritized order is Thing C (because the CEO outranks your boss), Thing A (because you answer to your boss), and finally Thing B. There are also the “what if” urgency issues. What if the item under consideration doesn’t happen? What if it does?
22.2. Stability
Some items to be done are very stable, and some are very volatile, and most are somewhere in-between. Normally, it’s best to prioritize the stable ones first. Here’s an example why: Let’s say we have Thing A to do, which is very stable, and Thing B to do, which is very volatile. If we do Thing A now (and by “do”, we can mean anything between gathering the requirements and delivering the release containing that Thing), in the next iteration (be that iteration a sprint, a release, or any other scheduling term), we can get to Thing B. But, if we do the volatile Thing B first, in the next iteration, we may very well be working on Thing B again. In the worst case, Thing A will never get done.
22.3. Certainty
When we first start gathering requirements, in the worst case, we don’t know anything about anything, and we know that we don’t know anything about anything. (Ok, there is an ever worse case, in which we think we know, but we’re wrong, but let’s leave that one out of the consideration for now.) As we do our research, and possibly some tests or experiments, we come to believe that some of the requirements are rather certain, and some remain rather questionable. The more certainty we have about a requirement, the more priority it should get. You don’t want to release the requirements for an airport, only to find out after it has been built that you needed an aircraft carrier.
Some companies use the statuses of Ready and Not Ready. Some have a few more categories: WAG (Wild Guess), SWAG (Semi-scientific Wild Guess), Almost Certain, and Certain. Others (again) use 1 to 100, 1 to 10, or 1 to 5. Again, if you use numbers, make sure that people know what the numbers mean.
22.4. Size
The size, or estimated resource requirement, of a task is often measured in hours, man-hours, man-days, or man-months. (Those are the terms used, and those terms are generally considered ungendered.) Some companies use a “work unit”, where the conversion between work units and man-hours is some constant or fuzzy constant particular to that company. (In Sheldon’s company, that’s 2-3 hours for time-and-expenses contracts and the price of 2½ hours for a fixed-price contract.) Some companies use points. Points are different than work units, in that a 2-point item takes longer to do than a 1-point item, but not necessarily twice as long. Some companies use XXS, XS, S, M, L, XL, and XXL. Often, the smaller items are prioritized ahead of the larger ones, so that the group can show the maximum number of items as completed at any time.
22.5. Benefit — Cost
Weighing cost against benefit can be important. Sometimes this is Benefit less Cost, either as a dollar amount, some other amount, or some immeasurable quantity. Sometimes this is the Cost/Benefit Ratio, measured as Benefit divided by Cost. Sometimes this is just a billable number. Note that Benefit can also be stopping a continuing loss or just improving something. Often, you (or the project, or at least the project manager) will want to get the greatest possible benefit in the shortest possible time. That affects prioritization rather directly. When Benefit-Cost can be expressed numerically, tasks become easy to sort into priority order.
22.6. Reliance
Oftentimes, one module will rely on another being done. In such cases, the relied-upon module must be prioritized before the reliant one.
22.7. Waterfall
Remember that in a Waterfall project, there will often be deliveries before the final one, often having version numbers starting at 0.1 to indicate pre-release copies. All of these prioritization rules apply, even though the final product is what counts the most.
22.8. Agile
In an Agile product, there are either continuous deliveries, or a distinct set of scheduled releases. In an Agile project, all of these rules apply all the time, because it matters which release (especially in sprint-based Agile projects) the feature, fix, or improvement will get into.
22.9. Spiral
In a Spiral project, you’re most often dealing with a set delivery date, such as having a project ready to sell at a specific trade show. Prioritization becomes a matter of deciding the feature set. For instance, you may decide on 100 new features, but only 50 can be engineered into the product. Not only do you need to prioritize directly to determine which features are in the release and which will have to wait, but you also have to decide which features work well with the others to make a complete suite of related features. So, some features will be prioritized individually, and some will be prioritized in a group.
22.10. Removals
If something is to be removed from a project, that is often prioritized last. Often the real reason to remove something from a product is simply to make future maintenance less expensive.
22.11. Discussion Questions
- Without looking at the list here, or elsewhere, can you make a list of items for consideration in prioritization?
- Keeping in mind that this will actually vary from project to project, can you order your list from generally most important to generally least important in doing prioritization?
