PROJECT PLANNING AT ACRO

Strategy: Story Writing

The goal of story writing during the strategy phase in web development is to put user experience and needs front and center. This helps map out your project's exact requirements to build the best journey possible for your website users, as Anders Paulsen, Director of User Experience, explains in detail.

Transcript

Hi, I’m Anders Paulsen, Director of User Experience at Acro Commerce.

In this next chapter of our Project Planning series, we’ll look at the process of Story Writing.

In the previous videos, we looked at common Strategy deliverables, known as the Information Architecture, Technical Architecture, and Prototype, which collectively inform our plans for development.
Throughout this process, we’ll also capture project requirements in the form of ‘Stories’, based on criteria that are pulled from the IA, TA, and Prototype

These stories make up our issue structure, and when combined, they create our Project Backlog, which represents the design and development planned for the upcoming project.

• The intent of working with the ‘Story’ format is to identify requirements without dictating a prescribed solution.

For example, let’s look at stories based on User Requirements.

Identified by the IA’s User Personas, these stories typically follow a User Story format of…

“As a who, I want to what, so that why.“

In this context,

• who represents a particular user persona  — which might be a Customer or Administrative user
• what represents an action they hope to take on the site,
• and why represents an outcome  — the actual goal they’re hoping to achieve, which helps us understand their reason for taking this action.

For example,

• “As a new shopper, I want to read product reviews from real customers so that I feel confident before making a purchase.“

or

• “As a recent customer, I want to check my order status so that I know when my package will arrive. “

or

• “As a site administrator, I want to create user roles and manage permissions so that I can restrict access to perform certain onsite tasks.“

Each User Story helps to create a simplified description of a site requirement, while keeping front-of-mind who we’re designing and developing for.

By also recognizing what they’re trying to achieve, we better understand why the feature is important to them and can account for its relative value within the system overall.

• This helps to establish a sense of priority, allowing our team to manage the backlog, by easily reordering issues to ensure the most important work is completed first.

Now, not all requirements will easily follow the User Story format, which is why some Project Requirements are written using an alternate structure — as System Stories.

System Stories represent behind-the-scenes actions that the project team takes, while setting up or maintaining a project.

A System Story follows a format of … 

action the subject so that objective 

In this context,

• the action represents a particular task to complete,
• the subject represents the system being created or affected, and
• the objective represents the goal  — what we’re looking to achieve by taking this action.

For example,

• “Upgrade the Hosting Environment so that we improve performance.”

or, on the design side

• “Adjust the Design System Token Values so that brand guidelines are followed.”

User Personas found in the Information Architecture will often include an initial list of User Stories based on the goals and frustrations outlined in each.

The Technical Architecture also helps form User Stories and System Stories, based on the requirements covered, and as the Prototype is developed, further stories may be established as workflows are reviewed, tested and refined.

Once a comprehensive collection of Stories has been created, we’ll import the list into Jira, our issue-tracking system, to form the Project Backlog.

In the final video of this series, we’ll examine more closely how we organize stories within the Backlog.

Thanks for listening.

Up Next, Project Backlog.