Welcome to this course. This course is stories, story writing, backlogs, planning and prioritization. This video is user-stories. This course is a presentation of Learn Quest. User stories are just a brief description of user functionality, or a feature, or some type of capability that a user needs. They generally describe features and, or capabilities. They are written on a template and they are meant to be brief descriptions. When you need more information, the product owner must deliver that information to the team that's part of the product owner's role. If we take a quick look at this user story template, we have our title, our priority. Later on, we'll estimate it, and again, here is the template and the template does enforce consistency and brevity. We described the functionality in this top section here, and then there's acceptance criteria which provides a framework for a test case. When stories were first written, they were actually written on post-it notes or index cards, so that is why there is so much of an effort to keep stories brief and to fill in the gaps if needed. We can see again here, the first part of the template as a, and then there's the user role I want and describe the functionality. That, and then there's business value. We can see here as a cyclist, I want to track the location of my friends so that I can join them on rides. We can see the role here, the functionality and the business value, and the idea here is to reverse engineer, the team needs to reverse engineer how to implement this functionality. Who writes stories? Stories are typically written by the team. The team takes the stories from the backlog and breaks them down if needed, and formally enters them into the template. The team is going to be building them, so this is a great exercise for the team to become more familiar with the stories. However, anyone can submit a story. Stories can be submitted by stakeholders, analysts, users, or customers. The product owner must approve all stories, and they must be formally added to the product backlog and prioritized. One way to think about a story is the four Cs. We have the card and the card, the purpose there, it formats the story. So we have the template, and it makes it consistent and relatively brief. We have the preconditions. To maximize effort by ensuring only user stories that are ready to be put into the backlog or to be put into the sprint. The conversation is with the product owner typically and tracks all records of changes, and the confirmation. The confirmation is that acceptance criteria. How will we know when the story is done? There is acceptance criteria, and that acceptance criteria lets us know the story's been properly implemented, and testers use that acceptance criteria as a framework for their test case. Also, there is the INVEST story criteria. Stories should be independent so they can be implemented completely on their own. They are not dependent upon any other story. If they are dependent, the team may want to combine stories. Negotiable, so the details are worked out collaboratively by the team. In other words, this is questions or answered information is provided by the product owner. Obviously, the stories need to be valuable to the customer. They need to be understood well enough that they can be estimated. They need to be sized to fit into a single sprint, and they need acceptance criteria so they can be tested and verified. Acceptance criteria is also written on a template. The confirmation part of those 4 Cs is the acceptance criteria, and acceptance criteria provides the steps needed to ensure that the story has been implemented correctly and it requires the user functionality. A popular way to implement acceptance criteria is to use behavioral-driven development, BDD. This is an approach that uses a BDD template, and it works like this given, and some kind of a setup when an action, this is an action or a trigger, then there is some kind of assertion. We can see here, given the workflow exists, when I request a GET API, then Workflow should run their jobs. You can see here, especially when this template is filled in how a tester could expand this acceptance criteria to an actual test case, and that's the idea. We have this very, very basic acceptance criteria and then testers expand on it to make sure that it covers everything it needs to cover and that it's clear and expresses all the steps for a tester. The complete user story again has the title, the priority, the estimate, describes the user story and has acceptance criteria. The user story templates today have been moved away from index cards and post-it notes to web tools and web tools still support the template. We can see the acceptance criteria right here in the description. The good thing about web tools are we can attach additional information, attach sketches. We are not so worried about the story taking up a lot of room. We don't have to force everything onto a post-it note, so the web tools give us a way to format, a web tools give us different ways to view stories, view the backlog, view the progress. The web tools for stories in Agile are certainly a great advancement beyond the physical backlogs and the physical cards from not too long ago. What's next? We are going to continue to discuss Scrum basics.
