Prepare sprint backlog

- [Instructor] We had identified several requirements in our previous iteration, which grouped into three big themes. Now it's time to prioritize them, so that we can pick what to implement in our next iteration. At a detailed level, this is the list from which we need to prioritize. Requirement prioritization is a fairly intensive and important activity, and you need to work with your stakeholders to help you prioritize. There are many techniques to do this, which I have explained in detail in my course on developing effective requirements. Here I used a simple ranking based on requirement dependency to come up with first cut prioritization. I have ranked requirements that other requirements depend on with a higher priority. For example, to compare two products I should be able to first search for them. Similarly, to record a meal, I need to first search for food products to add to the meal. So search is my first priority, ranked as one. In this way I rank them from one to five. There may be some requirements that you may not have enough clarity about at this point, so you can leave them unranked as of now, which I have done for some of them, as you can see. From here, using scrum methodology we can now create our product backlog, which is nothing but a prioritized list of requirements. Depending on how much clarity we have about these requirements, we may also write them out as user stories. Whichever way we do, we need to pick the highest priority requirements, write them out in the form of user stories, if not already done so, come up with effort estimates, and see how many we can deliver in next sprint. So in our case, let us assume that we think we can deliver the first three requirements, that is search by product name, display food product nutrients, and compare food products by their nutrients. This list then becomes our sprint backlog. A slightly different view of prioritized requirements, especially if you have your requirements written down as user stories, is a story map. We write the user stories on index cards, group them into themes, and then pin them up on a wall. The horizontal axis shows workflow, indicating some kind of requirement dependency, and the vertical axis shows priority that we arrived at through our first cut prioritization. The story map is also a form of product backlog, but with a little more structure and information to it. Now, let us go back to our sprint backlog and pick up our first user story to implement. Our highest priority requirement is search, and its user story can be written as, "As a user, I want to search for a food product "by name so that I can see its nutritional value." This user story takes care of first two requirements of showing a list of products, and their nutrients. If you want to specify search requirement in the form of a use case specification, it may look like this. User is the primary actor, with no secondary actor. The precondition is that user should have access to the application at the given URL. Then in basic flow, user initiates the use case by choosing the search option, and provides key words to search for. Red30 responds with a list of products and nutrients displayed as needed, and use case ends successfully. The ultimate flow may be that Red30 could not find any product with the given key words, and the use case fails. Now that we have articulated the search user story and use case, let us move on to its design and development.