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.
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.
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:
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.
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.
At Jimmy Technologies, we follow these rules that proved themselves countless times:
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