What are User Stories and Why are They so Important?
How well do you know your customers?
With the development of the Lean Startup Model startups and entrepreneurs have become obsessed with getting to know their customers. Validation from potential users and customers has become the core of building any startup. As Steve Case says, “Get out of the building” and go test your idea by talking to your ideal customer.
Similarly to building a startup, software development relies heavily on your target user. What does a user’s flow through your app look like? What type of features do they want and why?
That’s where user stories come into the picture.
What is a user story?
User stories define the entire software development process. The standard format is as follows:
As a ______, I want to ______, so that _____.
This format is important because it does 3 things – (1) focuses on a single group of users in your app, (2) outlines the functionality they expect, and (3) addresses why you should build this feature. This structure helps make building software an extension of building your company.
For example, for an app we are building called FirstPlace, we have two audiences we are building for – landlords and tenants. An example of a user story is:
As a tenant, I want to be able to filter rental properties by price, square footage, beds, baths, and neighborhood, so that I can find the exact type of house I’m looking for.
Every feature and process in a software build needs a user story. User stories drive the architecture of the app and help developers understand what they need to build. Once user stories are defined, the software team can take a holistic look at the app and break down each story into blocks of code they need to write to turn the user story into a feature.
Where do user stories fit into the larger picture of software development?
User stories are just a small part of the software planning process.
Before user stories are even written, it is important to write a longer script of the workflow for an app. This means as a new user who lands on the site, what type of functionality should they expect? The workflow is typically written in paragraph form.
The app workflow is then broken down into user stories. These user stories drive the design and back-end coding.
The next step is building wireframes. We really like Sketch for rapid prototyping andInVision for interactive wireframes. This gives more background and context to user stories and helps nail down the app’s functionality before a single line of code is written.
Once we have a holistic view of the workflow and how the app should function, it’s time to start planning our sprints. This means going to Trello and breaking down the user stories into feature builds and planning our two-week development sprints.
Depending on the project and the client’s preferences, we will also turn user stories into test suites to reduce the chances for buggy code, or we will write quality assurance tests at the end of a sprint to ensure the app functions as defined by the user stories. The tradeoff between the two methods is cost vs. speed.
Test-driven development (TDD) is more time-intensive and costly for the client, but results in higher quality code. Writing quality assurance tests at the end of development sprints allows us to build faster, but usually results in more bugs. So again, our approach greatly depends on budget and timeline.
So, this sounds pretty standard for most development firms…
Yes, that’s 100% correct.
There is variation within this process, but this is typically the workflow for any software development company. My point here is that you will notice that a lot of this process revolves around user stories. That’s why user stories are the lifeblood of software development.
At SotoLabs, we take a lot of time to nail our user stories. Don’t know your target market well enough yet? Then let’s find out more about them. We don’t write a single line of code until we are confident that we understand every single intricacy about your customers. It will cost you a lot of extra money and time if we don’t take this first step, and no one wants that.
Interested in chatting more about software, startups, sports, music, slow lorises? Hit me up at Zubin@SotoLabs.com.