1

Choose Appropriate Persona

• Select a scenario from the list slated for the next iteration or choose a scenario that is architecturally significant. Open the scenario description template in Microsoft Word and save the document using the scenario name to distinguish it from the other scenarios written so far.
• Determine the best persona who most personifies the scenario. If many personas will act the same within the scenario, choose one of them arbitrarily. This is the primary persona for the scenario. Check to see if the scenario is the same for each persona. For each persona that approaches the problem (from the system perspective) in the same way as the primary persona, write that persona's name in the alternate personas section in the scenario document. The primary persona will be used in the scenario description.
• If a persona requires differing functionality, add a new scenario entry for that persona to the scenario list or write a scenario for each primary persona.

2

Write Scenario Description

• Write the scenario in the description section of the scenario document. Starting from the beginning, describe each step that the persona attempts as they move through the system on the way to their goal. Sketch out those steps that have been part of previous scenarios and are not part of the differentiating factors. Be specific on the area that differentiates this scenario from others.
• To make the scenario easy to read, start a new paragraph at each decision point within the area that highlights the differentiating factors. A decision point is a point in which the persona makes a key decision in using the system. It is not necessary to use this guideline in areas that have been covered by previous scenarios.
• Describe the path through the system as a single train of thought. Capture the actions of the primary persona and consider what that person would do when faced with the decisions that the system would ask them to make.
• Describe system behavior at a high level. The storyboard can often be used capture the remaining system behavior. Describe persona behavior at a low level.
• Record the goal (the best case scenario) and any sources that the scenario was derived from. Save the scenario and publish it to the project portal. Attach the document to the scenario work item (or scenario entry). Notify the project manager, architect, appropriate developers, and testers that the scenario has been written. The architect can factor in any changes to the system and application diagrams. The developers and testers can begin breaking the scenario into development and test tasks for the project manager.

3

Split Scenario

• Optional
• If the detailed estimate (from the sum of the costs of the development tasks) is too large to be covered in a single iteration, it can be a candidate to be split. To be split, each new sub-scenario must maintain a complete path through the system. Determine the differentiating factors for each new scenario. Create two or more scenario documents from the scenario template.
• Write each new, smaller scenario based upon these new differentiating factors. Save the new scenarios with a unique name or with the parent scenario name and additional information indicating the split. Publish the new scenarios to the project portal. Create new scenario entries in the scenario list. Synchronize to create two new scenario work items. Attach the parent entry in the attachment section. Attach the respective document to the new work items.

A reviewed scenario that captures all of the external behavior of the system and the interactions with the personas in the area of the differentiating factors.