Writing Good Scenarios

Article
01/03/2007

Discipline	Product Management
Role(s)	Business Analyst
Activity	Write Scenario Description

Short Description

Scenarios are used to define the services that the software will provide to the user. A scenario can be thought of as a path through the system and can be represented by use cases or collections of user stories. Most of the scenarios for a system are written at the start of the project to help scope the work and identify the most important features or services of the system to be developed. It is not uncommon, however, that new scenarios are identified or existing ones modified or deleted as the development of the system proceeds and iterations are completed and previewed by users.

Scenarios are user and product, not technology focused. They are written in the language of the user and can be as short as a couple of sentences or as long as a few pages. Each scenario must stand on its own. Scenarios can be written as a collection of steps that the user performs when interacting with the system and the resulting services that the system performs for the user. When writing scenarios, the prerequisites for a given scenario should be spelled out ahead of time. When writing a scenario, it is often best to name the scenario as something that either describes the intended result or the problem the user wants to solve.

Workproduct Inputs

Vision statement or document
Access to domain expert or end users of the proposed system
Personas of expected users of the system

Workproduct Outputs

A description of a path through the system to be developed
An initial understanding of what the end user for that path expects or needs from the system

Checklist(s)

Writing Good Scenarios, items to consider

Check	Description
□	The language of the scenario is that of the target consumer/end user of the scenario, free of technical jargon that is not related to what they will expect and experience.
□	The scenario is concise and deals with a single path through the system. Variations and alternate flows can be discussed but the scenario is not meant to be a complete documentation of the system.
□	Scenarios are used to form a basis for agreement between the software development team and the end users of the system. They should represent a clear picture to each party of what the system is expected to do, and what business limitations the system should enforce for the particular path through the system
□	You will need to define multiple scenarios to describe a single system and should start with the most important ones to the end user. Not all aspects of a system will be described in the collection of scenarios developed. For example, there may be performance or scalability requirements on the system not reflected in any scenario.
□	Scenarios are used to scope the system and help identify requirements of the system. They do not document all of the requirements for the system. Scenarios are used as an input to the requirements gathering and documentation.

Size and number of scenarios

Check	Description
□	Scenarios can be as short as a few sentences or as long as a few pages. Any prerequisites that must be satisfied for a scenario to be performed must be specified in the scenario.
□	Scenarios can be written in a narrative form, as a collection of user stories, or as a numbered set of steps. They should clearly state the purpose or end goal the user has in mind when performing a scenario.
□	Not all aspects of the system will be documented in scenarios and more scenarios may be identified as the development proceeds. You should start with the key scenarios that will define the success of the system.
□	When possible, it is best to name each scenario with the goal that the user wants to achieve when performing the scenario.