In the last video, you learned about a Product Backlog. We discussed that in order to properly build the Backlog, the project manager must consider factors like descriptions, value, order, and estimations. This ensures that you, as the project manager, will include enough information to meet the Product Owner's vision for user value. Now that you know about the various fields associated with each item in your Backlog, let's discuss a popular way to capture and manage those Backlog items, user stories. User stories are short, simple descriptions of a feature told from the perspective of the user. This helps the team create a solution that's always centered around the user and the user experience. User stories might start off large and broad or may be broken down to be as small or as specific as possible. In this lesson, we're going to give you some ideas on how to write user stories and how to break them down. User stories are made up of three different elements: the user, the action they will take, and the benefit to them. These elements might have a few different formats, but the most common is "As a <user role>, I want this <action> so that I can get this <value>." When writing effective user stories, the team must have a user in mind. Imagine that the user will interact with the product in order to achieve a specific outcome. What I really like to do at this stage is create personas or detailed descriptions of my different users. Sometimes I even give them names. In Virtual Verde, we could give our users some names and some information about them. Here are some user persona ideas. Leo is my plant vendor, who manages acquiring the plants, the supply chain, and delivery logistics. Felicity is my gardening expert, who helps my support team give our customers really excellent advice on how to take care of their plants. Zach is my amateur vegetable gardener, who wants to use the plants they purchase to make dinner. Nia is my management consultant, who works from home and wants to set up a professional backdrop for video conferences in their home office. Reena is my flower aficionado, who wants to have a different flower arrangement each week to brighten up their home. By giving these users a name and a backstory, we can imagine them in our minds and we will design better products for them as a result. I really enjoyed writing user stories because it puts me in the shoes of my users. Each user story should meet six different criteria, represented by the acronym I.N.V.E.S.T., or invest. I, for independent: the story should be able to be started and finished by itself. It's not dependent on another story to finish it. The N stands for negotiable: there's room for negotiation and discussion about this item. The V is for valuable: this means that completing the user story has to deliver value. E is for estimable: our Definition of Done must be clear so that the team can give each user story an estimate. The S is for small: each user story needs to be able to fit within a planned Sprint. If that user story is too big, it should be broken down into smaller stories. Stories that are a low priority on the Backlog can stay big until they become a priority for an upcoming Sprint. Finally, the T is testable: a test can be written to check and make sure that it meets the acceptance criteria. While the Product Owner is the main person responsible for writing user stories, the team has a responsibility to give feedback on whether the user story is clear and fits the invest criteria before they invest any time into it. In addition to user stories, you need to know the term epic, which simply represents a group or collection of user stories. Some epics for Virtual Verde might be live plant delivery, office plant advice service, vendor management, or client data management. Let's come up with a sample user story for our Virtual Verde clients in the live plant delivery epic. As a Virtual Verde client, I would like to acquire a bonsai tree so that I can have a beautiful plant and I can meditate as I trim the branches. I thought of this one because I bought a bonsai tree for my 12-year-old nephew last year. He did some research and learned that in Japan, pruning bonsai trees is a meditative practice. He's learning how to do that. With that sample user story, the Product Owner creates something called the acceptance criteria, which is essentially the checklist you will use to decide whether the user story is done. To have a completed user story, you must meet the acceptance criteria checklist. Here's an example of acceptance criteria for the bonsai tree user story. Users can: Browse for three different types of bonsai trees to purchase. Compare the three trees to know which is easiest and hardest to grow in their home. Maybe each plant has a beginner, intermediate, and advanced gardener notation next to it. Can purchase specific bonsai tree care packages like fertilizer, trimming shears, etc. Access online to a bonsai booklet sheet, as well as having a care booklet packaged with the tree. Can find a troubleshooting bonsai tree issues page on Virtual Verde's FAQ page. Sounds like an amazing story, doesn't it? It feels like a real thing that a user can interact with and get excited about. Each user story in the Backlog should be written this way. It's natural for items higher on the priority list to have more detail and fewer gray areas. By leaving these low-priority items vague, this saves the team time from working on items that may end up getting deprioritized down the road. Fantastic. Now you know how to explain user stories, the criteria for assessing user stories readiness for the team, and you can explain epics and user stories acceptance criteria. In the next video, we'll discuss Backlog refinement and explain relative effort estimation, T-shirt sizes, and story points. Meet you there.
