Many software development teams today are faced with developing twice as much in half the time for even less budget. The risks this imposes to the business expecting and needing the software is much too high. A mechanism to deal with the risk is to rank and then prioritize requirements. Ranking requirements puts them in order of preference. Prioritization puts requirements in sequence of implementation after many considerations such as need, technical implementation, overall business strategy, etc. Some equate ranking and prioritization but they are different.
Many times stakeholders rank a list of requirements as high , medium or the lonely low. Given a list of one hundred requirements how many of them are rated as high? Through the decades the numbers I have heard range from 93% to 99% as rated high. I’m told there are a few ranked medium and there has to be at least one of low priority. When asked how useful the ranking is they admit “not very”. When asked why they go through the effort to rank if it is not very useful many reply “Prioritization is a formality that project management imposes”. When asked what the definition of “high” is, what is “medium” and what constitutes “low” many can’t answer the question. What criteria does a requirement have that makes it “high” instead of “medium”? The answer I get is silence and a look to heaven hoping that a Devine answer might come forward. Once a brave sole confided that the reason all requirements are “high” is because they ask the business person who stated the requirement what the priority should be. The business person would say “If it comes out of my mouth it is high priority. Don’t ask such silly questions of me again”. I said “Oh, I think I see the problem here”…
As you know proper ranking and prioritization is necessary for determining an incremental release strategy and for making trade-off decisions during development if necessary. It is difficult indeed when everything is high priority.
- Try to rank and prioritize requirements that have the same level of abstraction or requirements of the same type.
- If the ranking still has to be textural then maybe “must have”, “should have” and “nice to have” might be better.
- “Must Have” means core functionality as well as discretionary functionality determined to be critical such that deployment would be delayed if development delays occur. If a business person indicates that a requirement is a “must have” but indicates they don’t want to wait on its deployment if issues arise just prioritized the requirement as a “should have”. For an order processing system Create Order is core and therefore does not need ranking and prioritization. Track Order is most likely discretionary, except to the person who stated it as a requirement, and therefore needs to be ranked before it can be prioritized.
- “Should Have” means non-core, discretionary functionality that should be deployed in the increment or sprint it was assigned but if not ready deployment would not be delayed. Track Order is probably a “should have”.
- “Nice to Have” , normally the loneliest of the three, means exactly that, nice to have in the increment or sprint it was assigned but definitely trade it off first to another increment or sprint if necessary. Getting PDA notification when order status changes might be a nice to have. I personally would rank that as a “should have” but if implementation would be help up I can wait on this.
- Another idea is to rank the discretionary functionality based on “spend a buck” across a set of non-core, discretionary requirements. It is best if a selected set of business people “spend a buck” so the average or a weighted average can be determined. If 25 requirements require ranking prior to prioritization you might get 5 business people to allocate their 100 “pennies” to the 25 requirements. If someone spends 25 cents on let’s say 4 requirements and then says “I need more pennies, I have already run out” then you ask them to reallocate their 100 pennies across the 25 requirements.