1 00:00:00,360 --> 00:00:03,960 The Better Business Analysis Institute presence. 2 00:00:03,960 --> 00:00:07,760 The Better Business Analysis podcast with Hinjman Walsh. 3 00:00:12,640 --> 00:00:15,520 Hi everybody, it's Benjamin Walsh from the Better Business 4 00:00:15,520 --> 00:00:19,240 Analysis Institute and welcome back to the Better Business 5 00:00:19,240 --> 00:00:23,200 Analysis podcast. Now today we're going to get 6 00:00:23,200 --> 00:00:26,360 into a topic which is something I usually teach Bas. 7 00:00:27,290 --> 00:00:30,450 We're in the intermediate, moving to senior space. 8 00:00:30,970 --> 00:00:37,610 It can be the key to unlock a hack, which a lot of Bas don't 9 00:00:37,610 --> 00:00:43,210 really talk about or use. So I would say that this isn't a 10 00:00:43,210 --> 00:00:48,130 beginner BA topic, but in saying so if you learn this technique 11 00:00:48,170 --> 00:00:52,490 early on, and I didn't learn it until I was much into my senior 12 00:00:52,490 --> 00:00:57,300 BA career, this could, you know, hack your growth. 13 00:00:57,660 --> 00:01:02,100 It's a growth hack in terms of moving your career ahead a lot 14 00:01:02,100 --> 00:01:05,900 of patients, you know, potentially a year to or three. 15 00:01:06,820 --> 00:01:10,620 And it'll and this technique will allow you to steam ahead of 16 00:01:10,660 --> 00:01:15,220 some other Bas who are lost down in the problem that we call 17 00:01:16,420 --> 00:01:20,500 requirements management. And not just the management side 18 00:01:20,500 --> 00:01:23,840 of requirements, but effectively where do they come from? 19 00:01:24,000 --> 00:01:27,120 How do you know which requirements are important? 20 00:01:27,720 --> 00:01:32,000 Which stakeholders may more be more important than others? 21 00:01:32,240 --> 00:01:36,480 How do you know that this solution or this feature, this 22 00:01:36,480 --> 00:01:40,240 user story is more important than something else? 23 00:01:41,160 --> 00:01:43,640 So this I'm going to give you a scientific way. 24 00:01:43,640 --> 00:01:45,480 I'm not going to give you all the answers, but I'm going to 25 00:01:45,480 --> 00:01:50,880 give you a scientific way of applying this technique and it. 26 00:01:51,040 --> 00:01:56,120 This technique is called the PTRT model. 27 00:01:57,280 --> 00:02:01,160 Now, the PTRT model has been developed by the Better Business 28 00:02:01,160 --> 00:02:04,360 Analysis Institute after a lot of thinking, and we're going to 29 00:02:04,360 --> 00:02:08,400 talk about what that thinking is and why. 30 00:02:08,400 --> 00:02:10,240 This is the conclusion we've come up with. 31 00:02:11,680 --> 00:02:15,240 And I guess we should explain what PTRT stands for. 32 00:02:15,720 --> 00:02:21,240 So PTRT is simply processed to requirements thinking. 33 00:02:22,280 --> 00:02:25,400 OK, so we have design thinking in terms of how we design 34 00:02:25,400 --> 00:02:27,600 solutions. We have different types of 35 00:02:27,840 --> 00:02:32,440 hypothesis thinking. This specifically is for Bas and 36 00:02:32,440 --> 00:02:37,000 it is around process to requirements thinking. 37 00:02:38,920 --> 00:02:41,800 Now what is process to requirements thinking? 38 00:02:43,560 --> 00:02:50,160 It's really about the process, how processes relate to 39 00:02:50,160 --> 00:02:53,480 requirements. And at the end we'll talk about 40 00:02:53,800 --> 00:02:58,920 how this model allows you to extract requirements, the right 41 00:02:59,040 --> 00:03:02,400 requirements, the prioritized requirements, the must have 42 00:03:02,400 --> 00:03:06,040 requirements of whatever change program you're working on. 43 00:03:08,000 --> 00:03:12,840 Now there is a science is where we're trying to shove in science 44 00:03:12,840 --> 00:03:14,960 to requirements gathering, elicitation. 45 00:03:15,720 --> 00:03:20,530 And really where this PTRT has come from is like I said in 46 00:03:20,530 --> 00:03:24,610 terms of design thinking and the desire for a customer to 47 00:03:24,610 --> 00:03:28,250 complete a job. We use the term in product 48 00:03:28,250 --> 00:03:31,730 management. We use the term job to be done. 49 00:03:32,130 --> 00:03:36,330 So another way of looking at a job to be done is a set of 50 00:03:36,330 --> 00:03:41,770 process steps that a user or a customer needs to complete in 51 00:03:41,770 --> 00:03:47,210 order to get from A to B. They know the outcome B, the 52 00:03:47,210 --> 00:03:51,170 outcome they want to achieve. They know A, which is their 53 00:03:51,170 --> 00:03:54,130 starting point, but they don't necessarily know how to get from 54 00:03:54,170 --> 00:03:57,010 A to B or they might do in a theoretical sense. 55 00:03:57,330 --> 00:04:01,450 And really when we talk about solutions and two problems, 56 00:04:01,610 --> 00:04:04,650 that's what we're solving. So you can either look at the 57 00:04:04,650 --> 00:04:07,570 efficiency of that process, which is business improvement, 58 00:04:07,870 --> 00:04:11,390 you can look at it establishing a new process, you can look at 59 00:04:11,390 --> 00:04:14,830 establishing a new solution to solve a process problem. 60 00:04:15,030 --> 00:04:18,910 And that's effectively what the discipline of business analysis 61 00:04:18,990 --> 00:04:24,230 is all about. Now before I go into the PTRT 62 00:04:24,430 --> 00:04:31,030 model in detail, I think we should agree upfront because 63 00:04:31,030 --> 00:04:35,630 there is disagreement here by the way, on what types of 64 00:04:35,630 --> 00:04:41,650 requirements exist in the world. And we'll start with what the I, 65 00:04:41,650 --> 00:04:48,610 I BA, the International Business Analysis Association on how they 66 00:04:49,450 --> 00:04:54,370 categorize different types of requirements and they list them 67 00:04:54,370 --> 00:04:57,290 down into 5 categories. And I'll talk about what we here 68 00:04:57,290 --> 00:05:03,530 at the BBAI think about that. There's nothing wrong with this 69 00:05:03,530 --> 00:05:07,070 approach, but it is quite traditional in terms of how 70 00:05:07,070 --> 00:05:09,510 we've grouped and how we name these different requirements 71 00:05:09,510 --> 00:05:12,230 areas. And I'm going to explain what 72 00:05:12,230 --> 00:05:15,910 that I think that there is some fundamental challenge to that 73 00:05:15,910 --> 00:05:20,310 model and the fact that it doesn't help when we jump over 74 00:05:20,310 --> 00:05:24,390 to an agile model cause a lot of this has fallen out of 75 00:05:24,590 --> 00:05:29,350 traditional water for processes of what I would say as being 76 00:05:29,670 --> 00:05:33,630 full blow and documentation business analysis and not Lean 77 00:05:33,630 --> 00:05:38,190 BA which is where we are you know in 2023 or what you should 78 00:05:38,190 --> 00:05:41,830 expect from your BA's in 2023. OK. 79 00:05:41,830 --> 00:05:46,990 So what are these kind of areas or requirements type that we 80 00:05:46,990 --> 00:05:49,310 talk about? The first are business 81 00:05:49,310 --> 00:05:52,750 requirements and here at the institute, we agree business 82 00:05:52,790 --> 00:05:56,710 requirements is a really good term and that these, you know, 83 00:05:56,710 --> 00:06:01,590 these requirements are the highest level what that we need 84 00:06:01,590 --> 00:06:07,550 to capture that we need to achieve in order to deliver on 85 00:06:07,550 --> 00:06:13,390 the business objectives. So business objectives, how we 86 00:06:13,390 --> 00:06:17,470 measure the success of a project and below business objectives we 87 00:06:17,470 --> 00:06:21,110 have business requirements. So solving our business 88 00:06:21,110 --> 00:06:25,150 requirements at the highest level allows us to solve the 89 00:06:25,150 --> 00:06:28,870 business problem which we've defined in problem analysis. 90 00:06:30,430 --> 00:06:32,310 All right. So we totally agree that we've 91 00:06:32,310 --> 00:06:36,210 got business objectives which or strategic objectives of the 92 00:06:36,210 --> 00:06:38,650 business which is the most important thing and I talk about 93 00:06:38,650 --> 00:06:41,010 that and a couple of the other podcasts that we've talked 94 00:06:41,010 --> 00:06:43,130 about. It's all about business strategy 95 00:06:43,130 --> 00:06:47,450 and you know what, why we're doing this piece of work and how 96 00:06:47,450 --> 00:06:51,410 we're going to measure success and below that we have business 97 00:06:51,410 --> 00:06:52,850 requirements. So we start getting to the water 98 00:06:52,850 --> 00:06:55,490 be out here business requirements which come out of 99 00:06:55,490 --> 00:06:59,610 high level analysis. So totally agree that that is a 100 00:06:59,610 --> 00:07:03,260 requirements type. It is the overarching container 101 00:07:03,460 --> 00:07:08,820 of of requirement. Next, the I IBA talk about 102 00:07:08,900 --> 00:07:13,020 stakeholder requirement. OK and stakeholder requirements 103 00:07:13,420 --> 00:07:16,100 are the requirements that the stakeholder has. 104 00:07:16,100 --> 00:07:19,380 It represents their needs, their expectations of the individuals 105 00:07:19,380 --> 00:07:23,340 or group who have you know an interest in the project. 106 00:07:23,820 --> 00:07:28,140 These requirements, you know, you can extract through 107 00:07:28,140 --> 00:07:33,690 interviews or workshopping or surveys and they ensure that the 108 00:07:33,690 --> 00:07:36,450 solution meets the needs of the stakeholder. 109 00:07:36,610 --> 00:07:40,130 So it's it's, it's really important, it allows the 110 00:07:40,130 --> 00:07:44,250 solution to not be driven by it. It allows the stakeholder to 111 00:07:44,250 --> 00:07:49,090 have a voice and in essence we don't agree, disagree with that. 112 00:07:49,090 --> 00:07:53,530 Thinking behind that of course or the fact that you don't talk, 113 00:07:53,570 --> 00:07:56,050 you know you there is no reason to talk to customers about their 114 00:07:56,050 --> 00:07:56,930 needs. Of course there are. 115 00:07:57,090 --> 00:07:59,610 We actually take it even further to customer requirement. 116 00:08:01,030 --> 00:08:04,310 This is where we drift away from the scientific method a little 117 00:08:04,310 --> 00:08:09,670 bit and we can fall into a situation where we end up having 118 00:08:09,670 --> 00:08:16,270 a shopping list and and and some Bas don't even challenge that 119 00:08:16,270 --> 00:08:19,310 problem and they say that's the that's the job of the product 120 00:08:19,310 --> 00:08:20,990 owner. And this is where I completely 121 00:08:20,990 --> 00:08:23,870 disagree with that thinking or that attitude. 122 00:08:27,520 --> 00:08:30,240 Next, so we've got stakeholder requirements, if you like, the 123 00:08:30,240 --> 00:08:32,360 shopping list of things that stakeholders want. 124 00:08:32,360 --> 00:08:35,080 And then and of course that is one way that you extract 125 00:08:35,080 --> 00:08:38,039 requirements, but that isn't the solution or the method we're 126 00:08:38,039 --> 00:08:40,039 talking about. But obviously you talk to 127 00:08:40,039 --> 00:08:41,799 stakeholders, you ask them what they want. 128 00:08:41,960 --> 00:08:46,040 And there's a whole science behind necessarily knowing who's 129 00:08:46,080 --> 00:08:49,200 most, who's you know, who's most important in the zoo, which 130 00:08:49,200 --> 00:08:51,760 stakeholders most important. And you can lead on your product 131 00:08:51,760 --> 00:08:55,540 owner to help prioritize those. But ultimately these it's it's 132 00:08:55,540 --> 00:09:00,100 really subjective at this point. Next on the list of requirements 133 00:09:00,100 --> 00:09:02,300 type, there are solution requirements. 134 00:09:02,300 --> 00:09:06,860 The IRBA explicitly has a category called Solution 135 00:09:06,860 --> 00:09:10,820 requirements which is different to stakehold requirements. 136 00:09:10,820 --> 00:09:15,700 So they jump to the solution side and they say that solution 137 00:09:15,700 --> 00:09:17,780 requirements are the features and the functions and 138 00:09:17,780 --> 00:09:21,020 characteristics of the solution that will address the business 139 00:09:21,020 --> 00:09:25,120 problem. So they have, I guess you know, 140 00:09:25,120 --> 00:09:28,800 derived those solution requirements from the highest 141 00:09:28,800 --> 00:09:33,640 level business and stakeholder requirements and solution 142 00:09:33,640 --> 00:09:37,120 requirements are supposed to provide a detailed description 143 00:09:38,120 --> 00:09:41,920 of what the solution should do Okay. 144 00:09:42,880 --> 00:09:48,750 And at this point again the the we do not believe in the concept 145 00:09:48,750 --> 00:09:51,750 of solution requirements per se. We'll come back to that point in 146 00:09:51,750 --> 00:09:54,830 a minute. However, we do agree that at 147 00:09:54,830 --> 00:09:58,870 this point solution requirements generally in the concept term 148 00:09:59,550 --> 00:10:02,830 can be broken down into functional and non functional 149 00:10:02,830 --> 00:10:05,550 requirements. So functional requirements are 150 00:10:05,830 --> 00:10:09,470 the behavior of the solution that the user's interacting with 151 00:10:09,510 --> 00:10:14,030 and non functional requirements are the actually to the quality 152 00:10:14,030 --> 00:10:17,910 of the solution. So the solution must possess 153 00:10:17,910 --> 00:10:19,790 these things rather than behaviors. 154 00:10:20,070 --> 00:10:22,670 So non functional requirements are things like performance and 155 00:10:22,670 --> 00:10:24,510 security and usability and so on. 156 00:10:24,910 --> 00:10:33,270 So, so you've got those two parts and I agree that that 157 00:10:33,270 --> 00:10:37,680 we've got business that we have business requirements and then 158 00:10:37,680 --> 00:10:40,520 we have these functional and nonfunctional requirements of 159 00:10:40,520 --> 00:10:44,200 the solution. The IABA talks about those in 160 00:10:44,200 --> 00:10:48,680 terms of stakeholder requirement separate to the solution 161 00:10:48,840 --> 00:10:51,680 requirements and solution requirements and which under 162 00:10:51,680 --> 00:10:54,440 solution requirements they have functional and nonfunctional 163 00:10:54,440 --> 00:10:56,840 requirements. So in theory there's no problem 164 00:10:56,840 --> 00:11:02,460 with that model. But here the BBAI we agree that 165 00:11:02,460 --> 00:11:05,780 these that these things could be called solution requirements. 166 00:11:06,180 --> 00:11:09,740 But but actually in a real world scenario all those things in the 167 00:11:09,740 --> 00:11:12,540 solution bucket are called user stories. 168 00:11:12,540 --> 00:11:16,420 When we move into an agile world that there's no distinct 169 00:11:16,420 --> 00:11:19,780 difference between the fact therefore the solution or 170 00:11:19,780 --> 00:11:22,220 stakeholders, they all need to be met. 171 00:11:23,180 --> 00:11:25,860 But there is this difference. We've got these two buckets, 172 00:11:26,140 --> 00:11:30,700 those that the user wants and those in which the solution will 173 00:11:30,780 --> 00:11:37,470 deliver if you like the we'll hold that thought and we'll just 174 00:11:37,470 --> 00:11:39,830 talk about the last category of requirements. 175 00:11:40,110 --> 00:11:43,230 And and to be fair, this is a whole podcast in itself and 176 00:11:43,230 --> 00:11:46,830 probably a book and it's transitional requirements and 177 00:11:46,830 --> 00:11:51,030 these are not done well at all by Bas and are sometimes 178 00:11:51,030 --> 00:11:52,510 completely amidst by agile teams. 179 00:11:52,870 --> 00:11:56,830 Transitional requirements are activities, tasks and conditions 180 00:11:57,260 --> 00:11:59,740 necessary to transition from the current future state. 181 00:12:00,020 --> 00:12:03,460 And if actual tangible things like data migration, plan 182 00:12:03,460 --> 00:12:05,940 training, you know, change management, implementation, 183 00:12:05,940 --> 00:12:09,980 planning, and a lot of times B A's are very, very bad at 184 00:12:09,980 --> 00:12:13,470 defining these, I wouldn't say I'm particularly that great, but 185 00:12:13,470 --> 00:12:14,870 they're things that need to be done. 186 00:12:14,870 --> 00:12:17,950 And so yes, I do agree that they are a set of requirements and 187 00:12:17,950 --> 00:12:21,510 they usually never define and use the stories or backlogs, but 188 00:12:21,830 --> 00:12:26,070 they could sometimes be sections within your requirements pack. 189 00:12:26,070 --> 00:12:28,750 I think they should be. And that's how I do them today. 190 00:12:29,310 --> 00:12:31,350 But they don't necessarily use the stories in themselves. 191 00:12:31,550 --> 00:12:35,150 You could argue their tasks within the project that need to 192 00:12:35,150 --> 00:12:38,110 be complete and they're usually owned by things like the change 193 00:12:38,110 --> 00:12:41,150 manager or the trainer, or you know the project manager 194 00:12:41,150 --> 00:12:43,350 themselves. And we as Bas would be a 195 00:12:43,710 --> 00:12:48,150 subservient there and it would help on because those need to be 196 00:12:48,150 --> 00:12:50,430 done and you know you all muck in. 197 00:12:50,470 --> 00:12:53,870 Be a good ba mucks in. That might not be your primary 198 00:12:53,950 --> 00:12:57,710 ownership or focus however okay. Cool. 199 00:12:58,270 --> 00:13:03,240 So the BA separates, as I said, sorry, the IABA separates the 200 00:13:03,240 --> 00:13:05,000 stakeholder requirements and solution requirements. 201 00:13:05,280 --> 00:13:08,120 So what the user they they separate what the user wants 202 00:13:08,360 --> 00:13:11,400 from what the solution effectively does. 203 00:13:11,640 --> 00:13:13,920 OK. So that's that's the difference 204 00:13:13,920 --> 00:13:16,200 there. At the Better Business Analysis 205 00:13:16,200 --> 00:13:20,200 Institute, we believe that the solution only exists to help the 206 00:13:20,200 --> 00:13:24,000 user or customer get their job to be done OK or get their job 207 00:13:24,000 --> 00:13:26,000 done. So we talked about that before 208 00:13:26,590 --> 00:13:28,590 for the truth that we believe that you know they're 209 00:13:28,670 --> 00:13:31,870 intertwined. They're completely intertwined 210 00:13:31,870 --> 00:13:37,310 with one another and they need to be treated in terms of the 211 00:13:37,310 --> 00:13:39,950 statements, the user stories or the requirements. 212 00:13:40,190 --> 00:13:44,030 They need to reflect both the stakeholders prioritization, 213 00:13:44,030 --> 00:13:49,110 which is the so that I can and the why needs to represent the 214 00:13:49,110 --> 00:13:54,780 stakeholders prioritization or how they see held. 215 00:13:54,780 --> 00:14:00,940 This is important, but not only are they these stakeholder 216 00:14:00,940 --> 00:14:05,700 requirements, a way to drive the prioritization of a solution 217 00:14:05,700 --> 00:14:08,820 requirement, there's something else missing, which is the fact 218 00:14:09,060 --> 00:14:12,460 that in order for a customer or a user to get their job done, 219 00:14:12,820 --> 00:14:14,940 they have to actually follow a sequence. 220 00:14:15,180 --> 00:14:18,060 They have to get from A to B, and there will be a number of 221 00:14:18,060 --> 00:14:22,260 steps in which they need to follow an order in order to get 222 00:14:22,260 --> 00:14:23,900 from A to B. Now, those steps could be 223 00:14:23,900 --> 00:14:26,500 completely different depending on the analyst that's involved. 224 00:14:26,940 --> 00:14:30,950 But the stakeholder requirements for what the IOB A calls the 225 00:14:30,950 --> 00:14:33,750 stakeholder requirements, I'm going to say there is some truth 226 00:14:33,990 --> 00:14:37,990 to the sequencing in which a user needs to interact with the 227 00:14:37,990 --> 00:14:41,670 system or, you know, follow a process step from A to B, and 228 00:14:41,670 --> 00:14:45,990 that is the size. So how do we define the A to B? 229 00:14:46,030 --> 00:14:48,190 How do we define getting from A to B? 230 00:14:48,190 --> 00:14:52,030 How do we actually do that as a business analyst? 231 00:14:54,430 --> 00:15:00,470 OK, so we'll step back. The I I BA has defined different 232 00:15:00,470 --> 00:15:03,670 requirement categorization with business requirements completely 233 00:15:03,670 --> 00:15:06,950 on board with that. Then they define stakeholder and 234 00:15:06,950 --> 00:15:10,070 solution requirements separately and under solution requirements, 235 00:15:10,070 --> 00:15:12,230 they have functional and nonfunctional requirements. 236 00:15:12,270 --> 00:15:15,110 And finally, if you like right down the bottom, there are 237 00:15:15,950 --> 00:15:18,470 transitional requirements which are tasks that need to be done 238 00:15:18,470 --> 00:15:22,470 in order to deliver a change. Quite happy with that and 239 00:15:22,470 --> 00:15:25,850 conceptual world and an agile world. 240 00:15:25,850 --> 00:15:29,370 I'm just going to restate those business requirements are at the 241 00:15:29,370 --> 00:15:31,370 highest level. They can also be called Epics 242 00:15:31,370 --> 00:15:33,250 and I'll get to that point in a minute. 243 00:15:33,730 --> 00:15:36,730 And what I would say in an agile world solution requirements 244 00:15:36,730 --> 00:15:39,730 regardless of functional, nonfunctional requirements, they 245 00:15:39,730 --> 00:15:42,530 use the stories and generally transitional requirements are 246 00:15:42,530 --> 00:15:44,250 tasks. So if you live in an agile 247 00:15:44,250 --> 00:15:47,770 world, that is the name you give to those same areas. 248 00:15:48,650 --> 00:15:54,370 And here the BBA I we don't disagree that there are that you 249 00:15:54,370 --> 00:15:56,050 can break requirements down that way. 250 00:15:56,250 --> 00:15:59,770 But what we say is that user stories, you know, leaning on 251 00:15:59,770 --> 00:16:02,610 agile and we'll get there in a minute, that user stories that 252 00:16:02,610 --> 00:16:05,250 solution require solution requirements aren't any 253 00:16:05,250 --> 00:16:09,410 different or shouldn't be thought about as separately to 254 00:16:09,410 --> 00:16:11,450 stakeholder requirements and they need to come together. 255 00:16:11,730 --> 00:16:14,450 And now we're going to talk about how we make that happen. 256 00:16:14,450 --> 00:16:17,690 All right. Now before I tell you all the 257 00:16:17,690 --> 00:16:25,710 secrets about PTRT, we are going to go back in time. 258 00:16:26,230 --> 00:16:30,190 We're going to go back and look where requirements modeling was 259 00:16:30,190 --> 00:16:34,110 first standardized for software development because there was a 260 00:16:34,110 --> 00:16:37,950 lot of signs back then. It was quite different to where 261 00:16:37,950 --> 00:16:40,430 we are today. We're a little bit looser and 262 00:16:40,430 --> 00:16:42,230 and that's good. That's given us flexibility, 263 00:16:42,230 --> 00:16:46,990 that's given us, you know, excuse the pun agility, but 264 00:16:47,340 --> 00:16:49,540 there was some science back then and I'm going to, I'm going to 265 00:16:49,540 --> 00:16:53,780 lean on that and explain what that was back when I was at 266 00:16:53,780 --> 00:16:57,620 university and explained A technique that's very useful in 267 00:16:57,620 --> 00:17:02,300 the agile world for doing this. And then finally summarize what 268 00:17:02,420 --> 00:17:07,180 we take that to the next level. You as a BA, what that means in 269 00:17:07,180 --> 00:17:10,460 terms of process to requirements thinking. 270 00:17:12,869 --> 00:17:16,109 OK, so I went to university in the 2000s that shows my age. 271 00:17:16,109 --> 00:17:19,030 I did a computer science degree, actually, I I actually studied 272 00:17:19,030 --> 00:17:23,550 programming, but I enjoyed the systems analysis papers the most 273 00:17:23,550 --> 00:17:27,589 as well as the economics business papers and psychology 274 00:17:27,589 --> 00:17:30,830 papers more so than I did any programming. 275 00:17:30,830 --> 00:17:34,830 I wasn't particularly that interested in terms of that or 276 00:17:34,830 --> 00:17:36,830 it just wasn't as good as everyone else in the class. 277 00:17:36,830 --> 00:17:39,670 And maybe that's what sparked my interest in terms of other 278 00:17:39,670 --> 00:17:42,630 areas. But either way, when we learned 279 00:17:44,490 --> 00:17:47,130 what was called systems analysis back then, and when we had to do 280 00:17:47,130 --> 00:17:50,970 analysis papers, we learned something called UML. 281 00:17:51,370 --> 00:17:54,210 Now if you haven't heard of UML before, that's OK. 282 00:17:54,610 --> 00:17:59,650 I'm sure those who are over 40 may have heard of UML. 283 00:18:01,090 --> 00:18:04,530 Or if you haven't, and you're in the Agile world, I wouldn't 284 00:18:04,530 --> 00:18:05,930 surprise if you just haven't heard of it. 285 00:18:06,620 --> 00:18:09,300 It's really important to understand what UML is. 286 00:18:10,060 --> 00:18:15,100 It stands for Universal Modeling Language and if you've ever used 287 00:18:15,100 --> 00:18:18,980 tools like Rational Roads or Enterprise Architect or tools 288 00:18:18,980 --> 00:18:23,660 like Visio or Draw dot io, you sometimes see names of stencils. 289 00:18:23,660 --> 00:18:26,780 And this might be where you've heard some of the terms that 290 00:18:26,780 --> 00:18:32,450 relate to UML. Not only that, you may have 291 00:18:32,450 --> 00:18:35,250 heard the term that's used in language quite often, which is 292 00:18:35,250 --> 00:18:40,450 called Use Case and Use case. Use Cases and Use case Modeling, 293 00:18:40,730 --> 00:18:44,650 comes from UML. So what what you know what was 294 00:18:44,770 --> 00:18:49,250 UML and what did it kind of what we we what do we used to use it 295 00:18:49,250 --> 00:18:50,450 for And we still use it this way. 296 00:18:50,450 --> 00:18:53,210 By the way, a lot of Bas who especially those in the 297 00:18:53,290 --> 00:18:57,610 technical BA space, use UML. I still think it's fantastic to 298 00:18:57,610 --> 00:18:59,890 do. I think especially if I'm doing 299 00:18:59,890 --> 00:19:04,610 a new system project, I'll use all these techniques in one way 300 00:19:04,610 --> 00:19:07,530 or another. Maybe not to the nth degree, but 301 00:19:07,530 --> 00:19:09,290 definitely the the concepts behind it. 302 00:19:09,410 --> 00:19:12,730 So UML is a standard visual modeling language. 303 00:19:13,050 --> 00:19:17,370 OK, it is used in software engineering to design, visualize 304 00:19:17,370 --> 00:19:22,090 and document software systems. But there was science behind it, 305 00:19:22,090 --> 00:19:25,770 and the science can be used in your business analysis every 306 00:19:25,770 --> 00:19:27,870 day. OK, so when you heard the word 307 00:19:27,870 --> 00:19:31,550 systems analysis which was the precursor to business analysis, 308 00:19:32,430 --> 00:19:35,630 effectively UML was used to outline the requirements of the 309 00:19:35,630 --> 00:19:39,990 business. OK, so UML provided A graphical 310 00:19:39,990 --> 00:19:43,910 set of notations for representing aspects of systems 311 00:19:44,190 --> 00:19:47,190 or solutions effectively. OK, and you could use that for 312 00:19:47,190 --> 00:19:52,430 non IT systems. In some ways it talked about the 313 00:19:52,430 --> 00:19:55,900 structure, the behaviors and interactions of the systems and 314 00:19:55,900 --> 00:19:59,900 Bas use UML or you know, those who are moving into the BA space 315 00:19:59,900 --> 00:20:03,140 at this time for their requirements analysis to 316 00:20:03,180 --> 00:20:07,380 effectively communicate and document system requirements or 317 00:20:07,380 --> 00:20:10,140 solution requirement. And that's where the word 318 00:20:10,140 --> 00:20:11,540 solution requirements has come from. 319 00:20:11,820 --> 00:20:15,540 And I in my mind the IABA has evolved from the point to still 320 00:20:15,540 --> 00:20:17,900 talk about it. The solution requirements, as 321 00:20:17,900 --> 00:20:22,180 the IABA talks about this was a way of talking about it. 322 00:20:22,180 --> 00:20:26,670 And there are a couple of. Diagrams for getting there OK 323 00:20:26,670 --> 00:20:30,550 that are worth noting. I would say that number one is 324 00:20:30,550 --> 00:20:33,510 what I talked about for which is the use case. 325 00:20:33,830 --> 00:20:38,590 So the use case use the scenario use case Use Case Modeling is 326 00:20:38,590 --> 00:20:42,910 the diagram that we use. But there's also almost a 327 00:20:42,910 --> 00:20:46,630 reference sheet that goes along with this was use. 328 00:20:46,630 --> 00:20:48,550 I'll just talk about the model to keep it simple. 329 00:20:48,750 --> 00:20:52,630 Use case model I personally use. I still use them a lot, know a 330 00:20:52,630 --> 00:20:55,820 lot of BA's don't do. It's usually associated with 331 00:20:55,820 --> 00:20:59,180 waterfall or traditional requirements management, which 332 00:20:59,180 --> 00:21:01,700 is probably why it isn't used these days. 333 00:21:01,980 --> 00:21:03,620 But it's still a great technique. 334 00:21:03,900 --> 00:21:09,980 So use case diagram is simply a stick figure of a person. 335 00:21:10,780 --> 00:21:14,300 It has representations of a database or a system External 336 00:21:14,300 --> 00:21:20,020 systems with arrows like 20 arrows to these round ellipse 337 00:21:20,140 --> 00:21:24,300 circles, and in those circles are the function in which you 338 00:21:24,300 --> 00:21:27,540 want the user to perform with whatever it's connected to. 339 00:21:27,940 --> 00:21:31,460 And you can extend these use cases to talk about extensions 340 00:21:31,460 --> 00:21:37,380 that can happen. You can show child use cases at 341 00:21:37,380 --> 00:21:40,900 this point, and you can do and there's usually a little write 342 00:21:40,900 --> 00:21:43,620 up for each use case which talks about what has to be true 343 00:21:43,620 --> 00:21:47,220 beforehand, prerequisites and postrequisites of performing 344 00:21:47,220 --> 00:21:49,870 that function. And so you might have seen these 345 00:21:49,870 --> 00:21:53,110 diagrams before, they were not focused on sequence, so they 346 00:21:53,110 --> 00:21:58,310 were just a brainstorm of all the functions that the user very 347 00:21:58,310 --> 00:22:00,790 much called. The user back then wanted to 348 00:22:00,790 --> 00:22:03,470 perform with the system and what that system would then 349 00:22:03,510 --> 00:22:07,270 necessarily have to then communicate via just an arrow 350 00:22:07,710 --> 00:22:10,990 back to the user or their response to the function. 351 00:22:12,270 --> 00:22:15,390 So that was that's quite very useful for documenting the 352 00:22:15,390 --> 00:22:18,370 functional requirements of a solution. 353 00:22:18,370 --> 00:22:21,210 And because it was visual, you might start thinking Oh well, 354 00:22:21,210 --> 00:22:25,090 what needs to be true in terms of timing and and and in terms 355 00:22:25,090 --> 00:22:27,450 of security. And because it was visual, you 356 00:22:27,450 --> 00:22:30,010 could, you know some non functional requirements would 357 00:22:30,010 --> 00:22:33,250 drop out of that. So it was quite helpful in terms 358 00:22:33,250 --> 00:22:36,290 of capturing the system's intended behavior. 359 00:22:38,010 --> 00:22:42,170 And you know it was I guess useful in a very very simple way 360 00:22:42,170 --> 00:22:45,170 of doing that. So you can still still use that 361 00:22:45,450 --> 00:22:52,210 process and the next, I guess important function of your Now 362 00:22:52,210 --> 00:22:55,770 one of the diagrams there is called the activity diagram and 363 00:22:55,770 --> 00:22:58,530 so this was the flow of activities that the system 364 00:22:59,050 --> 00:23:02,090 needed to perform, if you like, the processes within the system, 365 00:23:02,370 --> 00:23:05,090 So what processes did the system need to do? 366 00:23:06,730 --> 00:23:09,570 These diagrams helped in the understanding of the sequence of 367 00:23:09,570 --> 00:23:12,730 actions and decisions and parallel activity. 368 00:23:13,620 --> 00:23:15,700 So again, talk about those stencils. 369 00:23:15,860 --> 00:23:20,980 Sometimes when you go to draw a flow diagram or a BPMM process 370 00:23:20,980 --> 00:23:23,820 model, you may see an activity diagram as the name of the 371 00:23:23,820 --> 00:23:27,100 stencil and so there are some you know, there were techniques 372 00:23:27,100 --> 00:23:31,380 and notations and special, you know, depictions that you needed 373 00:23:31,380 --> 00:23:33,540 to use. But effectively, if you can 374 00:23:33,540 --> 00:23:36,740 think of an activity diagram, think of it just like a system 375 00:23:36,740 --> 00:23:39,620 diagram. Sorry, process diagram, but very 376 00:23:39,620 --> 00:23:43,870 much down at the system level. OK. 377 00:23:43,870 --> 00:23:45,790 So that's kind of an activity diagram. 378 00:23:46,190 --> 00:23:49,710 And then we had class diagrams and class diagrams were what I 379 00:23:49,710 --> 00:23:51,550 talked about in terms of business entities. 380 00:23:51,910 --> 00:23:56,910 So if you were doing creating a system for a mechanic, a class 381 00:23:56,910 --> 00:24:01,670 diagram may be Car and Customer might be your two classes and 382 00:24:01,670 --> 00:24:05,990 Cars might be associated with Wheels, which is another class 383 00:24:06,310 --> 00:24:10,430 and class. Each class has attribute. 384 00:24:10,990 --> 00:24:15,830 So for example a car could have an attribute like I said wheels 385 00:24:15,830 --> 00:24:20,150 or color or make. And then each class has 386 00:24:20,350 --> 00:24:23,670 functions and like actual system functions they need to perform 387 00:24:23,830 --> 00:24:28,270 which might be create new car, update car details. 388 00:24:28,550 --> 00:24:31,310 And that's how you started to get the system functions that 389 00:24:31,310 --> 00:24:34,710 needed to exist. And so this was logically what 390 00:24:34,750 --> 00:24:37,830 needed to actually happen. And so this logical diagram or 391 00:24:37,830 --> 00:24:41,880 conceptual entity diagram, class diagram is where you differ with 392 00:24:41,880 --> 00:24:44,600 programming and programmers could then take that and then 393 00:24:44,600 --> 00:24:48,320 they could actually write classes with with you know in 394 00:24:48,320 --> 00:24:52,840 code if you like. And then they also allowed you 395 00:24:52,840 --> 00:24:55,960 to associate entities. So you knew you had to have a 396 00:24:55,960 --> 00:24:59,880 car, there might be one car and a car has multiple wheels. 397 00:24:59,880 --> 00:25:03,280 So we we have something called A1 to many relationship there. 398 00:25:03,280 --> 00:25:07,000 And so it helped with database structures is well in the data 399 00:25:07,000 --> 00:25:10,220 model. Next we had the sequence 400 00:25:10,220 --> 00:25:12,220 diagram. So the sequence diagram was a 401 00:25:12,220 --> 00:25:15,900 drawing of our of our people where little stick diagrams but 402 00:25:15,900 --> 00:25:19,460 it was showing the sequence in which a transaction would take 403 00:25:19,460 --> 00:25:21,940 place. So when I say transaction I mean 404 00:25:21,940 --> 00:25:25,460 that broadly an interaction. So it would say for example, you 405 00:25:25,460 --> 00:25:31,580 drop your car at the mechanic, the mechanic adds car to system 406 00:25:32,740 --> 00:25:38,140 and it would have a little arrow showing sending the car name if 407 00:25:38,140 --> 00:25:41,500 you like or the car details for the system and it might return a 408 00:25:41,500 --> 00:25:45,100 message saying car added or then you're prompting you for the 409 00:25:45,100 --> 00:25:47,620 next step. So it was a visual depiction of 410 00:25:47,620 --> 00:25:51,460 the logic that needed to happen was system interactions down at 411 00:25:51,460 --> 00:25:53,660 the, you know at an interaction system level. 412 00:25:54,020 --> 00:25:57,220 And that was effectively showing when functions would be called 413 00:25:57,220 --> 00:26:02,140 in what sequence again helping when you programmed and actually 414 00:26:02,140 --> 00:26:05,960 in terms of seeing how a system would actually work and you 415 00:26:05,960 --> 00:26:09,520 would and there were there are actually other diagrams that 416 00:26:09,520 --> 00:26:13,240 there's some main ones there there there are others But the 417 00:26:13,240 --> 00:26:16,360 idea was you were trying to effectively communicate system 418 00:26:16,360 --> 00:26:21,080 requirements and show that used to actually show that to users 419 00:26:21,280 --> 00:26:22,920 and show this is how it's going to work. 420 00:26:23,120 --> 00:26:25,280 So they kind of had to understand your amount to a 421 00:26:25,280 --> 00:26:27,280 certain degree. It was quite simple to 422 00:26:27,280 --> 00:26:31,360 understand and and some some cases you know this would help 423 00:26:31,360 --> 00:26:33,620 you write code. But equally then you could 424 00:26:33,740 --> 00:26:37,060 visually show how the system was working and where you had 425 00:26:37,060 --> 00:26:39,820 questions. So you were using that and so 426 00:26:39,820 --> 00:26:43,620 customers were kind of having to interact at that level okay. 427 00:26:43,820 --> 00:26:45,940 So that was that worked very well. 428 00:26:45,940 --> 00:26:50,180 But it was very scientific and very close to the outcome in 429 00:26:50,180 --> 00:26:56,220 terms of the solution outcome, but you could say it was in the 430 00:26:56,220 --> 00:27:00,280 lens of the system, OK. And so and and so it allowed you 431 00:27:00,280 --> 00:27:02,760 to not miss anything when programming. 432 00:27:02,760 --> 00:27:05,720 So you knew that all these things, you knew exactly what 433 00:27:05,720 --> 00:27:08,680 the critical items were. So back in that kind of 434 00:27:08,680 --> 00:27:11,080 traditional way and I'm not saying that it's necessary. 435 00:27:11,080 --> 00:27:14,040 We're throwing that out. That would allow you to make 436 00:27:14,040 --> 00:27:16,920 sure that whatever you delivered, you got your customer 437 00:27:16,920 --> 00:27:19,200 from A to B quite easily. OK. 438 00:27:19,840 --> 00:27:23,480 But we've moved away from that a little bit and what we've done 439 00:27:23,600 --> 00:27:27,850 and with the evolution of design thinking, I'm not even talking 440 00:27:27,850 --> 00:27:31,130 about Agile, which is a little bit lower down. 441 00:27:31,650 --> 00:27:34,010 We've started to think about the customer, right. 442 00:27:34,010 --> 00:27:36,810 And we want to capture our clients at a customer level. 443 00:27:36,810 --> 00:27:44,330 So we use things like now I guess 20-30 years later, we talk 444 00:27:44,330 --> 00:27:46,850 to our customers in their language and the language they 445 00:27:46,850 --> 00:27:49,330 understand and we use other techniques for doing that. 446 00:27:49,930 --> 00:27:54,650 So we use what I would say is a top down technique and so first 447 00:27:54,690 --> 00:28:00,330 we find out what they want to do and then we outline that in a 448 00:28:00,330 --> 00:28:03,130 customer journey map which is which is a process diagram at 449 00:28:03,130 --> 00:28:05,930 the highest, highest level. Service design if you like 450 00:28:05,930 --> 00:28:09,010 what's even pre service design. So you're you're working out 451 00:28:09,010 --> 00:28:11,890 what they need, what they need to perform and where their pain 452 00:28:11,890 --> 00:28:15,130 points are at the highest level and that's what we use you know 453 00:28:15,130 --> 00:28:17,970 design thinking to elicit what they're trying to achieve. 454 00:28:19,130 --> 00:28:20,850 And so we're using their language. 455 00:28:21,330 --> 00:28:27,120 OK, now that's great. But then we then get into, as 456 00:28:27,120 --> 00:28:31,200 most teams are working in these days, some kind of agile 457 00:28:31,200 --> 00:28:33,880 development method. So how do we then get down to 458 00:28:33,880 --> 00:28:36,080 the next level if we're not using UML? 459 00:28:36,680 --> 00:28:40,600 How do we make sure that the agile development team is 460 00:28:40,600 --> 00:28:44,760 delivering the logic and making sure that whatever we deliver 461 00:28:44,920 --> 00:28:48,260 actually gets us from A to B? Because what I would argue is 462 00:28:48,260 --> 00:28:51,340 that in a backlog management these days, you have a whole 463 00:28:51,340 --> 00:28:54,460 collection of things you could do which isn't necessary, the 464 00:28:54,460 --> 00:28:57,580 linear path from A to B, the most efficient path. 465 00:28:58,180 --> 00:29:01,820 And so therefore, and I'm not necessary to about the most 466 00:29:01,820 --> 00:29:04,700 efficient, but literally the fact that the person wants to 467 00:29:04,700 --> 00:29:08,500 achieve that that goal from getting from A to B in a pretty 468 00:29:08,580 --> 00:29:11,620 damn good time. If you actually track the 469 00:29:11,620 --> 00:29:16,380 success of the process they're trying to achieve and how how 470 00:29:16,380 --> 00:29:20,380 that relates to your delivery or how that relates to the delivery 471 00:29:20,380 --> 00:29:24,180 of most agile delivery teams, you would see that they are not 472 00:29:24,180 --> 00:29:27,140 necessarily aligned. And that's because 473 00:29:27,500 --> 00:29:30,300 prioritization of the backlog and what goes into the Sprint 474 00:29:30,660 --> 00:29:33,340 can be relooked at every time you finish the Sprint and do 475 00:29:33,340 --> 00:29:36,140 Sprint planning. So that doesn't naturally take 476 00:29:36,140 --> 00:29:40,300 you necessarily back to the prioritization of what of the 477 00:29:40,300 --> 00:29:43,100 job to be done. It prioritizes in terms of the 478 00:29:43,100 --> 00:29:45,260 features and what you're focusing on now. 479 00:29:45,580 --> 00:29:48,740 And that isn't there isn't anything within Scrum planning 480 00:29:48,740 --> 00:29:53,060 for example, that says anywhere there that goes, OK, well are we 481 00:29:53,060 --> 00:29:57,100 doing the most logical sequence, are we following the the most 482 00:29:57,420 --> 00:30:00,820 logical sequence And are we filling all gaps in the customer 483 00:30:00,820 --> 00:30:04,180 journey here? Are we actually, you know if we 484 00:30:04,180 --> 00:30:07,180 released another way of saying that is if we released our 485 00:30:07,180 --> 00:30:10,460 product tomorrow, would a user be able to achieve their goal 486 00:30:10,460 --> 00:30:14,220 from getting A to B? There is no challenge or 487 00:30:14,500 --> 00:30:18,740 particular I guess ceremony that asked that question. 488 00:30:19,700 --> 00:30:23,820 What it says is that have you and there's a couple of 1 liners 489 00:30:23,820 --> 00:30:28,180 about saying that when you do release the the the idea is that 490 00:30:28,180 --> 00:30:31,700 it that it's at an MVP stage at each time it's a slice of the 491 00:30:31,700 --> 00:30:34,180 solution and you can get from A to B right? 492 00:30:34,500 --> 00:30:39,840 But there isn't necessarily a bite in method for allowing us 493 00:30:39,840 --> 00:30:44,320 to do that. However, quite a few years back 494 00:30:44,320 --> 00:30:46,920 there was something that was introduced in the Agile world 495 00:30:46,920 --> 00:30:50,000 called User Story Mapping and this is fantastic. 496 00:30:50,760 --> 00:30:56,640 User Story mapping is a visual tool primarily that came from I 497 00:30:56,640 --> 00:31:00,200 guess from agile thinking. It's around making sure that 498 00:31:00,240 --> 00:31:04,040 even though you should, you know, focus on what matters for 499 00:31:04,040 --> 00:31:08,550 that Sprint and you know, don't just take things off the backlog 500 00:31:08,550 --> 00:31:12,910 and work in a waterfall manner. It allows us to take something 501 00:31:12,950 --> 00:31:17,910 from, I guess the same reason why UML exists and the same 502 00:31:17,910 --> 00:31:20,430 reason why traditional requirements were done in the 503 00:31:20,430 --> 00:31:24,310 way they were doing by making sure that there is a backbone. 504 00:31:24,310 --> 00:31:27,350 It's literally called a backbone that the backbone requirements, 505 00:31:27,350 --> 00:31:30,260 the must have requirements are done. 506 00:31:30,340 --> 00:31:33,700 So regardless of where we then spend our attention or where we 507 00:31:33,700 --> 00:31:36,900 decide to refine our requirements, we've still got a 508 00:31:36,900 --> 00:31:40,100 backbone the user can get from A to B Okay. 509 00:31:40,380 --> 00:31:43,140 Doesn't have to be the most prettiest way, but they can 510 00:31:43,140 --> 00:31:47,060 achieve their job to be done. So if you if you don't know 511 00:31:47,060 --> 00:31:51,460 about story user story mapping or story mapping for short, it's 512 00:31:51,460 --> 00:31:53,140 fantastic. Okay, it's not. 513 00:31:53,380 --> 00:31:56,980 User story mapping isn't about just throwing all the user story 514 00:31:56,980 --> 00:32:00,920 map visually up on to a board. The purpose, the underlying 515 00:32:00,920 --> 00:32:05,480 purpose is trying to show along the top. 516 00:32:05,480 --> 00:32:10,360 So along horizontally along the top of this visual board you 517 00:32:10,360 --> 00:32:13,880 show the customer journey. And the customer journey or user 518 00:32:13,880 --> 00:32:16,880 journey is what we talked about in terms of job to be done. 519 00:32:17,080 --> 00:32:21,000 They are the steps, the sequence of steps in a specific order 520 00:32:21,200 --> 00:32:25,110 from getting from A to B. OK, so it's defined by, you 521 00:32:25,110 --> 00:32:29,070 know, ideally it's been done by your human center design team or 522 00:32:29,070 --> 00:32:33,670 just the logical steps that have to happen to move from A to B to 523 00:32:33,670 --> 00:32:36,470 a point that if you don't know what those are, maybe you know, 524 00:32:36,470 --> 00:32:39,590 applying a bit of UML, looking at a sequence diagram will soon 525 00:32:39,590 --> 00:32:42,990 tell you what has to happen in order to send information back 526 00:32:42,990 --> 00:32:46,310 and forth or interactions back and forth from, you know, the 527 00:32:46,310 --> 00:32:50,680 various actors in the system. Okay. 528 00:32:50,800 --> 00:32:53,200 So. So that's really important and 529 00:32:53,200 --> 00:32:57,600 that this is where I think a replacement for the idea of 530 00:32:57,600 --> 00:33:03,520 looking at stakeholder and solution requirements starts to 531 00:33:03,760 --> 00:33:06,000 show itself. And I'll come back to the fact 532 00:33:06,000 --> 00:33:08,960 that I don't think that solution and stakeholder requirements 533 00:33:08,960 --> 00:33:12,040 should be different things. And I'll talk about how I think 534 00:33:12,680 --> 00:33:17,400 those could be helped using this technique called User Story 535 00:33:17,400 --> 00:33:22,630 Mapping. So a guy named Jeff Patton put 536 00:33:22,630 --> 00:33:25,750 together a book called User Story Mapping. 537 00:33:25,750 --> 00:33:28,310 I would suggest you check his book out. 538 00:33:28,710 --> 00:33:33,830 It's a as As he says User Story Mapping is a dead simple idea 539 00:33:34,390 --> 00:33:41,190 and it's the reason this is what User Story mapping can can 540 00:33:41,190 --> 00:33:43,710 confuse some Vas or those in the agile spaces. 541 00:33:44,110 --> 00:33:49,110 Along the top of your user story map you should have the high 542 00:33:49,110 --> 00:33:52,110 level activities a user needs to achieve. 543 00:33:52,110 --> 00:33:56,710 A customer needs to achieve to to get their job to be done Okay 544 00:33:56,710 --> 00:34:00,310 or use the product or or or interact with the system. 545 00:34:00,790 --> 00:34:04,910 Now they are epics. I'm going to say that again. 546 00:34:05,510 --> 00:34:10,030 The top level of your user story map should be your epics. 547 00:34:11,590 --> 00:34:13,949 Okay that's what User Story mapping talks about. 548 00:34:14,469 --> 00:34:19,130 And below that you have story, okay, you have stories, user 549 00:34:19,130 --> 00:34:22,610 stories that that fall under those categories. 550 00:34:22,610 --> 00:34:26,730 So user story mapping allows us to categorize our user stories 551 00:34:26,929 --> 00:34:32,530 into these very various horizontal categories, just 552 00:34:32,690 --> 00:34:35,690 analyst. And then as you talk about what 553 00:34:35,690 --> 00:34:39,210 you're going to release in terms of that Sprint, you would then I 554 00:34:39,210 --> 00:34:43,570 guess circle which of those user stories horizontally in the user 555 00:34:43,570 --> 00:34:46,130 story you're going to deliver on that Sprint. 556 00:34:46,810 --> 00:34:53,929 So it dictate that that Sprint I call that iteration needs to 557 00:34:53,929 --> 00:34:59,330 include our story or at least needs to needs to in the first 558 00:34:59,330 --> 00:35:04,530 Sprint include our story from each part of that user journey. 559 00:35:04,890 --> 00:35:08,730 So, so you know that at least something's been done in each 560 00:35:08,930 --> 00:35:13,570 area of that each of those effects have been met. 561 00:35:14,090 --> 00:35:16,810 So if the epics are being met, as we've just said, the job can 562 00:35:16,810 --> 00:35:19,890 be done. So therefore if your spring 563 00:35:20,610 --> 00:35:25,170 incorporates one, at least one user story from each of those 564 00:35:26,130 --> 00:35:31,410 parent epics, then you can be sure that the end of your Sprint 565 00:35:31,410 --> 00:35:36,130 or your integration will deliver the job to be done in some form. 566 00:35:36,410 --> 00:35:37,610 It's not saying it's the best way. 567 00:35:37,610 --> 00:35:40,970 It's saying that you know effectively you've done a slice 568 00:35:41,370 --> 00:35:43,970 of the solution that will be the final solution. 569 00:35:44,370 --> 00:35:47,570 And so it's a really good way of making sure that visually and 570 00:35:47,570 --> 00:35:50,250 the team knows that they're delivering, that whatever 571 00:35:50,250 --> 00:35:53,530 they're delivering is valuable straight away at the end of an 572 00:35:53,530 --> 00:35:55,930 iteration. And reality that isn't, you 573 00:35:55,930 --> 00:35:59,050 know, there are all sorts of different kind of sprints in 574 00:35:59,050 --> 00:36:02,130 terms of we know we want to work on this one area, but to start 575 00:36:02,130 --> 00:36:04,530 off with and to be true to Agile, that's exactly what it's 576 00:36:04,530 --> 00:36:07,650 all about. But, so user story mapping, 577 00:36:07,770 --> 00:36:09,450 please. Sorry, I'm going to say user 578 00:36:09,450 --> 00:36:11,600 story mapping. Learn about it. 579 00:36:11,600 --> 00:36:14,360 It's a fantastic technique if you're an agileist, if you're 580 00:36:14,360 --> 00:36:18,080 working as a BA and an Agile team, If you actually care about 581 00:36:18,240 --> 00:36:21,840 how traditional requirements map down to user stories, user story 582 00:36:21,840 --> 00:36:25,160 mapping is the missing element in your life. 583 00:36:25,720 --> 00:36:29,800 But I'm now going to talk to you about how if you incorporate 584 00:36:30,000 --> 00:36:34,200 user story mapping, design thinking and what I talked about 585 00:36:34,200 --> 00:36:37,990 earlier in terms of UML and going all the way up to our 586 00:36:37,990 --> 00:36:41,230 requirements classifications, why it's important for us to 587 00:36:41,230 --> 00:36:44,870 take that further if you're in the kind of intermediate senior 588 00:36:44,870 --> 00:36:47,830 space. And this is where we we fall 589 00:36:47,830 --> 00:36:52,670 into what the podcast is all about, which is processed to 590 00:36:52,670 --> 00:36:56,510 requirements thinking. So what do we know before we get 591 00:36:56,510 --> 00:37:00,470 into a bit of what do we know before we get into a conclusion 592 00:37:00,470 --> 00:37:03,790 here? We know that a user story 593 00:37:03,790 --> 00:37:06,910 mapping is a great technique and it solves many problems with the 594 00:37:06,910 --> 00:37:10,990 agile teams delivering part of a solution and not an intense 595 00:37:10,990 --> 00:37:15,310 solution. So it puts focus on the delivery 596 00:37:15,310 --> 00:37:18,790 to make it logical. And it does that by introducing 597 00:37:18,830 --> 00:37:23,150 epics along the top of the user story map, which is suggestive. 598 00:37:24,310 --> 00:37:27,870 It's suggestive because it's suggesting as we've said earlier 599 00:37:28,490 --> 00:37:32,090 that business requirements which I'm saying are what needs to be 600 00:37:32,090 --> 00:37:35,370 done to reach our strategic objectives or the job to be done 601 00:37:35,970 --> 00:37:40,530 is 1 and the same as our epics. So if all our epics are done, 602 00:37:40,530 --> 00:37:42,610 then in theory our objectives are met. 603 00:37:43,330 --> 00:37:46,770 So our business requirements are mapped are one the same as the 604 00:37:46,770 --> 00:37:48,330 epics. And you might say that's not 605 00:37:48,330 --> 00:37:49,730 new. We've talked about that before. 606 00:37:49,730 --> 00:37:52,890 That's not a problem. But it also suggests that our 607 00:37:52,890 --> 00:37:58,440 epics are the highest level steps or process steps that a 608 00:37:58,440 --> 00:38:02,440 user needs to go through to complete the job to be done. 609 00:38:02,800 --> 00:38:06,920 And this is the hack. This is the trick that 610 00:38:06,920 --> 00:38:10,600 effectively meant that if we know the highest level steps 611 00:38:10,600 --> 00:38:14,920 that a user needs to go through, our epics are our process model. 612 00:38:14,920 --> 00:38:20,880 I'm going to say that again, our epics, our requirements are one 613 00:38:20,920 --> 00:38:25,160 and the same as our process model at the highest level, 614 00:38:26,150 --> 00:38:30,390 which means that our requirements can come directly 615 00:38:30,510 --> 00:38:35,910 from the process model. So what does that mean for the 616 00:38:35,910 --> 00:38:38,310 model when we talk about stakeholder and solution 617 00:38:38,310 --> 00:38:41,310 requirement? Well, here at the Better 618 00:38:41,310 --> 00:38:45,910 Business Analysis Institute, we write our process models such 619 00:38:45,910 --> 00:38:48,870 that we are talking about the user, we're saying what they 620 00:38:48,870 --> 00:38:51,030 want to achieve. We do that in a couple of way. 621 00:38:51,550 --> 00:38:55,050 One, when we process model, we always depict who is carrying 622 00:38:55,050 --> 00:38:57,130 out that activity. We have a little actually use 623 00:38:57,130 --> 00:39:01,210 shapes and now a template for who is the actor, Who is the 624 00:39:01,210 --> 00:39:02,970 person that needs to complete that step. 625 00:39:03,370 --> 00:39:08,250 It can be a human or it can be a system of some description or 626 00:39:08,250 --> 00:39:12,010 multiple humans. They're performing a process 627 00:39:12,010 --> 00:39:14,810 step, right? So they're doing something. 628 00:39:14,810 --> 00:39:17,450 So let's take our carton mechanic example. 629 00:39:17,690 --> 00:39:22,840 You could say that the customer, the new customer because they 630 00:39:22,840 --> 00:39:24,200 might not be an existing customer. 631 00:39:24,200 --> 00:39:28,920 So you get down to some level, the new customer is takes their 632 00:39:28,920 --> 00:39:34,960 car to the local mechanic and then I guess there's a note that 633 00:39:34,960 --> 00:39:36,840 they haven't visited that place before. 634 00:39:37,160 --> 00:39:42,080 So they can get their car serviced because it's due for 635 00:39:42,080 --> 00:39:44,360 its service check. That's the kind of you know the 636 00:39:44,360 --> 00:39:48,720 note behind the process step. Now that one step is could be 637 00:39:48,720 --> 00:39:53,260 the first step in a sequence of getting their car serviced at 638 00:39:53,260 --> 00:39:55,780 the mechanic, right? So you can you can imagine what 639 00:39:55,780 --> 00:39:57,700 those steps might be along the way. 640 00:39:57,700 --> 00:40:01,100 But let's say is our first step. You could argue there might be 641 00:40:01,100 --> 00:40:04,060 steps beforehand, which is another process you go into 642 00:40:04,060 --> 00:40:08,580 which is around finding out about this new place, knowing 643 00:40:08,580 --> 00:40:11,300 that your car needed a service and you've got to this point. 644 00:40:11,300 --> 00:40:14,300 So let's just say this this is our starting point. 645 00:40:14,300 --> 00:40:18,100 But we know that in in in theory there could be steps beforehand 646 00:40:18,700 --> 00:40:22,190 that process step. Can be one in the same as the 647 00:40:22,190 --> 00:40:27,230 Epic, which is to take your car to the mechanic. 648 00:40:27,550 --> 00:40:31,070 It doesn't relate to a system, but taking the car to the 649 00:40:31,070 --> 00:40:35,950 mechanic, the local mechanic is your highest level epic. 650 00:40:36,030 --> 00:40:38,590 You'd write that in a in a user story format of course. 651 00:40:39,070 --> 00:40:42,670 So as a new customer, I would like to take my car to the new 652 00:40:42,670 --> 00:40:49,190 mechanic so that I can get my car serviced and experience 653 00:40:50,290 --> 00:40:51,690 their service for the first time. 654 00:40:54,450 --> 00:40:57,050 Okay, there might be reasons around it that they got a deal. 655 00:40:57,490 --> 00:41:01,330 So the so that is the stakeholder driver or motivation 656 00:41:01,330 --> 00:41:04,130 for wanting the requirement. That's the prioritization. 657 00:41:04,330 --> 00:41:06,850 They're wanting to test the service or see if it's cheaper 658 00:41:06,850 --> 00:41:10,170 than the alternatives could be the so that and so that's really 659 00:41:10,170 --> 00:41:12,410 important. But you would notice, you may 660 00:41:12,410 --> 00:41:14,850 have noticed this. I did say it very quickly that 661 00:41:14,850 --> 00:41:17,650 there are a couple of things that I said in that epic that 662 00:41:17,650 --> 00:41:23,030 was very useful. One, I defined not as a user, I 663 00:41:23,030 --> 00:41:28,270 defined as a new customer. And so that linked to the desire 664 00:41:28,270 --> 00:41:31,630 of that stakeholder group, which is quite different from any 665 00:41:31,630 --> 00:41:34,430 other user, a new customer, someone who hasn't experienced 666 00:41:34,790 --> 00:41:39,600 this, this mechanics before. So if you're not lazy with your 667 00:41:39,600 --> 00:41:43,600 requirements modeling and your process steps, then you've 668 00:41:43,600 --> 00:41:46,840 actually defined those up and that's quite a specific use case 669 00:41:46,840 --> 00:41:47,960 there. And you've talked about your 670 00:41:47,960 --> 00:41:50,240 personas. So again you've incorporated the 671 00:41:50,240 --> 00:41:53,920 stakeholder in the process step that you are modeling. 672 00:41:54,640 --> 00:41:58,480 And secondly, I said at the local mechanics and I talked 673 00:41:58,480 --> 00:42:01,800 about or at the local new mechanic, I talked about in the 674 00:42:01,800 --> 00:42:08,100 user story or when you could say with the local mechanic I added 675 00:42:08,100 --> 00:42:10,820 that to the user story. I didn't say I wanted to get my 676 00:42:11,100 --> 00:42:13,460 car serviced so that my car could be serviced. 677 00:42:13,460 --> 00:42:16,700 I said whether or at this particular location. 678 00:42:16,980 --> 00:42:20,300 So by introducing the business entity or the thing in which I 679 00:42:20,300 --> 00:42:24,180 wanted to interact with enhance the process step and actually 680 00:42:24,180 --> 00:42:28,980 the requirement itself because we know if we look back at UML, 681 00:42:29,180 --> 00:42:30,820 there's a sequence of interactions. 682 00:42:30,820 --> 00:42:34,670 So being me taking my car to the local mechanic for the first 683 00:42:34,670 --> 00:42:38,670 time as a new customer means that there would be a function 684 00:42:38,670 --> 00:42:42,670 that needs to occur at the mechanics which is accepting me 685 00:42:42,670 --> 00:42:45,790 or adding me to their database or you know, there's a response 686 00:42:45,790 --> 00:42:47,670 to that. So in your our land you could 687 00:42:47,670 --> 00:42:52,430 model that through the use cases but and also in terms of the 688 00:42:52,430 --> 00:42:55,590 sequence. So that's quite interesting from 689 00:42:55,590 --> 00:42:58,910 that land. But what I'm suggesting equally 690 00:42:58,910 --> 00:43:03,150 is that that epoch, if you've would drop out of that process 691 00:43:03,150 --> 00:43:06,910 model, you have all the attributes of that epoch in that 692 00:43:06,910 --> 00:43:09,710 process step. So if you've done your process 693 00:43:09,710 --> 00:43:11,790 modeling at that level and you've talked about it from the 694 00:43:11,790 --> 00:43:16,750 customer journey that should fall, that should be your epoch. 695 00:43:18,750 --> 00:43:22,310 So your process step if like I said done correctly drops down 696 00:43:22,310 --> 00:43:26,080 to your requirement. Now we know that Epics get 697 00:43:26,080 --> 00:43:28,280 elaborate. We know that in order for an 698 00:43:28,280 --> 00:43:33,280 epic to be met, we talk about a mix between the what we want the 699 00:43:33,360 --> 00:43:37,720 customer to do and the how. So and that example of taking 700 00:43:37,720 --> 00:43:43,120 our car and maybe the new customer drives to the local 701 00:43:43,120 --> 00:43:47,480 mechanic and drops their car off so that it could be serviced at 702 00:43:47,480 --> 00:43:51,320 that on you know on that day for example that could be your user 703 00:43:51,320 --> 00:43:53,200 story. So driving the car to the 704 00:43:53,200 --> 00:43:56,610 mechanic now I'm I'm, I'm purposely keeping life from kind 705 00:43:56,610 --> 00:43:58,490 of system requirements. You can think about it in a 706 00:43:58,490 --> 00:44:02,370 process term, but that that could be our user story and will 707 00:44:02,370 --> 00:44:04,490 say drive could be our first release. 708 00:44:04,490 --> 00:44:06,690 We're just doing, we're just assuming Drive. 709 00:44:07,170 --> 00:44:09,370 But in the future you could say, well you know, there's of 710 00:44:09,370 --> 00:44:12,290 course, you know, you could take your car to the mechanic, but 711 00:44:12,290 --> 00:44:14,650 you could potentially say that this app, I haven't talked about 712 00:44:14,650 --> 00:44:17,110 what this app's about or this business, it could be about 713 00:44:17,110 --> 00:44:19,230 concierge, it could be about someone else coming to your 714 00:44:19,230 --> 00:44:22,910 house and taking your car to the mechanic. 715 00:44:22,910 --> 00:44:26,670 And that could be the first, you know, the first enhancement we 716 00:44:26,670 --> 00:44:31,150 start talking about if we've completed enter and customer 717 00:44:31,150 --> 00:44:35,390 journey map. So if you think about the 718 00:44:35,390 --> 00:44:40,190 requirement of driving, which is now a mix between driving, so 719 00:44:40,310 --> 00:44:44,430 getting the action behind the epic, if you like, one of the 720 00:44:44,510 --> 00:44:47,910 possible actions of achieving the Epic, that's how I use the 721 00:44:47,910 --> 00:44:50,550 story and we might elaborate on that in terms of how we do that. 722 00:44:51,990 --> 00:44:57,950 You could argue that that's a subset of a process step, right? 723 00:44:59,150 --> 00:45:04,550 Taking as a new customer, taking our car to the new mechanic. 724 00:45:04,910 --> 00:45:08,430 A process step is driving the car you know down the street to 725 00:45:08,430 --> 00:45:11,790 the mechanic is a is a what how requirement down at the user 726 00:45:11,790 --> 00:45:14,430 story level. You could argue that that is 727 00:45:14,430 --> 00:45:18,990 just a sub process step as one permutation of a process step at 728 00:45:18,990 --> 00:45:22,030 a lower level. So you could argue that there is 729 00:45:22,030 --> 00:45:24,750 a very, very close relationship and I would say an exact 730 00:45:24,750 --> 00:45:28,990 relationship between process modeling at a lower level and 731 00:45:28,990 --> 00:45:32,300 your user story. And the science behind that is 732 00:45:32,300 --> 00:45:35,940 that is exactly what you now was about when you broke down the 733 00:45:35,940 --> 00:45:40,380 various functions and the functions within a use case 734 00:45:40,380 --> 00:45:43,820 diagram and you started talking about steps within the use case 735 00:45:43,820 --> 00:45:45,380 diagram. And then you talked about the 736 00:45:45,380 --> 00:45:47,900 sequence in which it needed to happen and you talked about the 737 00:45:47,900 --> 00:45:52,060 activities and the states in which you know things needed to 738 00:45:53,300 --> 00:45:56,160 change into. And then of course, class 739 00:45:56,160 --> 00:45:59,320 diagrams is the information and the functions in which those 740 00:45:59,360 --> 00:46:02,440 entities needed to perform. If you think about that UML, 741 00:46:02,440 --> 00:46:06,040 which is that pact for how to create systems and you And 742 00:46:06,040 --> 00:46:07,800 there's the logic and science behind that. 743 00:46:08,320 --> 00:46:11,760 If we then apply the logic and science of process modeling down 744 00:46:11,760 --> 00:46:14,920 to requirements, let the requirements literally drop out 745 00:46:15,160 --> 00:46:17,920 of the process, as in there is a one to one relationship. 746 00:46:17,920 --> 00:46:20,680 If you know how to do that properly, then we start to have 747 00:46:20,680 --> 00:46:25,620 a very easy way of knowing where requirements come from and that 748 00:46:25,820 --> 00:46:30,140 that technique is process to requirements thinking. 749 00:46:33,820 --> 00:46:40,220 In summary, with the evolution of user story mapping, knowing 750 00:46:40,220 --> 00:46:43,940 that you know you don't just do random requirements in an agile 751 00:46:44,100 --> 00:46:48,780 environment, or the other extreme back in traditional land 752 00:46:48,780 --> 00:46:53,020 having solution and stakeholder requirements being separate, 753 00:46:53,020 --> 00:46:56,270 which also didn't work, there was something missing. 754 00:46:56,870 --> 00:47:00,430 If we think about modern requirements elicitation and 755 00:47:00,430 --> 00:47:04,350 management, we use user story mapping to make sure that the 756 00:47:04,350 --> 00:47:10,630 development team is delivering you know enough of the solution 757 00:47:10,790 --> 00:47:13,630 such that the job can be done. So they've at least got 1 user 758 00:47:13,630 --> 00:47:17,710 story and e.g. epic along their iteration. 759 00:47:19,190 --> 00:47:24,050 We also then take that further and say we can go back and 760 00:47:24,050 --> 00:47:27,010 instead of having a solution and stakeholder requirements, we can 761 00:47:27,010 --> 00:47:31,130 just have epic and user stories. As long as we have very. 762 00:47:31,650 --> 00:47:35,730 We use the process modeling technique to drop our 763 00:47:35,730 --> 00:47:39,570 requirements out and such that in the process we are talking 764 00:47:39,570 --> 00:47:42,370 about the user, we are talking about the personas, we are 765 00:47:42,370 --> 00:47:45,290 talking about the various personas, same as stakeholder 766 00:47:45,290 --> 00:47:47,690 groups. We are talking about why they 767 00:47:47,690 --> 00:47:50,850 want to achieve that step. In the process we we have now 768 00:47:51,010 --> 00:47:54,900 brought in their prioritization and we you know, as long as it's 769 00:47:55,300 --> 00:47:59,660 adding to the sequence then we know that the requirements which 770 00:47:59,660 --> 00:48:04,220 allow us to get from A to B in some form or at least logically 771 00:48:04,220 --> 00:48:08,220 from A to B in the most logical way will be the priority. 772 00:48:09,500 --> 00:48:12,820 Yes, of course that leaves you lots of freedom to prioritize 773 00:48:12,820 --> 00:48:15,100 requirements which aren't necessarily must have 774 00:48:15,100 --> 00:48:18,820 requirements and becomes should and could and using our Moscow 775 00:48:19,300 --> 00:48:24,300 rating or then those requirements then are can be 776 00:48:24,300 --> 00:48:27,550 prioritized and then falls on the product owner or the, you 777 00:48:27,550 --> 00:48:29,590 know, BA working on the team. If you're not using an Azure 778 00:48:29,590 --> 00:48:32,950 environment to prioritize what is next going to be the most 779 00:48:32,950 --> 00:48:36,270 valuable to the end customer and you know that when you release 780 00:48:36,270 --> 00:48:39,590 it and then you release your first iteration and then then 781 00:48:39,590 --> 00:48:43,390 let them to go, OK, Rob, what's important now, you can now do 782 00:48:43,390 --> 00:48:46,790 the job to be done. Which area now is the pain point 783 00:48:46,790 --> 00:48:48,750 for you, The most important area for you. 784 00:48:48,750 --> 00:48:51,310 So you use. So once you've got that you know 785 00:48:51,310 --> 00:48:55,560 first release if you like, you're now using pain points. 786 00:48:55,560 --> 00:48:59,640 From that point you're revising your pain points in the process 787 00:48:59,640 --> 00:49:01,640 steps. You look at the process step you 788 00:49:01,640 --> 00:49:04,560 had before, you're looking at the process step you're now 789 00:49:04,560 --> 00:49:08,920 doing now and you're now re examining what is now the pain 790 00:49:08,920 --> 00:49:12,120 point now that you have these new tools and techniques from 791 00:49:12,120 --> 00:49:14,400 get or a new solution if you like, from getting A to B. 792 00:49:14,560 --> 00:49:19,060 What is now the most pressing pain point And again that's done 793 00:49:19,060 --> 00:49:23,700 in process modeling and again that drives which user story in 794 00:49:23,700 --> 00:49:25,940 the backlog should be added to the next Sprint. 795 00:49:27,340 --> 00:49:30,100 And that my friends, is process to requirements. 796 00:49:30,100 --> 00:49:33,140 Thinking in a nutshell. If you enjoy that thought, if 797 00:49:33,140 --> 00:49:36,100 you want to challenge me on any of that then please do and I 798 00:49:36,100 --> 00:49:38,300 hope you enjoyed the podcast this week.