Why Brands Need User Stories to Define Development Projects

All products begin with “I have a great idea!”. But what follows next?  

Stakeholders come together to create a plan and answer the many questions that come with every development project. What will our product look like? Who will be using it? How will we market and price it? What features should we focus on?

‍

A classic way of preparing project documentation may bring the team to creating long specification lists, building prototypes before the business objective is defined, etc. The sheer amount of work that all these processes require often lead to project requirements that are of poor quality or even unfinished. And that often set projects up for failure before they even begin.

That's where user stories come in. They are a middle ground between high-level business demands and detailed technical specs, which help to build understanding between the development team and a client.

At 923 Digital, we have a very specific technique to our User Stories that you can use to better define and scope your next development project.

What is a user story

A user story is a short and simple description of a feature of your end product. The main goal is to describe who is the user, what they want, and why. This way, each software feature is captured from the perspective of an end-user.

At 923 Digital, each project starts with a workshop to create the initial batch of user stories. Some user stories are added, altered, or scrapped throughout the project. The process of writing user stories is very collaborative. Product owners from your partner agency may take the lead to maintain a backlog of user stories, but it doesn’t mean that anybody else can’t write them.

Why create user stories

Creating user stories can seem like an extra step. Why not save time and simply write down all the desired features of the end-product? Because user stories have several unique benefits:

• User stories promote collaboration. User stories serve as a bridge between you and the development team at your partner agency.  They make it easy for the development team to stay flexible in terms of design and technologies used for the project, and for you to track the progress of the project.
  

• User stories keep the focus on end-users. Who the end-product is for and why they would need it is constantly in focus.
• User stories enable flexibility.Requirements often change as the project commences.Some features might lose necessity, while others uncovered only in the middle of the project.
• User stories save time. Instead of creating detailed documentation, the team can start the project earlier and focus on developing features that are actually useful. This results in quicker delivery of working software.

Now that we’ve covered the what and the why of user stories, it’s time to dive into the how.

Three Phases of User Stories

Before creating a user story, we need to differentiate between stories and Epics. Both concepts are tightly interlinked, and each has its own purpose in creating the end product.

While a user story focuses on one requirement or request from one user, an Epic is multiple related stories put together. An Epic describes an entire feature and provides a high-level view of the objective that unifies multiple stories.

‍

The path to creating user stories is simple, but each step involves work both on your end and at the end of the agency you work with. Here are the three phases of a user story:

‍

1. Epics - A series of brief descriptions of each need your end product will fulfill.
2. Creating User Stories -  Once you have your Epics, you are ready to create your user story. This is a very collaborative process between you and the agency you work with, which might require some back and forth discussions.
3. User story implementation - Once the user stories are complete, the development of your product can start.

Why do you need Epics?

An Epic is a top tier of work hierarchy. Usually, it’s broad in scope and lacks details, but not without purpose. It promotes effective communication within your organization and between your team and the agency you work with.

Epics can help convey a bigger picture, or a set of features your product will have. This might be useful when you talk with C-level and executive stakeholders. User stories, on the other hand, come in handy when you talk to your colleagues or the development team at your partner agency.

Elements of an Epic

To create an Epic you need the following five requirements:

1. Name
2. Description
3. Product Requirement
4. Technical Requirement
5. Design Requirement

‍

Step 1. Name

Describe what you are trying to accomplish with a particular feature from a high-level perspective. Use clear, simple language, and keep it short.

‍

Example:Implement the ability to onboard a user to the application

‍

Step 2. Description

In this step, you can go into more detail and describe the problem the feature solves and what needs it fulfills. As we said before, Epics are often used to talk to executive stakeholders, so focus on the business value of the feature rather than the implementation details.

‍‍

Example:Onboard the Team Owner to the application. Onboarding will guide the Teamowner through the Sign Up process.

‍
The Team Owner is a power user, a leader who discovers the app and has the power to bring their colleagues to use the app as a Team. Team Owner will eventually pay the subscription cost of the entire team.

