User Story Examples

A user story has three key pieces: (1) the person who needs to do something, (2) something the person needs to do, (3) an optional explanation of why it needs to be done. These key elements are presented in boldface in the examples.

Examples 1 and 2 are the simplest form of user stories, containing only these key pieces.

Example 1: A community member needs to update his/her user profile.

Example 2: A researcher needs to execute a set of computing jobs on a high-performance computing (HPC) system to complete a project.

Examples 3-5 are user stories that have been expanded into use cases. The extra information--the steps, the exceptions, and the acceptance statements--describe how the user story appears in a current system or application.

Example 3: A researcher, educator, science gateway developer, or application developer needs to find where a specific application or service is available within the system.

In most cases, the community member wants to experience this as follows.

1. The community member visits the system website and navigates to a page allowing a search for applications and services.
2. The community member enters the name of the application or service and clicks “Search.”
3. The community member receives a page listing locations within the system where the application or service is available for use.

We’ll take any solution as long as the following are true.

1. In Step 1, the navigation should be straightforward.
2. In Step 3, the results should span the following types of locations: SP resources, science gateways, cloud images, and/or cloud services (software-as-a-service).
3. In Step 3, the results should include information about how to access the application or service at each location.

Example 4: A researcher needs to generate metadata for one or more data objects using a tool or application selected by (and possibly provided by) the researcher.

In most cases, the researcher wants to experience it as follows.

1. First, the researcher logs into the system where the tool or application is available.
2. Then, the researcher invokes the tool and specifies the data objects to be processed. The tool generates new metadata for the data objects.
3. Finally, the researcher is able to review the new metadata and either store it or save a local copy for later use.

It will always be like this except when the user chooses to store the metadata immediately, in which case the experience described in [related user story] should happen in parallel with this. (The steps may interweave.)

We’ll accept any solution as long as in Step 3, the resulting metadata can be used with other metadata functions.

Example 5: An allocation administrator needs to create a new allocation submission opportunity so he/she can begin accepting allocation requests.

The allocation administrator wants to experience it as follows.

1. The allocation administrator authenticates to the administrative interface and selects “Create Submission Opportunity.”
2. The allocation administrator provides the required data for the opportunity and submits the request.
3. The system creates the submission opportunity and presents the allocation administrator with list of active resources.
4. The allocations administrator selects some or all resources to be included in the opportunity.
5. The system sends email to the administrator of each selected resource to confirm their resources' availability for the opportunity. Each email notification includes a link back to the system.
6. The SP Resource Administrator follows the email link, authenticates, verifies the resource’s availability (or declares it unavailable), and provides any resource details specific to this opportunity (e.g., number of service units available).
7. On and after the announcement/visibility date, the opportunity becomes visible as "upcoming" in the allocation proposal submission interface. The listing includes the participating resources, the start date for submissions, the submission deadline, etc.
8. On and after the start date for submissions, the opportunity is open and the proposal submission interface can accept submissions.
9. On and for two weeks after the deadline (plus grace period, if any), the opportunity appears as “closed" in the proposal submission interface.

We'll accept any solution as long as the opportunity becomes visible in the submission interface (assuming it should be) within 5 minutes.