Title

Required. The title describes the intent of the scenario. The title should be descriptive enough to allow a business analyst to write it several iterations after it was initially conceived.

Area

The area is used to group the scenario into an appropriate feature or team area. The area must be a valid node in the project hierarchy.

Iteration

The scheduled iteration is the iteration in which the scenario is implemented in code.

Assigned To

The current person that the scenario is assigned to.

State

Required. A scenario can be in the Active, Resolved, or Closed states.

Reason

The reason a scenario is in the current state. For example, a scenario can be in the Closed state because it was Completed.

Description

The description should be a high level outline of the scenario. The full scenario should be described in a scenario work product.

History

This history is a running discussion about the scenario that accumulates additional written entries as changes are made. Each time a change is made to the scenario, an entry is made in the History field describing what change was made and why, as well as any additional pertinent information about the change.

Issue

Issue is a Yes or No value indicating if the scenario is blocked on progress. If this field is set to Yes, the scenario will show up on the project manager’s issue report.

Exit Criteria

Exit Criteria is a Yes or No value indicating if the scenario is part of the iteration backlog. This field is used to synchronize the various views of the backlog (the scenario list, quality of service requirement list, and iteration plan). If the exit criteria field is set to Yes, the scenario displays in the project checklist query and work product. This field will be renamed to "iteration backlog" in a future release.

Rank

Rank indicates how important the scenario is relative to all scenarios for the software product.

Integration Build

The Integration Build is the build number in which the scenario is integrated by the development team.

ID

The ID is the unique identification number assigned to the scenario.

Rough Order of Magnitude

The rough order of magnitude estimate is a measure of the complexity of the scenario or quality of service requirement. If the work item requires a half dozen or less 1-2 day development tasks to implement, choose 1. If the work item requires between a half dozen and a dozen 1-2 day development tasks to implement, choose 2. If it is larger than this, choose 3 and consider splitting the scenario or quality of service requirement.