Translating User Stories into Code

Modern software is largely designed in order to solve problems for users, whether that be making calculations for a rocket launch or helping someone decide what groceries to buy.

There are multitudes of approaches to software design. When architecting solutions to common problems, it is often enough to look at the discrete logic for a specific challenge being overcome, ie: these two big numbers need to be multiplied together, this user needs to be authorized, etc.

One other such approach is to view the scope of the implementation wholistically, that is rather than viewing a particular challenge within its own limits of operability, to assume the perspective of a hypothetical end-user through the use of user stories.

User stories can be used to lay the foundation for every decision that is made when putting together a comprehensive web application. When looking to implement a feature in the software, user stories focus on the type of user that is being served, the user's goal when using said feature, and why they might want it to work that way.

Creating user stories is a collaborative endeavor that combines aesthetic design, strategies for user engagement, and a technical understanding of the capabilities and limits of the technology being used. The stories themselves can be written very simply, but they need to convey a range of underlying capabilities.

For example, with a photo sharing website, we might say something like:

> The user can post photos to their profile

This implies several implicit faculties for the implementation of the software. There is a unique user that should presumably have access to an individualized profile. They can upload or access image data and make post requests using that data.

Similarly, another user story might be:

> The user can view their friend's photos

This includes references to capabilities that allow the user to add other users as friends, that perhaps that only users have access to view another user's photos.

From these user stories, the design team can formulate a top-down approach in order to create a pathway through implementation. Similar to how a script might be used on a film set, each feature or scene is broken down into its constituent parts. In film production, ADs and producers typically use what are called "one-liners" which is a data table with each line representing a predefined subset of pages from the screenplay that need to be completed.

A user story will generally have criteria for satisfaction that can be expressed in terms of the parts of the program that need to be written. This may further be dissected into the components or pieces needed to fulfill the criteria, and then the behavior ascribed to them. Following the initial example, of being able to post photos to a profile, we might say:

> if the user is authenticated
> given their profile url
> when the profile page loads
> display photo field component
> display post photo link input
> display post button

Then we might define the behavior of the visible components thusly:

> when the button is clicked
> if the input field has data
> the photo should be fetched
> once the photo is fetched
> photo should display in the photo field

The process of atomizing these solutions can further be translated to the actual code being written. While completion criteria may in some cases be considered subjective, user stories are ultimately validated through the implementation of the components and related behaviors.

This atomization of fulfillment criteria can now be translated into pseudocode, which might resemble the following:

//when the button is clicked
buttonClick = (event) => {

  // if the input has value
  if (input.value){

    //fetch the photo
    let newPhoto = app.get(input.value, callback)

    //append to photofield
    photofield.append(newPhoto)

  }
}

Through this process, the structure of the program can be built up iteratively but with intention, direction and momentum.

There is a certain nontechnical empathic aptitude to placing oneself in the shoes of the user and asking, "does this feel right?" Again the analogue of a film set illustrates a similar relationship. A one-liner and the 5/8ths of a page of dialogue that constitutes having "gotten" the coverage needed to edit a scene is ultimately a matter of a director placing themself in the role of an audience member watching the film for the first time. Does it all make sense together?

project management
agile project management
user stories
tips for user stories