what are user stories?

Section #1. What are user stories? Talking about the different story types and giving real world user story examples. We will look at how sub-tasks are such an integral part to resolving user stories and how to write great sub-tasks Section #2. Questions about User Stories Who is responsible to write user stories? When do we write user stories? Let’s find out together in section 2. Section #3. Planning User Stories How do we plan user stories to get the best value result? What is story mapping and how can it help us plan priorities better? Section #4. The relevance shift Talking about the shift in priority relevance. A priority can lose its relevance without losing its priority level Section #5. Why User Stories? Why would you need to work with user stories? How can user stories help you be more efficient in achieving sprint goals Section #6. Resources & FAQs Download here the document for SEO measurements taken to improve ranking of this article. FAQs about user stories. What are user stories? User stories, as the name implies, are pieces of information that indicate a user centred requirement that when put together, will form a new system behaviour of the end product. A user story is an integral part of the product backlog, team backlog and the sprint board. Simply put, companies need to make money, and for that to happen, business analysts, sales and many other stakeholders need to communicate the requirements to the scrum teams. Companies make use of known communication systems to effectively communicate requirements and secure timely delivery in adherence with the original request. The ideation of user stories comes from the need to create a more informal communication that is actionable in an estimable amount of time. Basically, what worked in the past has no place in the ever changing, ever growing present. Depending on the type of venture or enterprise, business requirements and KPIs can change in such a way that would require companies to be flexible and adaptive to create the best competitive advantage in their industries. What makes a user story great? As Bill Wake puts it, a great user story follows the INVEST model Let’s break down this user story! ‘As a user…‘ The story starts with these words. Here, the team had decided to use the ‘user’ term only to refer to the end user. The user could also be an administrator or a developer or a stakeholder such as marketing or sales. Identifying the right user would allow the team to develop the requested functionality and create user tests. This user story meets the DoR (definition of ready), because it follows a format that ensures complete information for converting the story into technical requirements. ‘I want…‘. These next words indicate to the team what the user wants to be able to achieve, and here is where the team looks for a specific goal that the user wants to be able to achieve which would complement the overall user experience. In the example provided, the user would like to be able to set custom market movers parameters so that they can have a personalised watchlist of the trade-able instruments that are causing change in markets. ‘So that…’. This is an integral part of the conversational user story format as it indicates the monetising reason to satisfy the user needs. What will the user get from achieving their goal? What does it mean for the business? It gives an immediate understanding of why building the feature part of the user story is profitable for the user and the business. In the example above, the user wants to be able to take advantage of short term trading (A.K.A swing or day trading). Market movers filters can help the user do this by eliminating missed opportunities on trending markets. The above mentioned user story format aids the scrum team to convert stories into technical requirements. Technical requirements need to be specific for the team to understand what exactly they need to build. The above user story structure ensures information is correct and complete, however you may notice that the user story is not technical and specific enough to be able to create a proper technical requirement. The user story asks for custom movers for the users of the app, so that they can create a list of instruments that fall under their interested trends. However, user stories are not technical. This means that sometimes, teams need to break down a user story into sub-tasks. How do you build subtasks? Well subtasks are usually more technical pieces of information than a user story. They are the breakdown of user stories that represent the amount of effort a team will take to achieve the parent user story. Through the many years working as a product owner, I’ve seen many scrum teams struggle writing qualitative subtasks. Well here’s how we made our subtasks great! #1 A subtask should resolve one or more acceptance criteria defined in the user story. If it’s not resolving at least one acceptance criteria, there’s a high chance your sub-task is irrelevant to its mapping. Keep building subtasks until you have a subtask for each acceptance criteria, you don’t need more, and you must not have less. #2 We wrote test scenarios for each user story. Test scenarios, allow the scrum team to test their work from a user perspective. That’s all there is to your subtasks and you can use any format for them. Below is how we broke down the subtasks for the example above. Notice how we always looked for ways to improve visual communication. We used square brackets at the beginning of each subtask so that the scrum team members can quickly visualise their responsibilities: From the screenshot above, you can see that for this particular user story, we had a subtask for each acceptance criteria and an extra subtask to request the designs from the design team. The scrum team measures user story achievement through