Prioritizing the Requirements
| One problem with requirements is that there are always too many of them. Prioritizing gives you a way to choose which ones to implement in which versions of the product. Decisions about prioritization are complex because they involve different factors and these factors are often in conflict with each other. Also, because the various stakeholders probably have different goals, it may prove difficult to reach agreement about priorities. To prioritize requirements, you can group them together into logical (to you) groups. These groups are then prioritized as a unit, on the assumption that all the composing requirements have the same priority as the group as a whole. A group might be a use case, a component, a feature, or any other grouping of requirements that it makes sense to prioritize as a unit instead of treating them individually.
You can group requirements together and prioritize them as a unit. To make it easier to read, for the next few pages, we use the term "requirements" to mean "groups of requirements," "features," "product use cases," or any other grouping you care to use. Prioritization FactorsThe following factors commonly affect prioritization decisions:
Not all of these factors are relevant to every project, and the relative importance of each factor differs for each project. Within a project, the relative importance of the factors is not the same for all of the stakeholders. Given this combinatorial complexity, you need some kind of agreed-upon prioritization procedure to provide a way of making choices. Part of that procedure is to determine when you will make prioritization decisions. When to PrioritizeHow soon should you make choices? As soon as you understand what you have to choose from. The more visible you make your knowledge, the more chances you have to make and help others make informed choices. If your requirements have a well-organized structure, you can prioritize them early in your project. The process described in this book includes a project blastoff. You use this meeting to assess your level of knowledge about the contents of the first eight sections of the requirements specification template. Build a work context model and partition it using business events. At that point, because you have some identifiable pieces, you can do a rough prioritization and assign a priority rating to each business use casesomething like "high," "medium," and "low" will work fine for the moment. You can use the results of this prioritization to decide which parts of the business to investigate first. In addition, you can use this first prioritization to guide your version planning. When you start to write atomic requirements, you should progressively consider whether to prioritize them. If any requirements obviously have low value, then tag them as such. Use the customer satisfaction and customer dissatisfaction ratings, discussed in the previous section, to help other people make choices. Part of the reason for progressive prioritization is expectation management. Your stakeholders often assume the term "requirements" means these capabilities will definitely be implemented. "Requirements" are really desires or wishes that we need to understand well enough to decide whether to implement them. For example, we might have a requirement that is really high priority but, due to a mixture of constraints, we cannot meet its fit criterion 100 percent. However, we do have a solution that will fit the fit criterion 85 percent.
Your stakeholders often assume the term "requirements" means these capabilities will definitely be implemented. "Requirements" are really desires or wishes that we need to understand well enough to decide whether to implement them. If you have been progressively prioritizing throughout the project, people are able to accept such compromises without feeling cheated. Prioritization prepares stakeholders for the fact you cannot implement all the requirements. You can use any of a number of procedures to prioritize your requirements. We have already talked about customer satisfaction and dissatisfaction as a way of understanding the values people put on requirements. These ratings can provide input for deciding on and assigning priority ratings to the requirements. Requirement Priority GradingYou can grade your requirement priority however it suits your way of working. A common way of grading requirements is "high," "medium," and "low." But you can use any other grading that suits you. For example, some people grade requirements by release or version number: R1, R2, R3, and so on. The idea is that the R1 requirements are the highest priority and are intended to appear in the first release, the R2 requirements appear in the second release, and so on. But suppose that after you have tagged the requirements by release, you discover you have too many requirements in the R1 category. At that point you need to prioritize the R1 requirements into high, medium, and low categories. The idea of sorting the requirements into prioritization categories is often referred to as triage. This term (from the French verb trier, meaning "to sort") comes from the field of medicine. It was first adopted during the Napoleonic wars when field hospitals were not capable of treating all soldiers who had been wounded. The doctors used triage to place the patients into one of three categories:
Due to scarce medical resources, the doctors treated the third group only. The idea of triage can be used in project work using the categories:
Prioritization SpreadsheetA prioritization spreadsheet (Figure 14.6) enables you to prioritize the overflow requirements. Ideally, and especially if you have done a good job on progressive prioritization, these requirements will fit into the medium-priority (would like if possible) category. In other words, you have been able to fit all the high-priority requirements into your budget. If this is not the case, then prioritize the high-priority requirements and either drop the medium- and low-priority requirements or tag them for future releases. Figure 14.6.This prioritization spreadsheet is downloadable from www.volere.co.uk. 
Earlier in this chapter, we identified seven prioritization factors (or you may use any other prioritization factors relevant to your project). On our spreadsheet (see Figure 14.6), we have limited the number of factors to four. Trying to manage more than four prioritization factors makes it difficult, if not impossible, to agree a weighting system. The "% Weight Applied" column shows the percentage importance assigned to each factor. You arrive at this percentage weight by stakeholder discussion and voting. The percentage weights for all factors must total 100 percent. In column 1, list the requirements you want to prioritize. These might be atomic requirements or clusters of requirements represented by product use cases, features, or business use cases. Give each requirement/factor combination a score out of 10. This score reflects the positive contribution to the factor made by this requirement. For example, for requirement 1, we assigned a score of 2 for the first factor because we believe that it does not make a very positive contribution to the "Value to Customer" attribute. The same requirement scores a 7 on the "Value to Business" attribute, because it does make a positive contribution to our business. The score for minimizing the cost of implementation is 3; we think this requirement is relatively expensive to implement. It scored an 8 in terms of its ease of implementation, reflecting the relative simplicity of implementing this requirement. For each score, the spreadsheet calculates a weighted score by applying the percent weight for that factor. The priority rating for the requirement is calculated as the total of the weighted scores for the requirement. You may use a variety of voting systems to arrive at the weights for the factors and the scores for each requirement. Of course, the spreadsheet is merely a vehicle for enabling a group of stakeholders to arrive at a consensus when prioritizing the requirements. By making complex situations more visible, you make it possible for people to communicate their interests, to appreciate other individuals' opinions, and to negotiate. |
EAN: 2147483647
Pages: 371