1 00:00:00,005 --> 00:00:02,009 - [Instructor] We had identified several requirements 2 00:00:02,009 --> 00:00:05,005 in our previous iteration, which grouped 3 00:00:05,005 --> 00:00:07,004 into three big themes. 4 00:00:07,004 --> 00:00:10,008 Now it's time to prioritize them, so that we can pick 5 00:00:10,008 --> 00:00:14,001 what to implement in our next iteration. 6 00:00:14,001 --> 00:00:16,006 At a detailed level, this is the list 7 00:00:16,006 --> 00:00:19,001 from which we need to prioritize. 8 00:00:19,001 --> 00:00:22,001 Requirement prioritization is a fairly intensive 9 00:00:22,001 --> 00:00:24,008 and important activity, and you need to work 10 00:00:24,008 --> 00:00:27,006 with your stakeholders to help you prioritize. 11 00:00:27,006 --> 00:00:29,007 There are many techniques to do this, 12 00:00:29,007 --> 00:00:32,000 which I have explained in detail in my course 13 00:00:32,000 --> 00:00:34,006 on developing effective requirements. 14 00:00:34,006 --> 00:00:37,002 Here I used a simple ranking 15 00:00:37,002 --> 00:00:39,003 based on requirement dependency 16 00:00:39,003 --> 00:00:42,004 to come up with first cut prioritization. 17 00:00:42,004 --> 00:00:45,001 I have ranked requirements that other requirements 18 00:00:45,001 --> 00:00:47,008 depend on with a higher priority. 19 00:00:47,008 --> 00:00:50,002 For example, to compare two products 20 00:00:50,002 --> 00:00:53,005 I should be able to first search for them. 21 00:00:53,005 --> 00:00:57,000 Similarly, to record a meal, I need to first search 22 00:00:57,000 --> 00:00:59,005 for food products to add to the meal. 23 00:00:59,005 --> 00:01:03,005 So search is my first priority, ranked as one. 24 00:01:03,005 --> 00:01:07,001 In this way I rank them from one to five. 25 00:01:07,001 --> 00:01:09,008 There may be some requirements that you may not have 26 00:01:09,008 --> 00:01:12,001 enough clarity about at this point, 27 00:01:12,001 --> 00:01:14,006 so you can leave them unranked as of now, 28 00:01:14,006 --> 00:01:18,001 which I have done for some of them, as you can see. 29 00:01:18,001 --> 00:01:22,002 From here, using scrum methodology we can now create 30 00:01:22,002 --> 00:01:24,005 our product backlog, which is nothing 31 00:01:24,005 --> 00:01:27,006 but a prioritized list of requirements. 32 00:01:27,006 --> 00:01:30,000 Depending on how much clarity we have 33 00:01:30,000 --> 00:01:33,002 about these requirements, we may also write them out 34 00:01:33,002 --> 00:01:35,002 as user stories. 35 00:01:35,002 --> 00:01:37,002 Whichever way we do, we need to pick 36 00:01:37,002 --> 00:01:39,009 the highest priority requirements, 37 00:01:39,009 --> 00:01:42,004 write them out in the form of user stories, 38 00:01:42,004 --> 00:01:46,005 if not already done so, come up with effort estimates, 39 00:01:46,005 --> 00:01:50,004 and see how many we can deliver in next sprint. 40 00:01:50,004 --> 00:01:54,005 So in our case, let us assume that we think 41 00:01:54,005 --> 00:01:57,002 we can deliver the first three requirements, 42 00:01:57,002 --> 00:01:59,006 that is search by product name, 43 00:01:59,006 --> 00:02:01,007 display food product nutrients, 44 00:02:01,007 --> 00:02:04,009 and compare food products by their nutrients. 45 00:02:04,009 --> 00:02:08,004 This list then becomes our sprint backlog. 46 00:02:08,004 --> 00:02:11,006 A slightly different view of prioritized requirements, 47 00:02:11,006 --> 00:02:14,004 especially if you have your requirements written down 48 00:02:14,004 --> 00:02:17,007 as user stories, is a story map. 49 00:02:17,007 --> 00:02:20,005 We write the user stories on index cards, 50 00:02:20,005 --> 00:02:24,004 group them into themes, and then pin them up on a wall. 51 00:02:24,004 --> 00:02:27,004 The horizontal axis shows workflow, 52 00:02:27,004 --> 00:02:30,004 indicating some kind of requirement dependency, 53 00:02:30,004 --> 00:02:33,005 and the vertical axis shows priority 54 00:02:33,005 --> 00:02:37,003 that we arrived at through our first cut prioritization. 55 00:02:37,003 --> 00:02:40,009 The story map is also a form of product backlog, 56 00:02:40,009 --> 00:02:44,005 but with a little more structure and information to it. 57 00:02:44,005 --> 00:02:47,005 Now, let us go back to our sprint backlog 58 00:02:47,005 --> 00:02:50,009 and pick up our first user story to implement. 59 00:02:50,009 --> 00:02:53,006 Our highest priority requirement is search, 60 00:02:53,006 --> 00:02:56,004 and its user story can be written as, 61 00:02:56,004 --> 00:02:59,004 "As a user, I want to search for a food product 62 00:02:59,004 --> 00:03:03,006 "by name so that I can see its nutritional value." 63 00:03:03,006 --> 00:03:07,000 This user story takes care of first two requirements 64 00:03:07,000 --> 00:03:10,003 of showing a list of products, and their nutrients. 65 00:03:10,003 --> 00:03:12,008 If you want to specify search requirement 66 00:03:12,008 --> 00:03:15,005 in the form of a use case specification, 67 00:03:15,005 --> 00:03:17,002 it may look like this. 68 00:03:17,002 --> 00:03:21,006 User is the primary actor, with no secondary actor. 69 00:03:21,006 --> 00:03:24,003 The precondition is that user should have access 70 00:03:24,003 --> 00:03:26,008 to the application at the given URL. 71 00:03:26,008 --> 00:03:30,005 Then in basic flow, user initiates the use case 72 00:03:30,005 --> 00:03:34,000 by choosing the search option, and provides key words 73 00:03:34,000 --> 00:03:36,000 to search for. 74 00:03:36,000 --> 00:03:39,002 Red30 responds with a list of products and nutrients 75 00:03:39,002 --> 00:03:44,000 displayed as needed, and use case ends successfully. 76 00:03:44,000 --> 00:03:47,007 The ultimate flow may be that Red30 could not find 77 00:03:47,007 --> 00:03:49,008 any product with the given key words, 78 00:03:49,008 --> 00:03:52,002 and the use case fails. 79 00:03:52,002 --> 00:03:55,007 Now that we have articulated the search user story 80 00:03:55,007 --> 00:04:00,000 and use case, let us move on to its design and development.