In this lesson, we're going to learn about what good user stories look like, and then we'll take a few examples and see how we can make them look good. To remember the characteristics of a good user story, remember INVEST. It's an acronym that was coined by Bill Wake that encompasses all the good characteristics of a user story. So, I stands for independent. So we want our stories to be independent of each other. It helps with the implementation of software development so that when we are working on one, we are not dependent on another one to be finished. Again, it's not possible to make all stories independent but we try to make our stories as much as we can. Negotiable, we want to leave some of the details for the discussions later. We don't want to decide everything about how we're going to do it and exactly how this is going to happen earlier in the process because that eliminates all potential better ways of doing it. So leave the details sometimes to the expert or to your discussions later on. Valuable, so we want to make sure that the work that we are doing is valuable to the user. Estimable, so we want to create a story that we can estimate. Small, we don't want our stories to be too big that takes a long time to develop and then release it. We want to continue to show progress. And in the spirit of continue to deliver working software to the user, we want our user stories to be small. And Testable, we want to validate that we actually finished what was designed so our work was expected, so we want our stories to be testable. Otherwise, there is a very gray area as to whether this is done or not. Now, these criteria or these characteristics are just a general guideline. Don't get bogged down by the dogma. The main goal is to build the right stuff for the customer. So, they are just guidelines. Use them to help create better stories, but don't get stuck by these. Let's take some examples now and see how we can make those stories better. Let's look at the first one. "As a developer, I want to finalize the database table changes." So really, this doesn't really provide direct value to the user. And so, I would either delete this story or convert this into a task. This is more like a task to probably do something for the user. Maybe there is a business functionality that the user is trying to build, and this is one of the tasks. "As a Manny's food service customer, I want to see different food item types displayed in different colors. For me, it's this color for grains and this color for vegetables and fruits so that I can quickly identify my food items by food type." Again, this one breaks the law of negotiable, so you provide too much detail about these colors, that these are the exact colors. I think what the user really wanted was for the different item types to stand out. So instead of this, we can just say, "As a Manny's food service customer, I want my custom item code to stand out so that I can find it on the screen more quickly." Another example, "As a business user, I would like a report of item profitability so that I can identify and highlight profitable items and consider what to do about underperforming items." So in this case, the report of item profitability is not clear how you're going to validate or test or what functionality is looking for. So we can change it to, "As a marketing manager considering how to spend limited marketing dollars, I need a report of the most/least profitable items so that I can identify and highlight profitable items and consider what to do about underperforming items." Another one, "As a customer ordering food, I want to locate previous food order lists so that I can see all the list that I have." Now, it does specify the why, but it doesn't really specify how does it help the customer. If you can see all the lists that I have, how does it really help? So I think, we need to improve the why of this story. So we can write it in such a way that, "As a customer ordering food, I want to see my saved food order lists so that I can reuse the list for future orders, making ordering faster and more accurate." So again, now, the why is much clearer as to what the value it provides to the customer. Another one, "As a tester, I want to have detailed test plans so that when the system is completed, I can test the system." This is more like a task overall for testers that they need to do. So again, I would convert this as part of other stories as a task. So really delete this story, I don't think it provides value to the user. Now, let's look at these three stories. "A company can pay for a job posting with a Visa card", "A company can pay for a job posting with a Master card", "A company can pay for a job posting with an American Express card." It makes these three stories very dependent on each other because whichever story you will do first will create the major work for supporting the credit card, and the other two stories will be small. So again, this makes three stories dependent on each other. Instead of that, we could write, "A company can pay for a job posting with one type of card, and then a company can pay for the job posting with two additional type of cards." So now, we reduce the dependency between just these two stories. Another one, "A user must find the software easy to use." Now, this one is very difficult to test. So I would reword this to, "A novice user can use the software without a need of training." So, this clearly specifies that if somebody can use the software without need of training then I would consider this story to be done.