The Teammate is a user who has been invited to the app by the Team Owner. An invitation sent by the Team Owner will start the onboarding and guide the Teammate through the process of setting up the account as part of their Team.The Teammate can’t create a new Team or invite other Teammates.

The elements of a user story

Now that you know what an Epic is and why you need it, let’s dive into how to write a user story.

Working with user stories can quickly become just another technical task, which defeats the purpose of a user story. To combat that, focus on the three areas: role, action, and advantage.

• Action: After you’ve determined who the end-user is, you need to understand what they want to accomplish. This shows how the user could achieve the goal by interacting with the system. Keep it simple and avoid the use of passive voice.
• Advantage: The advantage should be a result or benefit that is non-functional. This represents the ultimate value the system brings and shows exactly how a feature is useful in everyday life for the user in question.

• Role: This a user who will interact with the system to reach their goals. It’s important to focus on the end-users.

‍

The answers to these questions form, quite literary, a story with this format: As a [type of role], I want to [action] so that [the advantage of the action]. It should be easy to understand for all stakeholders. For example:

• As a truck driver, I want to have access to my next job, so I can start the trip.
• As a sales manager, I want to have a web leads list, so I can contact them and make a new sale.
• As a customer, I want to manage my prescription list, so I can receive the medication I need.

‍

Best practices for writing a user story

While there is no wrong or right way to create a user story, there is one trusted and tested method that keeps the purpose of user stories in perspective: the three C’s.

1. Card. This can be a physical or a digital card that contains the basic components of a user story: As a [type of role], I want to [action] so that [the advantage of the action].
2. Conversation. Before you start using the user stories you’ve put together for development, they need to go through a validation round. This means you should talk to customers to see if the stories are easy to understand or if some additional information is needed.Continuous discussions between your team and your partner agency are also important, both to see if user stories need adjustments, but also to keep everyone informed about bottlenecks and challenges.  
3. Confirmation. The final step of completing a user story is determining acceptance criteria that will confirm that a user story has been successfully implemented and delivered. Each story can have its own acceptance criteria.

How to make sure your user story is of good quality

The three C’s tell us howto create a user story, but what about how to ensure it’s of good quality? Luckily, there is another framework you can use. It goes by the acronym INVEST. You can use this framework to make sure your user stories will actually bring value to the final product.

• Independent – User stories should be independent of each other.
• Negotiable –  User stories should be negotiated between the product owner and the development team to capture the real need of the customer.
• Valuable – User stories should represent real value for the customers.
• Estimable – It should be simple to estimate how long it’s going to take to develop each user story.
• Small – Each user story should be small enough to fit into a two-week iteration. If any single story takes more than 50% of an iteration (2 weeks/10-day sprints) it should be broken into substories.
• Testable –  Each user story should have its own acceptance criteria.

Adding Assumptions to the User Story

Technical Assumptions

Technical assumptions should include tactical details of technical implementation of the feature: DB, API, third-party services, etc. This step will involve the developers or tech leads from your partner agency. Their input will make sure the estimation of work is done correctly.

‍

Example of technical requirements:

• An auto-delete system must be in place to be GDPR compliant

Design Assumptions

Design assumptions focus a lot on the user experiences, which means it’s going to be a collaborative effort between you and UX designers. Design requirements typically include sketches, mockups, screenshots, images, photos as well as specific requirements about image formats, storage, etc.

 Example of design requirements:

• ‍Max profile photo should be 2000X2000 pixels
• ‍Success indicator to be shown for successful uploads

Get started with user stories

User stories play a significant role in a smooth software development process. To start using user stories effectively in your work, start by looking at each need your future product might fulfill. Break each of them down into smaller user stories, and invite both your agency and your team to weigh in.

Don’t hesitate to start the development process. You and your team will learn more about the product as features are developed and tested, ultimately leading to a higher quality product.

Need help with your next software development project? Get in touch with us.