header-logo

LookFar Labs16 May 2018

Strategic Software Development: How Well-Defined User Stories, Acceptance Criteria, and Stories Can Save Startups Time and Money

When it comes to software development, spending extra time during the initial planning stages of a product build can save startup founders a lot of time and money in the long run.

Here at LookFar, the Strategize Phase is a key component of what we do for this very reason.

The more fully that everyone on the team – from the startup founder to our software engineers and product managers – understands what problems we’re trying to solve for the users and how we plan to solve them, the better the end result will be.

One of the main ways that we ensure that everyone on the team is on the same page about the product that’s being built is through User Stories and Acceptance Criteria. These tools help us successfully build products that help your company acquire and retain new users and keep your existing users happy.

TL;DR,

User Stories and Acceptance Criteria are the building blocks and guiding light for developers to build out stellar products. Once we’ve determined these, we then synthesize this information into Stories to relay it to our entire team.

User Stories are a tool used in Agile software development that describe how a software feature will be used from the perspective of an end-user. They give us the big-picture view of an action a user wants to do within an application.

Acceptance Criteria further builds off of the User Stories, getting into the detailed, nitty-gritty of how an area of your software should be built in order to let the user do the action they want to take.

Let’s dive in deeper with some examples, and you’ll quickly see how these tools can save a lot of time, money, and headaches for startup founders during the software development process.

Examples of User Stories

User Stories should define an action or output that a user desires. In a user story, you should be able to specify:

who wants to do what and why they want to do so

On a more technical level, this specifies the user role, desired outcome or output from the action, and a brief rationale for why the user wants to take this action. These answers can be summarized using the following user story format:

“As a ____, I want to _____ so that ______”

Using this format hits the, “who, what, and why” in a water-tight way that leaves no room for error. Let’s look at some examples:

  • “As a Spotify user, I want to create playlists so that I can choose songs to listen to in order.
  • “As a JIRA Admin, I want to edit workflows so that my team can follow the same workflow.
  • “As a Gmail user, I want to mark emails as spam so that I no longer get unwanted emails.

These User Stories ensure that our developers, partners, and product teams are all on the same page.

To demonstrate some benefits to using this format, here are some anti-examples of User Stories with vague, incomplete, or missing information that should be avoided:

  • “As a user, I need to add tracks”.
  • “We need to upgrade our workflows so we can get more done”
  • “I need to mark emails as unwanted”

You can see why we’d want to avoid these anti-examples.

Examples of Acceptance Criteria

After getting your User Stories nailed down, we can drill down into Acceptance Criteria (AC), which documents the nitty gritty details of what needs to be built out.

AC builds upon your User Stories and provides a crystal clear understanding of each detail and interaction that a user will experience when using your product. AC helps our developers build great software products, which in turn will keep your users happy and engaged.

AC should be written using specific language in a way that explains the end goal of a feature. Let’s look at some examples:

  • Within the “Edit Profile” view, users must be able to upload a new profile picture
  • Users must be able to upload pictures from their computer, phone, or social media (Instagram, Facebook, and Twitter)”
  • Once a new profile picture is uploaded, users must receive an indication that the upload was successful
  • Buttons used in profile upload must be consistent with other areas of the app

Writing AC in-line with the above examples eliminates any question of how a feature should look.

Now that we know what stellar AC looks like, let’s look at an anti-example to avoid:

  • Can edit profile picture

This vague AC leaves your teammates asking more questions like, “Who should be able to edit profile pictures? Where does uploading new profile pictures exist? Should people be able to apply filters and crop their picture?”

Being specific and narrowing in your specifications allows our developers to narrow down the time it takes to build a feature. Which in turn saves you, the startup founder, money.

Examples of Stories

At the intersection of User Stories and Acceptance Criteria are Stories. Without going too far into it, Stories are how we communicate User Stories and Acceptance Criteria across Agile teams.

The title of a Story gives a quick, one line understanding of the work to be done. Here’s a good example of a well-written, clearly described Story:

Project: Google Chrome
Title: Most-frequently visited websites

User story: As a Chrome user first opening the app, I want to be able to navigate to my most frequently viewed websites so that I can access them quickly and easily

Acceptance Criteria:

  • On the default view for Google Chrome, users must have access to a view called “most frequently visited websites”
  • View will have no title displayed
  • This view must display the top 8 most visited websites
  • Websites must be displayed in a card format
  • Cards must display an image of their respective website
  • When hovering over a card, the hover text should display the website title
  • When a card is clicked, the user is navigated to the website respective to the card
  • Users can manually delete websites from this view via an “X” in the top right corner of a card

On the other hand, a Story like the one seen below does not provide the necessary information to help a developer understand what they need to build. It uses incomplete sentences and lacks clarity:

Project: Google Chrome
Title: Frequently Visited websites

User story: As a Chrome user, I want to be able to navigate to my websites so that I can access them

Acceptance Criteria:

  • Users must have access to a view called “most frequently visited websites”
  • Must display the top visited websites
  • Websites displayed in an card format
  • Cards display a picture
  • Users can delete these sites

That said, it could always be worse. Here’s a really terrible example of a Story. You can see from the Story below that a lot of necessary information is missing. It needs to needs to be much more specific:

Project: Google
Title: Websites view

User story: I want to see my most viewed websites

Acceptance Criteria:

  • Users can see most viewed websites
  • Websites show pictures of sites
  • Users can click sites

In order to keep our developers AND partners happy, it’s crucial to our process that we create clearly defined Stories.

Strategic Software Development

By taking a strategic, thoughtful approach to software development, from beginning to end, we’re able to save startup founders time and money in the long run. It also helps us to create products that best serve the needs of the intended users.

When we work with our partners to provide fully fleshed out User Stories and Acceptance Criteria, our product teams have a clear understanding of how a software product should be built, allowing them to spend less time interpreting what needs to be built and more time building.

If you’d like to learn more about our Strategize Phase and how we work with our partners to develop mobile apps and other software, contact us.

Like this post? Bookmark it on Pinterest:

When it comes to software development, spending extra time during the initial planning stages of a product build can save startup founders a lot of time and money in the long run.

Written by

Eric Skinner

Why Conduct a UX Review Why Conduct a UX Review Am I Spending Too Much Maintaining Software and Should I Be Exploring Alternative Solutions? Am I Spending Too Much Maintaining Software and Should I Be Exploring Alternative Solutions?