is an integral part of agile development. It helps you break your work down into a series of tasks, each of which adds tangible value to the project. All of these tasks can be discussed and ranked independently of each other. This post is inspired by the "50 quick ideas to improve your user stories
" book by Gojko Adzic and David Evans.
User stories, or user stories / wishes, are a methodology that draws on other agile practices, including the principles of continuous delivery and face-to-face communication with users. It's not enough just to understand what your user will be like; the real user of your system must be with the team for a long time.
User story can be added to the project backlog at any stage of the sprint by any team member. The project owner decides how to coordinate and prioritize the user's wishes and picks them up at the beginning of each sprint cycle.
User Wish Cards
The user's wish is a card with a title and several lines of text. Your cards can be both virtual and physical. When developing a large product / system, store it digitally and then issue material cards as part of sprint planning.
When making a card with a user's wish, make sure that it (wish) is well formulated. Do not skip the part that explains the need to create this element of the system just because it can cause you difficulties.
You can develop a list of acceptance criteria when meeting custom system requirements. It should act as a reminder to test or verify certain things that might be raised in the discussion. But you don't need to focus on it when determining the scope of work based on the user story.
If the wish is too large, break it down into smaller parts, as this approach increases the chance that the result will be ready-to-use code.
Movement "from the target"
Building useful software systems is time consuming, so you need to make sure you are solving the right problem. Agile methodologies use a reverse approach - what is the system user trying to get at the end? If you delve deeper into this issue without sufficiently understanding your users, you risk solving the wrong problem or finding a solution that doesn't really work for your users in real life. Therefore, the most important part of a user story is its purpose.
Understanding the goals will help you in deciding whether you have met the user requirements, in other words, is the work you have done meets the user's goal?
When writing a user story with your development team, always start by thinking about and discussing your user's goals.
A detailed description of the customer (actor) will help you break down the interaction building process into logically connected chunks.
Sometimes the customer will be the user of your system, in other cases the administrator, technician, or manager of your organization.
Make sure you know your users well enough based on work you've done or research done. If not, take the time to broaden your understanding of users.
Use them as a block of communication about the basic type of interaction that should be considered as part of the user experience. Remember that the card does not have to reflect every detail of this interaction. See more info here
Acceptance criteria for user story
The acceptance criteria help, in particular, to understand whether the user's wishes have been fulfilled. They accompany the communication between the developer and the user or his representative and are evaluated before development begins. Record them on the back of the card only if the team thinks they contain user considerations that might be forgotten in the future. Sometimes writing acceptance criteria on a card is useful if a user or user representative is unavailable and there is no one to substitute for a personal meeting.