Google





First Things First

Luc K. Richard
December 7, 2004

Every software development project is bound by some constraints, and more often than not, those constraints include time. In today's competitive market, there is a definite first-mover advantage, and the first company to release its product has by far the best chance of becoming the market leader.

As a result, you must have some tools in your software development process that help you proactively deal with such time constraints. You, as a project manager, must be able to determine ahead of time which features must make it in the product for the customer to accept it, and which can be delivered in the next release. If you're development schedule is aggressive, you're inevitably going to cut some features. The question is, are you cutting features that will cost you a sale?

Must-Have versus Nice-To-Have

Customers are not always reasonable when asked to prioritize requirements, and generally speaking, they'll qualify everything as a must-have. They normally do not understand or care about the pressure that comes from the project schedule. They've agreed to pay a price for a solution, and they want that solution to do everything they can imagine.

If you ask customers which features are less important or which features could be delayed until the next release, you'll get the knee-jerk response that they need it all, and they need it now - actually, they'll probably reply they needed it yesterday. However, if you try to understand their use of the system, perhaps you'll discover certain bells and whistles they don't necessarily need, and that features X, Y or Z won’t be required until at least a year from now. If scheduling these features for the next release won’t cost you a sale and allow you to gain a first-mover advantage, then don't be afraid to do so.

Prioritization Scales

There are different ways to qualify requirements as must-haves and nice-to-haves. One popular way is to rate requirements on a scale of 1-10, and state that all requirements that fall in the 1-5 category must be in this release, and those that fall between 6 and 10 will only be included if time permits it.

Another effective method – the one I personally prefer – is to simply qualify requirements as being “Committed”, “Time Permitting”, or for a “Future Release”. This offers a few advantages over the simple 1-10 method.

First, it’s very hard to determine the difference between a 1 and a 2, or a 2 and a 3. And it’s somewhat pointless. If the requirement has been committed to a customer and truly represents a show stopper in the acceptance of the product, then there's no need to prioritize it other than stating it’s a must-have.

Second, requirements that are definitely out of this release and scheduled for the next one are still clearly documented in the Software Requirements Specification (SRS). This allows readers of the SRS to clearly understand what's in this release, and what's not. Documenting “Future Release” requirements demonstrates you're trying to scrub requirements to optimize Time-To-Market instead of trying to simply sweep them under the rug.

To make this method as effective as possible, I prefer to go one step further and assign integers to “Time Permitting” requirements so that developers know what to focus on once all the “Committed” features have been developed and tested. These integers should be determined based on the value the feature brings to the customer, and its development cost.

Setting Priorities According to Value and Cost

The priority of “Time Permitting” features must be related to its value and its cost. Needless to say that if two features offer the same value to your customers, you're better off implementing one that will cost you less. Generally speaking, in the software industry, cost is closely related to the time it takes to develop and test a feature. Therefore, before prioritizing requirements, you must be aware of the value this feature brings to the customer, and how long it will take your team to fully implement, integrate, and test the additional functionality.

This article will not get in the details of assessing the value of features or sizing them. However, for illustrative purposes, let’s look at the following example.

Imaging a Web-based application whose main role is to accept customer orders online. Obviously, the core functionality such as the ability to authenticate users, track product quantities and accept payment information would be “Committed” requirements because without these basic features, the customer would never accept the product. Since all of these requirements must be included in the first release of this product, there's no need to prioritize them relative to each other. Simply stating that these features are “Committed” is appropriate.

Still, there is a need to prioritize the following “Time Permitting” features using integers.

After analyzing the expected value and cost of the above features, the following table was created, and the priority of each individual requirement was calculated.

ID Feature Value Cost Priority
01 The customer must be able to track the status of his/her shipment online using a unique shipment identifier. Medium Medium 2
02 The system must confirm the customer’s order via e-mail. High Medium 1
03 The system must be able to display the price of the product in the customer’s currency of choice. Low High 3

This table clearly indicates that once developers have implemented and tested the “Committed” features, they should start implementing feature 02, followed by feature 01. If there was enough time left in the project schedule, feature 03 would also be implemented, but since it brings little value to the customer and is relatively expensive, this feature could be immediately be reclassified as a “Future Release” requirement.

Once all the “Time Permitting” features have been prioritized, document their priority in the SRS and get it signed-off. This functional blue print can then be used to finalize the project schedule and get the developers started.

This article was originally published on www.gantthead.com.