Welcome to the second part of our free guide for product owners. In the previous article, we covered effective project onboarding. This time, we dive into User Stories!

User Stories are an essential part of the Agile approach and methodology. Even folks who are not connected with software development in any way somehow heard of User Stories. It's a buzzword, and today we'll show you how to master them and create easy-to-follow descriptions for everyone.‍

Why do we need User Stories?

‍Good software solves users' issues and helps people. User Stories make it easy to describe the intent, a direction in which the development should proceed. It explains what we want from the software. How do we want to use it? User Stories also open a room for discussion and present our intentions to stakeholders so that everyone involved in product development understands what should be done and why.

‍What does a good User Story contain?

‍A good User Story is distilled during the preparation process. From our experience, the best approach is to start with the User Story voice, which goes like: "Me as..., I want to be able to..., so that..." This first sentence describes your intention and addresses everyone involved. Further expansion is necessary, though. Include:

• A detailed description of a User Story voice and focus on answering the "Why?" question – why are the proposed things important.
• A function description that is more in-depth and clarifies technical requirements.
• Design requirements.
• Out-of-scope questions from developers – but remember to concentrate on the vital part of the Story.
• Acceptance criteria – this part is often forgotten, but there is no way to evaluate User Story's completion without specific criteria.

How to prepare a good User Story?

‍User Story's preparation is an open process where all participants are equal, and all stakeholders should be involved.

User Stories might be written by the client, by a product owner, or by the development team – it depends on the project and aims of the product. Let's look at the software project developed using the Scrum framework. In such a workspace, the key actors are Product Owners, Dev Team, and a Scrum-master.

The User Story spans across all development stages – when defining the stakeholders' problems, when discussing the user's problem, when you cooperate with UX/UI specialists, analysts, QA, or developers. Everyone in the project comes across the User Story at some point. Why? Because only by the discussion you can uncover ambiguities and get a complete picture of the task. If the User Story is not talked through, the implementation might go south.

User Stories always help the team understand the client's problem and make it easier to find a possible solution by sparking the imagination. When you operate in the b2b environment, your view shouldn't be limited to end-users but also include both businesses' perspectives. A good User Story is not limited to solving users' problems but has to analyze benefits for clients and benefits for an application owner – the service provider.

Writing User Stories is not a linear process, but you shouldn't be stuck in circles either. When there is new information, it's not a problem to go a few steps back and adjust the Story. However, preparing a too detailed Story or revising it countless times is a road to hell. When you struggle, try applying this simple rule. The dev team should analyze the User Story before the refinement to have more room for questions and answers during the meeting. Try allocating a limited amount of time for each User Story during the refinement. If the time runs out, the discussion is still in full swing, there are many questions left, and the dev team is not ready to give an estimation, your User Story is probably too complex and complicated. When this happens, move the problematic User Story out of the refinement and adjust it according to the new inputs.

‍How big one User Story should be?

‍Complex User Stories are hard to follow, difficult to track, and painful to evaluate. Therefore several smaller and shorter User Stories are more valuable than one big. However, pieces of information without proper context can be deceptive to developers, analysts, and UX/UI experts. So how do you deal with it?

Creating an Epic and a big User Story that contains several functions and Story points might be your trickshot. It will provide general guidance, and later you can divide it with the team into smaller User Stories that are closely linked to programming and development itself.

Story points also help you understand that the User Story is too big and shall be split or rewritten. When you, as a PO, know the team's velocity in Story points, you can easily define the limit for User Story that can be taken for the Sprint. Based on our experience, this value is 70 % of average velocity.‍

Best practices for writing good User Stories

‍At Jimmy Technologies, we follow these rules that proved themselves countless times:

• The User Story should be short and easy to read, understandable to all.
• All involved in the product development should take part in the User Story preparation.
• It is essential to understand that a User Story is a small target for a successful product.
• There is no need to replace all documentation with User Stories.
• The User Story is also a business for UX/UI, Analyst, etc.
• The User Story shall be testable and used as one of the inputs for QA.
• The User Story is easy to evaluate and helps estimate the time required for implementation.
• The User Story should contain a valuable function that can be developed during a Sprint and has a specific outcome

‍What to include in User Stories:

• User Story voice – personalization makes it easier to understand what you are saying – "As a (product owner), I want to (be able to manage my personal dashboard) so that (I have a quick access to data)."
• A description of a User Story voice – Show your motivation so that everyone can understand. (Dashboard will save users time and help them focus on necessary information).
• Describe the functionalities from a user perspective.
• Technical requirements.
• Relation to other User Stories – how it fits into the ecosystem.
• Design – describe the user journey, add requirements.
• Out of scope – clarify which features and things are out of scope for the implementation.
• Questions & comments – let others ask questions and add comments.
• Acceptance criteria – ACs define required functions from User Journeys, and they help product owners control DoD (definition of done). ACs can be used as one of the test cases, but they are not the test specifications. ACs also show what will be presented in the demo.
• Milestones (defined by the team) – Milestones are optional and help avoid losing track in large multi-team projects where Sprints duration is fixed. Milestones should be set on the first day of each Sprint when you analyze User Stories. They are instrumental when the User Story is complex and challenging to handle – by having milestones, PO and QA can track and evaluate the progress.

We hope you'll find this guide valuable and implement it into your workflow. The next part of our free guide for product owners will be focused on Scrum ceremonies and how to get the most of them.

Reach out to get more information.
Pavel, Product Owner

‍