Number 5 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.”

1. Short-change Time Spent on Software Requirements or Don’t do Them at All
2. Don’t Listen to Your Customer’s Needs
3. Don’t use Models
4. Use Weasel Words
5. Don’t Prioritize Requirements
6. Don’t  Baseline and Change Control Requirements
7. Don’t do Requirements Traceability

You have concise and unambiguous requirements, derived from multiple types of models giving multiple views, all based on accurate and thorough elicitation time spent with customer business and subject matter experts. Can you still shoot yourself in the foot before development starts? Absolutely! You have to build the right product before you can begin to build the product right. And building the right product must be done in the context of an ever changing business environment. Change happens.  It is a natural occurrence. It can be your friend or your enemy depending on your preparation. There are two main ways of dealing with change, requirements prioritization and change management. I will deal with the former in this blog and the latter in my next blog in this series.

Why prioritize requirements?  Here is Karl Wiegers’ perspective from First Things First: Prioritizing Requirements:

“Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions.

One characteristic of excellent requirements is that they are explicitly prioritized. When customer expectations are high, timelines are short, and resources are limited, you want to make sure the product contains the most essential functions. Establishing each chunk of functionality’s relative importance lets you sequence construction to provide the greatest product value at the lowest cost. Customers and developers must collaborate on requirements prioritization. Developers do not always know which requirements are most important to the customers, and customers cannot judge the cost and technical difficulty associated with specific requirements.

A project manager has to balance the project scope against the constraints of schedule, budget, staff resources, and quality goals. One balancing strategy is to drop or defer low priority requirements to a later release when you accept new, higher priority requirements or other project conditions change. If customers don’t differentiate their requirements by importance and urgency, the project manager must make these trade-off decisions. Because customers may not agree with the project manager’s decisions, they must indicate which requirements are critical and which can wait. Establish priorities early in the project, while you have more options available for achieving a successful project outcome.

It’s difficult enough to get one customer to decide which of his or her requirements are most important; gaining agreement among multiple customers with diverse expectations is even more challenging. People naturally have their own interests at heart and they aren’t always willing to compromise their needs for someone else’s benefit. However, making such priority decisions is one of the customer’s responsibilities in the customer-developer partnership.

Customers prioritize requirements initially from the perspective of how valuable each one is to them. Once a developer points out the cost, technical risk, or other trade-offs associated with a specific requirement, though, the customers might decide it isn’t as essential as they thought. The developers might also determine that certain lower priority functions should be implemented early on because of their impact on the product architecture. When setting priorities, you need to balance the business benefit that each function provides against its cost and any implications it has for the product’s architectural foundation future evolution.”

One of the tenets of the agile project management process, Scrum, is delivering the highest value features to the customer first. This requires prioritization of requirements.

There are several prioritization techniques. The best prioritization, regardless of the specific technique, will always rank software requirements according to a comprehensive set of business value attributes. The elements in the set and their relative importance will vary from customer to customer and over time.  Here are some possible business value attributes: NPV (Net Present Value), IRR (Internal Rate of Return), profit, market share, alignment to corporate strategy, competitive positioning, architectural positioning, internal or external strategic political objectives.

Here are some common techniques. The light-weight techniques do not require a tool and are the most common. The medium-weight and heavy-weight techniques are most often used with a tool.

1. MoSCoW

The capital letters in MoSCoW stand for:

• M – MUST have this.
• S – SHOULD have this if at all possible.
• C – COULD have this if it does not affect anything else.
• W – WON’T have this time but WOULD like in the future.

Explanation taken from Wikipedia entry for MoSCoW:

“All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the M, S and C requirements but the S and C requirements will be the first to go if the delivery timescale looks threatened.

The plain English meaning of the MoSCoW words has value in getting customers to understand what they are doing during prioritization in a way that other ways of attaching priority, like high, medium and low, do not.

Must have

Requirements labeled as MUST have to be included in the current delivery timebox in order for it to be a success. If even one MUST requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from MUST, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important).

Should have

SHOULDrequirements are also critical to the success of the project, but are not necessary for delivery in the current delivery timebox. SHOULD requirements are as important as MUST, although SHOULDrequirements are often not as time-critical or have workarounds, allowing another way of satisfying the requirement, so can be held back until a future delivery timebox.

Could have

Requirements labeled as COULD are less critical and often seen as nice to have. A few easily satisfied COULD requirements in a delivery can increase customer satisfaction for little development cost.

Won’t have (but Would like)

WON’T requirements are either the least-critical, lowest-payback items, or not appropriate at that time. As a result, WON’T requirements are not planned into the schedule for the delivery timebox. WON’Trequirements are either dropped or reconsidered for inclusion in later timeboxes. This, however doesn’t make them any less important.

Sometimes this is described simply as “Would like to have” in the future, this however leaves some ambiguity in the minds of the users as to its priority compared to the other marks.”

2. Prioritization Poker

A simpler variant of Planning Poker applied to software requirements prioritization. It is a consensus-based game technique. Playing cards are given to the stakeholders or their delegates and marked with Must/Should/Could/Won’t or a simple numerical ranking. A variation can include distributing the cards non-uniformly if some of the stakeholders have a greater say in the matter. A hand is played for each requirement (or group of requirements).

3. $100 (aka 100 point) Method

This is another game-based technique. All stakeholders or their delegates have 100 dollars to spend on requirements that they would like in the release. They each “buy” the requirements they want up to $100 worth. The requirements are then ranked by how many total dollars the stakeholders wanted to pay.

4. Cost Value Method

Each requirement is measured by 2 factors: a business value attribute and a cost to develop. For example, the business value attribute could be profit and could be ranked using the $100 Method and the cost to develop could be ranked with a high-level estimate of difficulty to implement and test. This high level estimate could be determined by Planning Poker, for example, or the formal Wide Band Delphi technique that it is based on. Cost Value Method can be done using an AHP tool for large, complex systems.

5. AHP (Analytic Hierarchy Process)

The Analytic Hierarchy Process (AHP) is a structured technique for dealing with complex decisions. If applied to software requirements prioritization, the hierarchy represents a structured decomposition of the requirements from business objectives at the top to features in the middle to requirements at the bottom. There can be one or more hierarchies, each being a different view (e.g. profit, cost) of the requirements with its own business value attribute as the metric.  The total value of the system is determined. Each level must add up to that value and a parent node is the sum of its children.

For example, in the diagram below, profit is the business value attribute with a projected total value of 25 million dollars. (Ctrl-Left Mouse on the diagram to view a larger copy in a new window). All level 2 (business objectives) sum to 25 million. All level 3 (features) sum to 25 million. All level 4 (requirements) sum to 25 million.

Software requirements prioritization helps the project team build the right product. It helps the team resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions.

For extra reading:

Karl Wiegers — First Things First: Prioritizing Requirements

Luke Hohmann – 3 part blog series (within Agile paradigm)

• Why Prioritizing Your Product Backlog for ROI Doesn’t Work (Part 1 of 3)
• Developing Attributes for Product Backlog Prioritization (Part 2 of 3)
• Prioritizing for Profit (Part 3 of 3)

Don’t shoot yourself in the foot on your next project! Resolve today to prioritize your software requirements by business value. The choice is yours.

Next time I will look at “Don’t Baseline and Change Control Requirements”