Over the last few months, we’ve been hard at work improving one of our newest, most exciting products here at Neon Roots: Arbor. Arbor is a comprehensive tool for collecting and managing user stories, which are a key part of effective Agile development, but the concept of user stories isn’t exclusive to software – it can apply to just about any field where work is done in projects. So how do you use it? The process is simple, and it all starts with writing user stories.
User Stories In Arbor & Beyond
Simply put, a user story is a way to describe some function or feature of your product. They’re written from the perspective of the user, and they follow a simple format:
As a <type of user>, I want <some function> so that <some benefit>.
This format describes the user who wants to use the product, the functionality they’re looking to get from it, and what benefit they derive from the product. In one sentence, it gives you all the information you need to know to describe and create an individual feature or functionality in the product.
Keep in mind that different users will want different things from the app, so it’s important to specify just what type of user you’re talking about. If you truly are a one-function app with one user, it may be fine to generically call them “users” – but chances are you’ll also have other parties interacting with the app or the code. When building user stories, think about all the categories of users who may touch your product: general customers, registered users, unregistered users, administrators, maintenance workers, advertisers… The list really could be endless.
This format almost looks too simple, but it’s remarkably powerful. Before we see what makes it so effective, though, let’s talk about what characteristics good user stories have. First and foremost – and this is really the guiding principle of user stories – a user story should describe the what, and not the how. For example, if you’re building Uber, your user might want to summon a car to their location. That user story could look like this:
As a rider, I want to call a car to me so that I can get from my destination to my location.
Notice that this story doesn’t actually discuss the nitty-gritty details of how the user does this, just the broad-strokes explanation of what happens. The story doesn’t talk about the size of the buttons, the layout of the interface, or special notification system that tracks the car – it just states that a user can call a car to them.
Writing stories into Arbor is pretty simple. First, create a project and give it a name, which will lead you to a blank backlog screen. From there, it’s easy: just enter the type of user, function, and benefit into the appropriate fields and click “create.” That’s it – you’ve got your first user story!
4 Qualities Of A Good User Story
As you might notice, user stories are a pretty open-ended format, so there’s something of an art to writing good user stories. While the specific rules will change from project to project, we’d say there are 4 key guidelines for writing a good user story:
- Independent: Each user story should describe an independent, self-contained function or aspect of the product. Keeping each story about a single functionality allows more accuracy in estimating the cost and timeline of the project later on.
- Objective: User stories, as much as possible, should be written objectively. They shouldn’t include details or information about the “best” way to do something or the “best” font size because those claims are unsubstantiated and don’t describe what functionality the user is seeking. They should only describe the broad-strokes functionality and benefit.
- Concise: When writing user stories, it’s important to balance information density with simplicity. In general, you want to write them at the level of complexity that the layperson user would deal with: you don’t have to mention whether something is a modular window or not, only the key information or functionality the user experiences through that window.
- Valuable: This one is critical – every user story should be there because it’s generating some value for the user. You don’t need user stories for the coloring, transition animations, or font variations of the product because they don’t actually generate use value to the user. Keep your stories about the bare-bones functionalities and how they add value to the user’s experience.
Get Your Hands On Arbor
These guidelines should give you a pretty solid command of how to use Arbor to write effective user stories, but if you’d like a more in-depth look, feel free to check out our video on the subject. If you haven’t tried Arbor yet, we’d highly recommend signing up for our Beta program, which lets you get your hands on the tech before its main release and comes with special perks and benefits. We’re adding new improvements, fixes, and functionalities to Arbor regularly, so keep a look out for updates and for the eventual main version launch. Until then, happy story writing!