User Stories are a crucial part of managing interdisciplinary teams on complex projects, and they can also be useful for solo developers who want to ensure that they are delivering a quality product. Read on and learn how user stories can enhance your project workflow!

Why User Stories?

See the map? Enormous projects look about the same. There are many different teams working together, trying to deliver a wonderful product. You can compare those teams with the different routes on the map. Each team has their own goals in mind and only at certain crossings do teams catch up with each other. Communication is key in any project but even more crucial in big projects. How do you communicate effectively in such projects?

I work at an app design and development firm in New York City. Often, different projects pass through the office and it's not always clear how to complete projects with different stakeholders involved. This is why in any collaboration you need to be able to understand each other. We opted for a system which is highly flexible and scalable, to tackle both small and huge projects. Here's some insight into our process.

User Stories Unify Teams

User stories help unify our teams when creating a product. They connect each team and improve our workflow.

Connecting teams is a challenge. Naturally, teams do communicate. Whether that happens effectively is questionable. Having a system in place which improves communication by making it easier to talk about a technical product improves how teams collaborate. This is exactly what user stories are about.

At Fueled we believe that we are able to achieve more with an agile process. This means that all our teams are involved from day one when a client wants to work with us. When you have different teams involved with a project from the first day, there will be conflicts and misunderstandings on the expectations and the desired outcomes of a project. After all, how do you successfully plan certain technical limitations to a designer or explain to a developer how a mock up will function? People with different backgrounds in the industry often have different expectations. For people who have been working together forever it's a lot easier to know what is expected from one another, but for startups or new employees it's often more difficult to communicate effectively at the start of a project.

What Do User Stories Look Like?

This is where user stories come into play. The concept behind user stories is straightforward. What if we use our common language, written English, to connect teams and achieve the realization of a product? User stories are the written thoughts of the user. This could be an example of a user story:

• As a user, I want to be able to press the back button to return to the previous screen.

User stories are always written from the perspective of the user.

Accompanied with user stories are acceptance criteria. These are basically a list of requirements that enable the user story to happen. Here are the acceptance criteria for the previous user story:

• I'm able to tap the back button.
• Once I tap the back button, it will momentarily switch to the tapped state before returning to normal.
• Afterwards, I'm directed to the previous screen.

Besides the acceptance criteria, user stories are usually accompanied with a wireframe, a priority, and the current status. Here are some more examples of possible acceptance criteria which can be found accompanying a user story:

• On the background, there's a map which dynamically shows my current location.
• The following text input field should be pre-filled with data saved from the database.
• Below these buttons, there's a countdown clock which lasts for about 30 seconds. Once the timer has run out, the buttons on this screen will enter the disabled state.

User stories and the accompanying acceptance criteria are short, detailed pieces of information which are able to explain the functionality of a certain feature in an application. At the same time, both designers and developers understand what is expected of them. Let's use the example of the back button user story: once designers have seen the wireframe and have read the acceptance criteria, they know that they need to design two states of the button and the developers know what kind of specific functionality they need to implement.

I'd like to elaborate on the difference between user stories and acceptance criteria. User stories are always written from the perspective of the user. Acceptance criteria are there to clarify user stories: what is required to make a user story work?

User Stories & Teams of One

As an individual designer or developer, you may be tempted to think that this isn't relevant for you. You already know everything that your app should do, right? Unfortunately, this is unlikely to be true. Acceptance criteria are still extremely helpful for quality assurance and finding issues within your own code or design.

User stories are also a useful tool for project management in general. You're able to keep track of different user stories and report bugs or issues. After all, user stories specifically list expectations for the functionality of the app you're working on.

Finally, while you may not be working with another team member today, what if that changes tomorrow? You could extend your stories in such a way that you could provide instructions for design or development in order to provide even more guidance for collaborators.

Managing User Stories

Of course, there is a lot of software out there that makes managing user stories a simple and accessible process. For example, there's Mingle, Pivotal Tracker, ScrumDo and many more. For our projects, we prefer to use Jira.

You're not dependent on software such as Jira to use the concept of user stories while creating an application. You can stick to free tools or create your own way to keep track of user stories.

Usually, there's one person who manages the project. Often, we label those people as project managers as they have the general overview of the project. Designers and developers aren't required to constantly think of the bigger scope, they can purely focus on making the user stories happen. When used correctly, this is a system that works quite well. One person concentrates on the bigger picture, provides user stories and thinks about what the product should look like and how the product should function. At the same time, these people are making sure that the expectations of clients are met while guiding their team. It's a way of assuring quality effectively.

This enables designers and developers to focus on very specific, defined functionalities and issues without constantly worrying about the bigger picture. User stories and acceptance criteria make this feasible and it's easy to track the progress of the final product.

Tools like Jira include built-in functionality for following this process. You have the freedom to work flexibly with the system. You are able to link certain issues or bugs with certain user stories. If you're not happy with one specific aspect of the design, you can relate to that specific user story. Here at the office, we enjoy working with "epics". An epic is basically a group of user stories. For example, certain applications have an epic for every screen. This way, you are able to group the functionalities of a screen in one group, providing you with an even better overview of how quickly your project is being completed or what group of user stories is responsible for the majority of the bugs. Additionally, designers and developers are able to allocate their resources among the different user stories by providing more information regarding time or complexity of the functionality involved. It's also possible to plan certain user stories or epics in a calendar and micromanage the progress of a project.

Ultimately, the success of working with user stories in your own project is likely to depend on the flexibility of the system you've implemented and the freedom the system provides to work within it as either an individual or a team. A good user story system should also allow you to keep an overview of the project as a whole in your peripheral vision even while focusing in on specific tasks or features.

Some Final Tips & Tricks

• Try to balance your user stories between being specific enough to convey the necessary functionality without becoming so specific that they limit creativity. Offer developers and designers the freedom to be creative while still keeping client or stakeholder goals at the heart of the project.
• Write user stories with the potential users of the application in mind. Anticipate that the expectations of the target audience might differ from the initial wishes of the client and try to mitigate this divide.
• At Fueled, we love to polish our products. Make the app work smoothly! If the user interacts with something, provide feedback, even if it's a simple loading animation. The user should always know what's going on. User stories are a great way to make sure that these details are added properly.
• While writing user stories, link to other relevant ones. For example, a button could open a previous screen that already has a user story. The more these stories connect to each other, the better. User stories are all fragments which together form the final product.

Conclusion

Hopefully this article provides some insight into how we tackle large projects and assure quality for the products we create. User stories make sure that you think through the functionality of your app and you keep the wishes of the client in mind. User stories are great for the product, your client, and your team!