- functions first, remembering that "value" has many dimensions: fiscal value (income or cost savings to the system consumer or sponsor), political value (reassuring a critic or rewarding an ally), and morale value (bits that are rewarding for the team).
- Which are the most expensive functions? Delay implementation of functions that are high in people or financial cost to reduce expenditures if a project is paused or cancelled. This approach allows an expensive function to be deferred easily if project resources become constrained.
- Which functions facilitate testing? Consider how the system will be integrated and tested, then partition and order the build to support these activities. If your system must store and access data, building store facilities first makes it easier to test access functions later. Testing early assures that more time is available to make schedule, scope, and resource adjustments if problems are detected.
- What decisions can be safely delayed? When it isn't necessary to immediately commit to a course of action for some aspect of a system, consider delaying that part of the system until more information is available. This approach allows the decision to benefit from more information and reduces the rework required as we learn more in the course of the project.
- What functions comprise the minimum acceptable product? Feature sets are like an onion because they tend to have many layers. One of the advantages of an effective agile process is that it produces a working product-after each iteration (layer). Sequencing functionality so that early iterations produce a valuable product makes it easier for a project to respond to later schedule or resource developments by declaring victory for the current version of the product and deferring unrealized functionality to "the next version."
You probably noticed potential conflicts among the suggestions above. Some high-risk features may also be high cost, suggesting they should be done near the front of the schedule to make sure they are doable. At the same time, I suggest scheduling them later to defer spending.
Some high-value functions, which we might typically want to develop first, may need most of the system to be completed to successfully implement and test, meaning they must be implemented last. Deciding how to balance these considerations and the best way to sequence the build can be a complex and subjective process; however, the product and project will both benefit from a thoughtful loading effort.
The all-too-common alternative is a mindless sequence to the build that is needlessly inflexible and difficult to manage, making it hard to take effective action if it becomes necessary to throw cargo overboard during the project. By taking a little time up front to consider how to load the project cargo, we increase the odds of reaching port with goods to deliver-even when the sailing is not smooth!