Scenario States and Transitions
The states of a scenario work item. A scenario is a type of work item, recording a single path of user interaction through the system. As the persona attempts to reach a goal, the scenario records the specific steps that they will take in attempting to reach that goal. Some scenarios will record a successful path; others will record an unsuccessful one. When writing scenarios, be specific as there are many possible paths.
New
Scenarios can be created in the quality of scenarios list found in the requirements folder in the document library or by using the Team Explorer.
New to Active
|
New |
A scenario is activated as a new scenario when it is first created. |
Active
Scenarios begin in the Active state. The business analyst creates the scenario, provides a descriptive title, and fills in the Description field with as much detail as possible about the scenario.When the scenario is fully written, the business analyst assigns it to a lead developer. The Specified field is set to Yes, and the scenario remains in the active state while it is being implemented. The lead developer coordinates efforts with other developers to implement the scenario.
Active to Resolved
|
Completed |
A scenario is resolved as Completed when the development team completes writing code for the scenario. The lead developer assigns the scenario to a tester. |
|
Split |
A scenario is resolved as Split when further review indicates that the scenario is too large, or that it needs more granular definition. When splitting a scenario, create the new scenarios and link to them from the original scenario. |
|
Deferred |
A scenario is resolved as Deferred if it cannot be implemented in the current iteration. A scenario could be deferred because the team does not have enough time, or because blocking issues were discovered. Update the Iteration field to the correct iteration in which the scenario will be implemented. If the scenario is deferred to the next software product release version, leave the Iteration field blank. Be sure to include a detailed description of why the scenario was deferred, and when it is planned to be implemented. |
|
Removed |
A scenario is resolved as Removed if it is no longer deemed necessary to implement. When removing a scenario, check the Issue, and Exit Criteria fields. Typically these fields should be set to No for a removed quality of service scenario. |
Resolved
When the scenario is implemented in code, the lead developer sets the state to Resolved. The lead developer also assigns the scenario to a tester so that testing can begin.
Resolved to Closed
|
Completed |
A scenario is closed as Completed when the tester indicates that it has passed its tests. When completing a scenario, check the Issue, and Exit Criteria fields. Typically these fields should be set to No for a completed quality of service scenario. |
|
Split |
A scenario is closed as Split because further review indicated that the scenario was too large, or that it needed more granular definition. |
|
Deferred |
A scenario is closed as Deferred because it could not be implemented in the current iteration. |
|
Removed |
A scenario is closed as Removed because it is no longer deemed necessary to implement. |
Resolved to Active
|
Test Failed |
If the scenario fails to pass any tests, the tester must return the scenario to an active state and reassign it to the original lead developer. Also, the tester should create appropriate bugs for the test failures. |
Closed
The tester closes a scenario if it passes its tests. A scenario is also closed if it is Deferred, Removed, or Split into more scenarios.
Closed to Active
|
Reactivated |
A scenario may be reactivated due to a change in functionality. | | 
