Planning the Project

The desired outcome of planning a project is a plan that includes a scope, a schedule, a budget, a risk management plan, and a commitment and approval from all stakeholders. With an agreed-upon project plan, you want to progress with analysis, design, development, testing, and eventually delivery.

You can reduce risk by using an iterative development method. Iterations let you demonstrate a partly working product at the end of each iteration and act on feedback from that demonstration. Therefore, the plan provides an overall shape and is subject to review and refinement before the start of each iteration.

In this topic

Gathering and Modeling the Requirements

Creating Incremental Requirements

Entering and Editing Requirements

Prioritizing Requirements

Representatives of the business stakeholders and the development team should work together to prioritize requirements so that the subsequent use case decompositon can be assigned to iterations. Typically, you do this in a meeting, where you share or project the Office Excel view of the Open Requirements query.

Some guidelines on prioritization

Many detailed schemes exist for prioritization. We will examine some of these when we consider iteration planning. For now, at the project level, we include some guidelines that may be useful to help manage risk and optimize added value.

  1. Prioritize minimal end-to-end scenarios.

    Aim to achieve a simple end-to-end scenario as early in the project as possible. Later, add more features to the different parts of the scenario. This practice ensures that the principal functions of the platform and the principal ideas in the requirements are tried early.

    By contrast, do not divide the schedule according to the architecture. A schedule that completes the database, then the business logic, and then the user interface will probably require a great deal of rework to integrate the parts at the end. In the same manner, a horizontal split such as {sales component; warehouse component; payment component} is not recommended. It would probably produce a wonderful system for selling on the Web but run out of time before the business has a means of getting money from its customers. Complete components can be scheduled for later iterations only if they are truly optional add-ons.

  2. Prioritize technical risk.

    If a requirement includes a technically risky element, develop it early in the schedule. Take a “fail early” approach to risk. If something cannot be accomplished, you want to know this early in the project so that it can be canceled or replaced with an alternative approach. So prioritize technically risky requirements into early iterations.

  3. Prioritize reduction of uncertainty.

    The business stakeholders will not be sure about some requirements. It is difficult to predict what product behavior will work best in the business context. Prioritize work that is likely to reduce the uncertainties. This can often be achieved by developing a simpler version of the scenario with which users can experiment. Defer the full scenario to a later iteration, in which the results of these experiments can be considered.

  4. Prioritize highly valuable requirements.

    If possible, try to establish an opportunity-cost-of-delay function for each scenario. Use these to determine the requirements that can potentially bring more value to the customers earlier. Prioritize these requirements for development of use cases that are to be put into earlier iterations. This may buy you the option of releasing a partial product early.

  5. Group requirements that are common to multiple personas.

    If you have requirements that have utility for two or more personas, group these together. Rank them by the number of personas that require the scenario. Prioritize the requirements that apply to a larger number of personas into early iterations.

  6. Rank personas.

    Personas represent market segments or user groups. Marketing people or business owners should be able to articulate the priority of such segments or groups based on utility to be delivered or the value of the segment. If segments or user groups can be ranked in priority, show this by listing the personas for each segment by rank. Identify the requirements for the highest ranked personas, and prioritize these into earlier iterations in the schedule.

In general, we want to prioritize the reduction of risk because of the possibility of failure. We want to prioritize common functionality because it is likely to be required and unlikely to change. We want to prioritize more valuable requirements. We want to enable the option for early release of the product to a subset of personas by prioritizing all requirements that are required to satisfy the needs of any one persona.

Revising Requirements

Revisit this activity before each iteration to consider revised and new requirements, revised priorities, and revised estimates. There will be more revisions in the first few iterations.

See Also