Arranging Requirements into a Product Plan

After you analyze your customer requirements sufficiently to understand what the product should do, you must work out a plan to implement the product. Or, for an existing product, you must work out what functionality is missing and work out a plan for making the changes. But the requirements do not automatically tell you the plan.

This topic outlines a method of obtaining a plan, starting from a set of requirements. This is just one method among a variety that will work on Visual Studio, and you should adapt it so that it suits your needs.

In this topic

Requirements

Use Case Decomposition

Assign Use Cases to Iterations

Product Planning

Iteration Planning

Requirements

Use Case Decomposition

To help you arrange the requirements into iterations it becomes necessary to decompose the requirements into smaller steps or use cases describing the steps.

Storyboards often help with this activity. A storyboard is a sequence of pictures that illustrate the scenario. UML activity diagrams are useful for showing alternative paths, and UML sequence diagrams can help you discuss interactions between several actors. After you use these tools to analyze a scenario, you can enter the decomposed scenarios into Team Explorer. This lets you link test cases to the scenarios and thereby ensure that the requirements have been satisfied. For more information, see UML Activity Diagrams: Guidelines and UML Sequence Diagrams: Guidelines.

In this example walkthrough, you enter a set of customer requirements in the form of a small tree of use cases.  To make it clear which work item is a requirement and which is a use case, we will use the moniker Requirement # for a requirement work item and Use Case # for a use case work item.

To open the requirements tree in Excel or Project

  1. In Team Explorer, open a GovDev for TFS 2010 v1.0 project.

  2. Expand Work Items, expand Team Queries, expand Project Management, and run Work Breakdown from Requirements. by opening it up in Microsoft Excel (Tree).

  3. If the Iteration Path and Requirements Type columns do not appear, click Column Options, and add them to the display list.

    You might also want to add the Area Path column.

  4. In Office Excel, if the column headed Title 1 is not followed by columns that are headed Title 2 and Title 3, click the Team tab, and then click Add Tree Level to create the additional columns.

You can now conveniently enter the requirements as a batch.

To enter the requirements and use cases

  1. In the row immediately after the bottom row of existing work items (if any), enter the title of the top-level requirement in the Title 1 column:

    Requirement 1

    Requirement 2

    Requirement 3

  2. In the Work Item Type column of all the new rows, set the type to Requirement.

  3. By default, all Requirement Type values are set to Functional. If you want to change this value to one of the other type options, then you will need to add the Requirements Type

    field to the MS Excel or MS Project view.
  4. In discussion with the business stakeholders, you determine the principal steps that make up the top-level requirement.

    In the rows that immediately follow the top-level requirement, you will enter in the use cases as child work items of the requirements by first selecting the requirment and then clicking on Add Child in MS Excel. Then enter in the Title 2 column:

    Use Case 1.1

    Use Case 1.2

    Use Case 2.1

    Use Case 2.2

  5. In the Work Item Type column of all the new rows, set the type to Use Case.

  6. To publish the requirements and use case to Team Foundation Server, select any cell in the table of work items, and then click Publish on the Team tab.

In a real situation, you might start by entering one level of requirments and then decomposing each requirement into smaller use cases in separate operations.

You now have a tree of customer requirements, which you can edit further in Office Excel or Team Explorer.

Assign Use Cases to Iterations

Assign the use cases to iterations by setting the iteration path field. You can do this in the Office Excel view.

In the following example, the most essential scenarios are implemented in iterations 1 and 2, and other functions are added in later iterations.

  • Iteration 1

    • Use Case 1.1

    • Use Case 1.2 -

  • Iteration 2

    • Use Case 2.1

    • Use Case 2.2 -

You can take thsi a step further an define the tasks for each use case as the following picture illustrates.

Work Breakdown from Requirements

Product planning

Before the start of every iteration, hold a meeting to review the product plan. The first product planning meeting creates the plan, and subsequent meetings review it based on earlier iterations. For more information, see Planning the Project (GovDev).

In a product plan review, discuss the features with business stakeholders, and be prepared to reprioritize them and arrange them into different iterations. The meeting should include business stakeholders and representatives of the development team.

The meeting discusses the sequence in which features will be developed. This can be done by projecting or screen-sharing the Office Excel view of the Open Requirements and Use Case Planning queries and ordering the features by iteration.

Product planning considers the priorities and the development costs. Priorities come from the business stakeholders, with some guidance about risk from the developers. Cost estimates come from the developers. To get an accurate idea of the costs, the development team must have already done some work on the architecture of the product and might need some experience from the early iterations. For this reason, the cost estimates should be refined at every product plan review.

Iteration planning

See Also