Skip to main content

Construction of a User Story

· 4 min read
info

This post is a real ticket at $DAYJOB, for an application used for running small, in-person collectable card game competitions. I have edited it to remove proprietary and/or extraneous information, but it is otherwise unchanged.

Components​

Good stories need the following:

  • Persona: This is the "As a..." bit, and should represent a class of user of your software
  • Goal: This is the "...So that..." or "... In order to..." bit, and should represent what the user is trying to achieve i.e. what problem they are trying to solve
  • Action: This is the "... I want to ..." bit, and should represent what the user wants to do in furtherance of the Goal.

Format​

There are 2 common, related formats that often used:

Action first:

As a ... I want to ... So that ...

Goal first:

As a ... In order to ... I want to ...

Of these, I prefer Goal first as it encourages you to think about higher level requirements before lower level ones.

Language​

The language used here should focus on "What?", rather than "How?" That is, focus on the problems being solved, rather than implementation details.

Additional information​

The information above is not (pardon the pun) the whole story. As the saying goes:

A story is a promise for a conversation

The User Story Format is a starting point, a framing device for having that conversation. Having this conversation will allow you to come up with a design that solves the problem expressed in the framing device. This may result in some implementation details being expressed in e.g. the description field in JIRA.

Example: Concurrent users vs. Dividing the work​

The relevant role for this example is "Scorekeeper". Their primary responsibility, as the name suggests, was collecting paper score sheets, signed by both players, verifying them and entering them into the system.

They also had the secondary responsibility of registering players into the system, some of whom have pre-registered, and some whom show up on the day of the event and need to be entered manually.

Both of these tasks benefit from splitting the work among several people, but player registration especially can become a bottleneck because it all has to happen up front.

That is was this ticket is about.

As a Scorekeeper I expect player registration to support concurrent users

The player registration page needs to support multiple people doing player registration so that we can start the event faster.

We need:

  • Automatic updates for ** Adding players (guest and WA) ** Removing Players ** Updating Player names

This is pretty good already. It isn't written in user story format, but it has all the information.

Here is a possible improvement

As a Score Keeper, In order to start the event more quickly, I want to split the player registration process among my fellow scorekeepers

Technical details​

We should update the Player Registration screen to support concurrent usage by multiple Score Keepers. This will entail using websockets to notify clients of changes made by other clients and updating the UI accordingly.

Acceptance Criteria​

  1. When a user registers a new player for the event, other connected clients which are also showing the player registration screen MUST be automatically updated to reflect the change
  2. When a user unregisters a player for the event, other connected clients which are also showing the player registration screen MUST be automatically updated to reflect the change
  3. When a user changes a player's metadata (e.g. first and last name), other connected clients which are also showing the player registration screen MUST be automatically updated to reflect the change