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.
.png)
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.
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:
Now that we’ve covered the what and the why of user stories, it’s time to dive into the how.
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:
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.
To create an Epic you need the following five requirements:
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.
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.
.png)
.png)
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:
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.
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.
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:
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:
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.
