1 00:00:00,280 --> 00:00:04,360 The Better Business Analysis Institute presence, the Better 2 00:00:04,360 --> 00:00:07,720 Business Analysis podcast with Kingsman Walsh. 3 00:00:12,400 --> 00:00:15,200 Hi everybody, and welcome back to the Better Business Analysis 4 00:00:15,200 --> 00:00:19,040 podcast with Benjamin Walsh. And I apologize for my voice. 5 00:00:19,280 --> 00:00:22,960 I have been down with COVID for the last week, but we're going 6 00:00:22,960 --> 00:00:25,080 to continue on our BA Byte series. 7 00:00:25,320 --> 00:00:31,600 And today we are going to follow through 10 top tips for writing 8 00:00:31,600 --> 00:00:36,640 awesome user stories. So if you follow me on LinkedIn 9 00:00:36,640 --> 00:00:41,160 or you are, you know, one of my, I guess, friends on there, you 10 00:00:41,160 --> 00:00:44,000 will see that the Better Business Analysis Institute 11 00:00:44,000 --> 00:00:49,160 published a white paper called User Stories 2.0. 12 00:00:49,400 --> 00:00:53,280 And we're going to get to that in #10 but we're going to count 13 00:00:53,280 --> 00:00:57,360 down 10 top tips. These are really important. 14 00:00:57,360 --> 00:01:04,400 I dip into the subject a lot and I think any BA, doesn't matter 15 00:01:04,400 --> 00:01:08,480 if you're senior or junior or getting started, will get value 16 00:01:08,480 --> 00:01:13,920 from from today's session around writing effective user stories, 17 00:01:13,920 --> 00:01:17,880 which is critical. And you, it's critical because 18 00:01:18,120 --> 00:01:22,080 it ensures that the delivery team, the development team, are 19 00:01:22,080 --> 00:01:27,680 building staff, features, deliverables, approving 20 00:01:27,680 --> 00:01:31,880 processes that actually deliver real value. 21 00:01:33,160 --> 00:01:37,680 And real value is not just a buzzword, it actually means 22 00:01:37,680 --> 00:01:40,040 something the customer cares about. 23 00:01:41,080 --> 00:01:45,120 So we're going to walk through 10 top tips for writing awesome 24 00:01:45,120 --> 00:01:50,680 user stories with examples focusing on clarity, actionable 25 00:01:50,680 --> 00:01:55,000 details and connecting user stories to the broader business 26 00:01:55,000 --> 00:01:59,320 process. We'll also introduce the User 27 00:01:59,320 --> 00:02:04,200 Stories 2.0 concept which the Institute has published, and I'd 28 00:02:04,200 --> 00:02:05,680 love to get your feedback on that. 29 00:02:06,800 --> 00:02:08,600 So let's dive in with number one. 30 00:02:09,320 --> 00:02:14,840 Number one is keep the story focused on user value or 31 00:02:14,840 --> 00:02:19,160 customer value. Ensure that the story is centred 32 00:02:19,280 --> 00:02:23,800 on the user's needs and the value they will receive. 33 00:02:24,680 --> 00:02:29,800 They receive a value item. OK, User stories should not be 34 00:02:29,800 --> 00:02:33,880 about technical tasks. OK, there's a lot of people out 35 00:02:33,880 --> 00:02:36,840 there who write user stories to talk about what they're going to 36 00:02:36,840 --> 00:02:40,200 do. No, it's not about technical 37 00:02:40,200 --> 00:02:46,440 tasks, but about delivering things, features, if you like, 38 00:02:47,560 --> 00:02:51,040 that solve user problems or provide benefits. 39 00:02:51,720 --> 00:02:57,360 I'll give you an example. As a customer, I want to see 40 00:02:57,440 --> 00:03:03,200 recommended products based on my previous purchases so that I can 41 00:03:03,200 --> 00:03:07,360 quickly find items that match my preferences. 42 00:03:08,320 --> 00:03:13,880 A lot of ecommerce sites to this, OK. 43 00:03:13,880 --> 00:03:16,200 And of course, there's acceptance criteria under that 44 00:03:16,200 --> 00:03:19,640 you can put in the description or the acceptance criteria 45 00:03:19,640 --> 00:03:23,920 field, which will be recommendations should be 46 00:03:23,920 --> 00:03:26,600 personalized based on my previous purchases within the 47 00:03:26,600 --> 00:03:30,200 last six months to introducing a bit of a business rule. 48 00:03:30,200 --> 00:03:32,840 There some constraints around the user story. 49 00:03:33,880 --> 00:03:37,400 The recommended product should appear on the homepage when the 50 00:03:37,400 --> 00:03:40,280 user logs in. So this is description of the 51 00:03:40,280 --> 00:03:42,040 user story. This is the comic book. 52 00:03:42,440 --> 00:03:46,360 So when you write your user story, one of the best ways to 53 00:03:46,360 --> 00:03:49,040 make sure you've covered it off is draw a little comic book 54 00:03:49,040 --> 00:03:50,600 strip. OK, if you're from the world of 55 00:03:50,600 --> 00:03:53,880 user stories and not use cases and traditional business 56 00:03:53,880 --> 00:03:57,880 analysis, visualize how you think this will become true. 57 00:03:58,200 --> 00:04:01,040 And some of those additional points will become description 58 00:04:01,240 --> 00:04:03,840 acceptance criteria in your user story. 59 00:04:04,440 --> 00:04:11,240 It's #1 keep the story focused on user value #2 is be specific 60 00:04:11,280 --> 00:04:16,160 with the desired outcome. Clearly define the outcome or 61 00:04:16,160 --> 00:04:19,959 benefit the users should be experiencing. 62 00:04:20,360 --> 00:04:23,680 Vague goals lead to misunderstanding about what 63 00:04:23,680 --> 00:04:26,600 should be built. OK, and this really focuses on 64 00:04:26,600 --> 00:04:31,520 the so that I aspect of the user story. 65 00:04:31,520 --> 00:04:34,880 So here we go. As a project manager, I want to 66 00:04:34,880 --> 00:04:42,200 receive e-mail alerts when tasks are overdue so that I can follow 67 00:04:42,200 --> 00:04:45,600 up with team members to avoid project delays. 68 00:04:46,760 --> 00:04:50,120 Lots of people could have written so that I receive an 69 00:04:50,120 --> 00:04:55,400 alert or so I am notified. They just rewrite that I want to 70 00:04:55,800 --> 00:04:58,680 and the so that I This is an easy problem. 71 00:04:58,760 --> 00:05:03,120 Don't do it. It is my advice if you catch 72 00:05:03,120 --> 00:05:05,880 yourself doing it, and sometimes you do it because you're rapidly 73 00:05:05,880 --> 00:05:08,240 writing these things, go back and change them. 74 00:05:08,240 --> 00:05:11,280 OK, So you need to think about why. 75 00:05:11,800 --> 00:05:15,520 Why is that feature? Why is that function important 76 00:05:15,960 --> 00:05:18,720 to the person? And it's usually not a technical 77 00:05:18,720 --> 00:05:21,840 reason. And so in this case, it was 78 00:05:21,840 --> 00:05:25,120 actually so they could follow up because it's really important. 79 00:05:25,120 --> 00:05:28,440 At least there's so many other aspects of product management 80 00:05:28,440 --> 00:05:32,640 and why you create value and by the alternatives. 81 00:05:32,640 --> 00:05:37,840 And when things are tough and you need to prioritize, then the 82 00:05:37,840 --> 00:05:41,480 why is all that matters. OK. 83 00:05:41,480 --> 00:05:43,520 And so again, you can have acceptance criteria. 84 00:05:43,520 --> 00:05:47,040 Alerts must be sent when a task is more than 24 hours old. 85 00:05:47,920 --> 00:05:50,800 And the task alert should not include or should include, 86 00:05:50,800 --> 00:05:53,920 sorry, the task name, assignee, due date, and so forth. 87 00:05:53,920 --> 00:06:00,960 So that's really around #2 which is be specific with the desired 88 00:06:00,960 --> 00:06:06,840 outcome #3 is really important. And I'm going to talk about 89 00:06:06,840 --> 00:06:09,080 breaking down in more detail here. 90 00:06:09,480 --> 00:06:14,960 Breakdown user stories or stories, the general term, into 91 00:06:15,000 --> 00:06:19,000 small manageable chunks. That's the whole point of the 92 00:06:19,080 --> 00:06:23,400 agile cycle and sprints. So large stories, epics are hard 93 00:06:23,400 --> 00:06:26,720 to implement in a single Sprint. That's the purpose of breaking 94 00:06:26,720 --> 00:06:28,360 them down. So there's two reasons. 95 00:06:28,360 --> 00:06:33,000 One is the side from the delivery side that they're too 96 00:06:33,000 --> 00:06:37,320 big, but they're also a great start, as I said, to, to link to 97 00:06:37,880 --> 00:06:40,560 traditional business analysis and real business analysis, if 98 00:06:40,560 --> 00:06:43,680 you like, of capturing high level requirements first. 99 00:06:44,520 --> 00:06:47,560 But you do need to break them down into smaller, more 100 00:06:47,560 --> 00:06:51,160 manageable user stories that can be completed within a Sprint. 101 00:06:51,840 --> 00:06:55,000 And so you could break these down again into child user 102 00:06:55,000 --> 00:06:58,200 stories. So you might and and and a child 103 00:06:58,200 --> 00:07:01,680 user story might supersede the the previous user stories. 104 00:07:01,680 --> 00:07:05,560 So you can either have children or you can archive and just have 105 00:07:05,560 --> 00:07:08,360 smaller more user stories if you like. 106 00:07:09,800 --> 00:07:14,000 So I'll give you an example for a large area, like, I don't 107 00:07:14,000 --> 00:07:16,800 know, managing my orders, you could break that down into 108 00:07:17,760 --> 00:07:21,920 smaller stories. As a customer, I want to view my 109 00:07:21,920 --> 00:07:26,640 order history. So it's a it's a sub function of 110 00:07:27,120 --> 00:07:31,200 or managing my order. OK, so that I can track past 111 00:07:31,200 --> 00:07:36,280 purchases or you might have as a customer, I want to update my 112 00:07:36,280 --> 00:07:40,080 shipping address before order is shipped out. 113 00:07:40,360 --> 00:07:42,960 So these are all sub features. And again, you can visualize 114 00:07:42,960 --> 00:07:47,560 this if you draw up what you think is a conceptual version of 115 00:07:47,560 --> 00:07:49,400 an order strip screen, this really helps. 116 00:07:49,400 --> 00:07:51,440 This is not cheating. Some people think you're 117 00:07:51,440 --> 00:07:53,840 bringing up pen and paper. It's like, oh, you're starting 118 00:07:53,840 --> 00:07:57,240 to develop, you're starting to design well, you'll know you're 119 00:07:57,240 --> 00:07:58,680 just conceptually thinking about it. 120 00:07:58,680 --> 00:08:01,880 There's there's, you should be doing this as a VA draw a 121 00:08:01,880 --> 00:08:04,400 picture and go, oh, what's on an order screen or, or look at your 122 00:08:04,400 --> 00:08:06,120 order screen. So you're like, well, they want 123 00:08:06,120 --> 00:08:08,600 to be able to be able to view their order history, don't they? 124 00:08:08,600 --> 00:08:10,840 And update their shipping address. 125 00:08:11,600 --> 00:08:15,800 And so this is all part of it. This is all passive, the 126 00:08:15,800 --> 00:08:19,640 analysis and design in the sense of business analysis. 127 00:08:20,000 --> 00:08:22,640 So you do that and you go, OK, well, we've got this, this 128 00:08:22,640 --> 00:08:24,960 massive epic around managing my order. 129 00:08:24,960 --> 00:08:28,120 We're going to manage my order screen, but actually now we've 130 00:08:28,120 --> 00:08:30,640 got some sub components if you like. 131 00:08:30,640 --> 00:08:32,919 They will be components by the developer's side. 132 00:08:32,919 --> 00:08:35,039 And from your point of view, they're just, they're functions 133 00:08:35,039 --> 00:08:38,200 that need to be reformed. OK, the user stories and you can 134 00:08:38,200 --> 00:08:42,080 write them down even further. So for example, you've got to a 135 00:08:42,080 --> 00:08:44,960 point where you're like view my order history and the order 136 00:08:44,960 --> 00:08:48,560 history screen was massive. That's where you could say, 137 00:08:48,560 --> 00:08:52,520 look, I really want them to not just view the order history, I 138 00:08:52,520 --> 00:08:58,160 want them to be able to view specific details of their 139 00:08:58,160 --> 00:09:00,880 previous orders, right? So like go back in time, see 140 00:09:00,880 --> 00:09:03,760 what was delivered, when it was delivered and all the rest of 141 00:09:03,760 --> 00:09:05,560 it. So that could be another user 142 00:09:05,560 --> 00:09:09,000 story. So you, you get into the order 143 00:09:09,000 --> 00:09:12,560 history and the, it's come from the product owner. 144 00:09:12,560 --> 00:09:15,400 They've spoken to customers and they want to track past 145 00:09:15,400 --> 00:09:18,600 purchases and you find out it's a bit more than you thought it 146 00:09:18,600 --> 00:09:20,400 was going to be. It wasn't just the name of the 147 00:09:20,400 --> 00:09:22,680 order and the item. It was like when it was 148 00:09:22,680 --> 00:09:24,840 delivered and submitted data around the order. 149 00:09:25,240 --> 00:09:28,560 So that's a child user story of that particular user story. 150 00:09:28,560 --> 00:09:31,680 Or you could just create a new one, add this backlog and say, 151 00:09:31,680 --> 00:09:34,840 look, we're going to implement this version of it. 152 00:09:34,840 --> 00:09:39,160 My order history as this user story 1st and then it's going to 153 00:09:39,160 --> 00:09:45,040 be my order history details, view or advance details or track 154 00:09:45,040 --> 00:09:47,120 that on the backlog. And that's not going to be done 155 00:09:47,120 --> 00:09:49,360 this spring. That's what we mean by breaking 156 00:09:49,360 --> 00:09:53,080 this down. They all contribute to the epic 157 00:09:53,400 --> 00:09:56,640 which was managed my order. Does that make sense? 158 00:09:56,920 --> 00:10:00,000 But there's a relationship between view my order history 159 00:10:00,240 --> 00:10:04,520 and this new view my order history, you know, details and 160 00:10:04,520 --> 00:10:09,440 that there could be linked as a child user story or just Simply 161 00:10:10,160 --> 00:10:12,000 put on the backlog at the kind of same level. 162 00:10:12,080 --> 00:10:15,800 I like to use child user stories and that's why I would break it 163 00:10:15,800 --> 00:10:20,240 down, OK, But it wouldn't be implemented in that Sprint. 164 00:10:20,320 --> 00:10:22,040 It doesn't mean that the children are all done in the 165 00:10:22,040 --> 00:10:27,840 same Sprint. OK, let's move on to #4 add 166 00:10:27,840 --> 00:10:32,640 clear exceptions criteria. So just to be clear about 167 00:10:32,640 --> 00:10:36,840 acceptance criteria. Acceptance criteria define how 168 00:10:36,840 --> 00:10:39,320 the story will be validated. OK. 169 00:10:39,840 --> 00:10:42,880 And this helps the developers, the testers and stakeholders 170 00:10:42,880 --> 00:10:45,360 know when the user story is done. 171 00:10:45,360 --> 00:10:47,760 So they the the definition of done. 172 00:10:48,160 --> 00:10:50,920 How do they not? And how do they know it's 173 00:10:50,920 --> 00:10:56,000 working as expected? So the acceptance criteria is 174 00:10:56,000 --> 00:10:59,720 being is not a, well, by the way, defined area. 175 00:10:59,720 --> 00:11:02,320 And it's something that I'm quite interested in having 176 00:11:02,600 --> 00:11:08,240 wrapping some guidance around, but it's being increasingly used 177 00:11:08,280 --> 00:11:12,920 to fill the gap of, say, documents that have business 178 00:11:12,920 --> 00:11:16,520 rules in them. So I'll give you an example. 179 00:11:16,520 --> 00:11:20,400 So as a user, I want to reset my password via e-mail. 180 00:11:20,840 --> 00:11:22,760 OK, It's quite interesting. It's got via e-mail. 181 00:11:22,960 --> 00:11:27,320 She's now specifying with what channel, with what. 182 00:11:27,680 --> 00:11:31,520 OK, so we'll come back to that so that I can regain access to 183 00:11:31,520 --> 00:11:33,840 my account if I forget my password. 184 00:11:34,760 --> 00:11:38,280 Very standard user story. It's one of these user stories 185 00:11:38,280 --> 00:11:42,040 that you sometimes forget to Chuck into your app because you 186 00:11:42,040 --> 00:11:45,200 just assume the developer's gonna, like, do all this. 187 00:11:46,320 --> 00:11:49,760 And I've done that before. And the acceptance criteria 188 00:11:49,760 --> 00:11:53,720 under this user story is that the user story can request, 189 00:11:53,920 --> 00:11:58,440 sorry, the user can request a password reset by entering your 190 00:11:58,440 --> 00:12:02,280 e-mail. OK, that's different. 191 00:12:02,680 --> 00:12:05,400 It's more descriptive. It's saying that they have to 192 00:12:05,400 --> 00:12:10,640 enter the e-mail. So that that if you like, you 193 00:12:10,640 --> 00:12:14,800 could break this user story down into further user stories around 194 00:12:14,800 --> 00:12:20,880 having a field or an area where a user can type their e-mail 195 00:12:20,880 --> 00:12:24,640 address, a valid e-mail address. Can you see, can you, can you 196 00:12:24,640 --> 00:12:27,320 see how you could break this down into other user stories? 197 00:12:27,600 --> 00:12:31,400 But in this case, the acceptance criteria is enough for the 198 00:12:31,400 --> 00:12:35,760 developer to visualize what they are going to build and they've 199 00:12:35,760 --> 00:12:38,080 recognized as patterns. So you I would say there would 200 00:12:38,080 --> 00:12:41,640 be less value in writing another user story or child user stories 201 00:12:41,640 --> 00:12:43,520 here. But the first acceptance 202 00:12:43,520 --> 00:12:46,840 criteria is around by resetting by entering their e-mail. 203 00:12:46,920 --> 00:12:51,280 And the second one is a reset link is synced within 5 minutes 204 00:12:51,280 --> 00:12:55,080 of the request. OK, you set your e-mail address, 205 00:12:55,080 --> 00:13:00,920 you click reset password and then within 5 minutes the 206 00:13:00,920 --> 00:13:04,080 request should be sent back. And there's some importance 207 00:13:04,080 --> 00:13:05,720 about that. I mean, you could say instantly. 208 00:13:05,720 --> 00:13:08,440 And then that can involve huge amounts of tests. 209 00:13:09,120 --> 00:13:11,920 I happen to know because I've got a bit of a development 210 00:13:11,920 --> 00:13:14,960 background, that it will be queued this request. 211 00:13:14,960 --> 00:13:17,240 And it might not be possible if everyone's resetting their 212 00:13:17,240 --> 00:13:19,600 password. It's not really a priority job. 213 00:13:19,960 --> 00:13:23,760 So 5 minutes is pretty standard, or I don't actually say a couple 214 00:13:23,760 --> 00:13:26,680 of minutes these days. People would expect an e-mail 215 00:13:26,680 --> 00:13:28,800 reset or they'll go back and reset it again. 216 00:13:29,520 --> 00:13:33,040 And then the last acceptance criteria #3 is the reset link 217 00:13:33,040 --> 00:13:36,520 will expire after 24 hours. So it's around security and 218 00:13:36,520 --> 00:13:40,600 making sure that it's not forever or hackers can't gain 219 00:13:40,600 --> 00:13:43,840 access to it. So that all what I'd call 220 00:13:43,840 --> 00:13:47,440 business rules that you're applying in the acceptance 221 00:13:47,440 --> 00:13:48,920 criteria and that all have to be true. 222 00:13:49,440 --> 00:13:53,520 So that allows the user story. Ultimately the resetting happens 223 00:13:55,040 --> 00:14:01,840 and you've specified some rules around how it has to happen. 95 224 00:14:02,400 --> 00:14:04,920 is so important. User stories. 225 00:14:04,920 --> 00:14:08,120 You get so wrapped up in your epochs, user stories, product 226 00:14:08,120 --> 00:14:12,840 features, all the rest of it. Don't forget about non 227 00:14:12,840 --> 00:14:19,600 functional requirements. Most projects that encounter big 228 00:14:19,600 --> 00:14:25,360 disasters when they go live is because the BA and the team and 229 00:14:25,360 --> 00:14:27,800 the architect haven't thought about non functional 230 00:14:27,800 --> 00:14:29,480 requirements or done a good enough job. 231 00:14:30,400 --> 00:14:32,480 They are overlooked. They are critical. 232 00:14:33,120 --> 00:14:36,840 They are critical not just for your reputation, but for user 233 00:14:36,840 --> 00:14:39,840 satisfaction. So we just talked about before 234 00:14:39,840 --> 00:14:44,200 around there was this resetting option, What would happen if we 235 00:14:44,200 --> 00:14:50,040 hadn't specified a time or worried about performance of 236 00:14:50,040 --> 00:14:55,200 this particular resetting of password or even security? 237 00:14:55,520 --> 00:15:00,720 OK, so we for example, when we reset the password, we sent the 238 00:15:00,720 --> 00:15:06,880 old password in the URL. That would be a security 239 00:15:06,880 --> 00:15:08,640 problem, a non functional requirement. 240 00:15:08,640 --> 00:15:11,440 We should have to to make sure that doesn't happen. 241 00:15:11,960 --> 00:15:16,040 And that would cause a security risk. 242 00:15:16,320 --> 00:15:19,400 And actually people would be able to just instead of 243 00:15:19,400 --> 00:15:23,360 resetting the like they can just take the old password, enter and 244 00:15:23,360 --> 00:15:26,440 get into your account. So you need to think about 245 00:15:26,440 --> 00:15:29,520 things from a non functional site and there's usually 246 00:15:29,520 --> 00:15:32,280 templates. I've got lots of good content 247 00:15:32,280 --> 00:15:35,360 about non functional so I'm not going to go on about the point, 248 00:15:35,360 --> 00:15:36,600 but I'll give you an example here. 249 00:15:37,000 --> 00:15:40,680 As a user, I want the system to respond quickly when searching 250 00:15:40,680 --> 00:15:47,360 for products so that I can find items without delays and this 251 00:15:47,360 --> 00:15:49,680 will stop me from going to other websites. 252 00:15:50,360 --> 00:15:53,880 And so the exceptions criteria could be search results must 253 00:15:53,880 --> 00:15:58,720 repeat appear within 2 seconds of 90% of queries. 254 00:15:59,000 --> 00:16:02,480 The system should handle up to 10,000 concurrent search 255 00:16:02,480 --> 00:16:04,800 requests. So these are all non functionals 256 00:16:04,800 --> 00:16:12,720 around the interaction with the system in order for the features 257 00:16:12,720 --> 00:16:16,760 functions to operate correctly, securely, you know, performance, 258 00:16:16,760 --> 00:16:20,600 a scalable, a usable and and this includes things like 259 00:16:20,600 --> 00:16:23,240 content and web standards as well. 260 00:16:23,240 --> 00:16:25,480 So they're all come under non functional requirements. 261 00:16:25,800 --> 00:16:28,440 So do not forget about non functional requirements. 262 00:16:29,360 --> 00:16:33,840 Number six is and I actually had this conversation with someone a 263 00:16:33,840 --> 00:16:38,360 couple of weeks ago. Focus on one persona per story. 264 00:16:39,400 --> 00:16:42,640 Don't have a group of personas. Think about the individual 265 00:16:42,640 --> 00:16:45,760 persona, individual user that you're focusing on. 266 00:16:45,760 --> 00:16:48,480 User story should cater to a specific type of user or 267 00:16:48,480 --> 00:16:51,240 persona. Trying to address multiple 268 00:16:51,240 --> 00:16:56,200 personas and a story creates confusion and so that I it's 269 00:16:56,200 --> 00:16:58,840 really talking about the individual persona. 270 00:16:59,640 --> 00:17:03,640 So as a System Administrator, I want to manage commissions and 271 00:17:03,640 --> 00:17:06,800 the control panel so that I can control access to different 272 00:17:06,800 --> 00:17:10,240 parts of the system. And then an, except described 273 00:17:10,240 --> 00:17:12,800 here, you might say something around admins can view a list of 274 00:17:12,800 --> 00:17:16,880 items, they can grant or revoke access to specific modules. 275 00:17:17,599 --> 00:17:20,119 Now that's around the system user System Administrator. 276 00:17:20,119 --> 00:17:22,160 And that's a good example because it's around the people 277 00:17:22,160 --> 00:17:24,560 that you sometimes forget about, especially when you're building 278 00:17:24,560 --> 00:17:27,240 a system that you think, oh, we haven't built an area where the 279 00:17:27,240 --> 00:17:29,720 System Administrator can actually control permissions. 280 00:17:30,000 --> 00:17:33,840 We've just got a user who has a credential, OK, and just gets 281 00:17:33,840 --> 00:17:36,200 allocated or wrong, but someone has to manage that. 282 00:17:36,280 --> 00:17:39,960 So that's thinking about the individuals in the life cycle, 283 00:17:40,040 --> 00:17:43,160 your stakeholders that are managing the system as well as 284 00:17:43,160 --> 00:17:44,520 interacting with it. OK. 285 00:17:44,600 --> 00:17:49,960 They all are important and we need to think about them as 286 00:17:49,960 --> 00:17:54,400 individual personas. So yes, and as, as a it should 287 00:17:54,400 --> 00:17:59,200 be, it should be unique there. And sometimes just as a top tip, 288 00:18:00,280 --> 00:18:01,960 sometimes that can be a bit of a reply. 289 00:18:01,960 --> 00:18:07,600 So early day business analysis and system design, you would do 290 00:18:07,600 --> 00:18:11,760 like a sequence diagram, for example, sometimes or you would 291 00:18:11,920 --> 00:18:15,640 do a use case diagram. And so think about a baton 292 00:18:15,640 --> 00:18:17,280 approach. And what I mean by that is, 293 00:18:17,640 --> 00:18:22,320 look, as a user, I want to be able to view a list of products 294 00:18:22,320 --> 00:18:25,520 on the site so I can browse and decide which product I want to 295 00:18:25,520 --> 00:18:29,560 purchase. And then so I've I'm doing that 296 00:18:30,080 --> 00:18:32,640 now, what is the response? Who needs to? 297 00:18:32,640 --> 00:18:35,320 Does anyone need to do that? Does the system need to do 298 00:18:35,320 --> 00:18:39,600 something at that point? As a system, I want to respond 299 00:18:39,960 --> 00:18:43,320 to searches for products within a timely meeting. 300 00:18:43,560 --> 00:18:47,120 So the better meaning that I've done my thing, now I want the 301 00:18:47,120 --> 00:18:49,800 system to do something. And if you think about it that 302 00:18:49,800 --> 00:18:53,040 way, again, like a comic book, but with all the characters, 303 00:18:53,040 --> 00:18:57,440 including the system as a character, you won't miss all 304 00:18:57,440 --> 00:19:03,160 the user stories #7 make the user story testable. 305 00:19:04,320 --> 00:19:11,240 And so we do that by doing great acceptance criteria, but we also 306 00:19:12,080 --> 00:19:15,600 need to write a user story in a way that testers can validate 307 00:19:15,600 --> 00:19:17,920 whether or not it works as expected. 308 00:19:18,480 --> 00:19:21,440 So an example might be as a subscriber, I want to be able to 309 00:19:21,440 --> 00:19:25,000 cancel my subscription from again, where? 310 00:19:25,440 --> 00:19:30,360 From the account setting page so that I can stop being billed if 311 00:19:30,360 --> 00:19:35,200 I no longer need the service. And then in the acceptance 312 00:19:35,200 --> 00:19:38,120 criteria you might have, the user can navigate to the account 313 00:19:38,120 --> 00:19:42,040 settings and see a Cancel subscription button. 314 00:19:42,520 --> 00:19:45,600 Clicking the button triggers a confirmation response 315 00:19:46,000 --> 00:19:49,560 calculation is processed and the user is notified by e-mail. 316 00:19:49,560 --> 00:19:53,640 That completes the whole actual comic book, the story side of 317 00:19:53,640 --> 00:19:57,040 the user story. They need to be testable, so 318 00:19:57,040 --> 00:19:59,280 make sure that you're writing something that can actually be 319 00:19:59,280 --> 00:20:02,560 tested. If it's not, then you may need 320 00:20:02,560 --> 00:20:05,920 to reword your user story. And they're not all. 321 00:20:06,520 --> 00:20:09,840 For example, numbers or counts could just be binary. 322 00:20:09,840 --> 00:20:13,960 Does it work? Does it #8 is prioritize just 323 00:20:13,960 --> 00:20:19,160 user stories by business value, not by development preference? 324 00:20:19,480 --> 00:20:23,120 Not by what you think is the most important, but what the 325 00:20:23,120 --> 00:20:26,480 user, the customer, the business thinks is the most important. 326 00:20:27,200 --> 00:20:30,720 This ensures that the team is always working on the highest 327 00:20:30,720 --> 00:20:36,960 impact items and features. So for example, as a customer, I 328 00:20:36,960 --> 00:20:39,680 want to be able to track my order in real time so that I 329 00:20:39,680 --> 00:20:42,120 know exactly when it will be delivered. 330 00:20:43,480 --> 00:20:49,520 Now that's an example there where a user wants to know when 331 00:20:49,520 --> 00:20:52,520 they want to track my order. Now let's say there's another 332 00:20:52,520 --> 00:20:59,280 user story which is as a user, I want to be able to view where my 333 00:20:59,280 --> 00:21:05,760 order is at, OK, so that I know when it will be delivered or I 334 00:21:05,760 --> 00:21:09,000 get some idea about when it's going to be delivered. 335 00:21:09,560 --> 00:21:13,760 So the fact that we have two user stories, one which is just 336 00:21:13,760 --> 00:21:17,200 a roundabout to track my order bit more light and the other 337 00:21:17,200 --> 00:21:20,000 ones around tracking in real time, which might be a should 338 00:21:20,000 --> 00:21:23,480 have requirement. The business value might be just 339 00:21:23,480 --> 00:21:28,080 to implement the tracking order first and then you will do the 340 00:21:28,080 --> 00:21:34,640 real time tracking and a next Sprint if it's deemed highest 341 00:21:34,640 --> 00:21:36,600 value. So you need to prioritize these 342 00:21:36,600 --> 00:21:39,760 things. I would suggest that a trick to 343 00:21:39,760 --> 00:21:43,080 fight to even realizing whether or not a user story is the most 344 00:21:43,080 --> 00:21:46,720 valuable is that it allows the user to complete their journey, 345 00:21:47,040 --> 00:21:49,800 their job to be done, so they're able to complete their full 346 00:21:49,800 --> 00:21:52,520 cycle. So you should focus on them 347 00:21:52,520 --> 00:21:58,560 being able to perform a step. OK, just yes or no? 348 00:21:58,560 --> 00:22:01,360 Can they complete that step tracking their order or viewing 349 00:22:01,360 --> 00:22:04,880 the order or checking out before you start to work on user 350 00:22:04,880 --> 00:22:09,080 stories which aren't MVP for And what that means is before you 351 00:22:09,080 --> 00:22:16,960 start adding additional features to other areas #9 is is never 352 00:22:16,960 --> 00:22:19,640 done well here. And that is considered 353 00:22:19,640 --> 00:22:24,720 dependencies between stories. Sometimes 1 user story cannot be 354 00:22:24,720 --> 00:22:27,360 fully implemented without completing another. 355 00:22:28,400 --> 00:22:30,960 OK, like I said, there might be a user journey. 356 00:22:30,960 --> 00:22:35,040 So that's literally the the journey of the customer to get 357 00:22:35,040 --> 00:22:37,080 from A to B. That's important. 358 00:22:37,600 --> 00:22:40,480 Your storyboard should show that. 359 00:22:41,560 --> 00:22:48,160 But also in delivery there might be some dependencies that ensure 360 00:22:48,160 --> 00:22:53,280 smooth delivery. So for example, they say as a 361 00:22:53,280 --> 00:22:57,960 customer, I want to pay using PayPal so that I can complete my 362 00:22:57,960 --> 00:23:00,760 purchase using my preferred payment method. 363 00:23:00,880 --> 00:23:03,600 That's a pretty common user story here. 364 00:23:05,440 --> 00:23:07,600 And there will be some acceptance criteria that go 365 00:23:07,600 --> 00:23:11,000 under that. But what we might realize is 366 00:23:11,000 --> 00:23:13,120 that that's someone's working on that. 367 00:23:13,120 --> 00:23:16,720 They're building a screen, they've got the PayPal logo, 368 00:23:17,240 --> 00:23:20,960 they've like designed it really nicely. 369 00:23:20,960 --> 00:23:24,800 They've given the user option, but there was no point in doing 370 00:23:24,800 --> 00:23:28,760 that user story because I haven't completed as a system. 371 00:23:28,800 --> 00:23:32,920 I want to be able to integrate with PayPal to provide PayPal 372 00:23:32,920 --> 00:23:36,600 payments. So the Paymal integration must 373 00:23:36,600 --> 00:23:39,400 be completed before implementing this story. 374 00:23:39,720 --> 00:23:43,880 So you don't just focus, you do focus on the user value from the 375 00:23:43,880 --> 00:23:45,800 storyboard point of view and what's the sequence. 376 00:23:46,080 --> 00:23:49,320 But ultimately, you also need the development team to think 377 00:23:49,320 --> 00:23:51,760 about what user stories need to be done and what sequence. 378 00:23:53,000 --> 00:23:56,280 So for example, you can't offer pay, pay by power Pal to a 379 00:23:56,280 --> 00:24:01,160 customer, which is high value if you haven't done PayPal 380 00:24:01,160 --> 00:24:05,000 integration. So if there are sequences that 381 00:24:05,000 --> 00:24:08,520 you just need to focus on, and so that's using dependencies 382 00:24:08,520 --> 00:24:11,520 prerequisites, that would be fantastic. 383 00:24:11,520 --> 00:24:14,440 And you can do that in tools like Jira, Jira and DevOps. 384 00:24:15,480 --> 00:24:22,560 And #10 #10 is to adopt User Stories 2.0 to include triggers 385 00:24:22,640 --> 00:24:25,720 and HDS. So to address gaps in 386 00:24:25,720 --> 00:24:29,600 traditional user stories, you can adopt User Stories 2.0, 387 00:24:29,960 --> 00:24:37,280 which adds 2 critical components with User stories 2.0. 388 00:24:37,880 --> 00:24:41,080 What we have introduced here at the Better Business Analysis 389 00:24:41,080 --> 00:24:49,960 Institute is both with trigger, OK, So that allows us to know 390 00:24:50,320 --> 00:24:55,120 what entity are we affecting. This could ultimately end up 391 00:24:55,120 --> 00:24:58,720 being a feature in your development. 392 00:24:58,720 --> 00:25:01,680 So it's an output, a page and area. 393 00:25:02,840 --> 00:25:05,400 So that is, but entity is a really good way of looking at 394 00:25:05,400 --> 00:25:08,200 it. So it's like with car or wheel, 395 00:25:08,200 --> 00:25:11,440 OK, a conceptual entity that you may have drawn up and we 396 00:25:11,440 --> 00:25:14,360 introduce a win, a trigger, a condition. 397 00:25:15,320 --> 00:25:18,920 So that allows us to talk about timing and what needs to be 398 00:25:18,920 --> 00:25:21,560 true. Now this won't necessarily 399 00:25:21,560 --> 00:25:24,160 replace all the business rules that you have in your acceptance 400 00:25:24,160 --> 00:25:29,000 criteria, but it will give you the main reason for why and 401 00:25:29,000 --> 00:25:32,240 when. And with this user story 402 00:25:32,400 --> 00:25:37,600 functions around. So this is the format that we 403 00:25:37,600 --> 00:25:43,640 use as a persona. I want to right perform function 404 00:25:43,960 --> 00:25:48,840 desired feature whatever it is so that user value goal when 405 00:25:49,680 --> 00:25:53,360 trigger condition with entity being affected. 406 00:25:54,160 --> 00:25:57,760 So let's work through a really good example here. 407 00:25:58,080 --> 00:26:04,760 As a customer, I want to manage my e-mail subscriptions so that 408 00:26:04,760 --> 00:26:13,640 I can choose which e-mail I receive when my account is 409 00:26:13,680 --> 00:26:21,520 activated OK and managed with the account setting page. 410 00:26:23,880 --> 00:26:29,040 So you've, if you're ABA working on detailed user stories, you 411 00:26:29,040 --> 00:26:30,240 should be in the development team. 412 00:26:30,560 --> 00:26:33,080 They're talking about how they're going to design it. 413 00:26:33,080 --> 00:26:35,120 And you already know conceptually there might be an 414 00:26:35,120 --> 00:26:37,160 e-mail settings page. You should have drawn that up 415 00:26:37,160 --> 00:26:39,520 probably conceptually and you're thinking about it. 416 00:26:39,520 --> 00:26:42,360 You say, well, I want them to manage the subscriptions in this 417 00:26:42,360 --> 00:26:44,720 area. So why don't you be more 418 00:26:44,720 --> 00:26:49,440 explicit when you're in the detailed planning phase, you're 419 00:26:49,440 --> 00:26:52,120 in the Sprint and you talk about, well, where, where do you 420 00:26:52,120 --> 00:26:54,840 want this to happen? So that means the developer now 421 00:26:54,840 --> 00:26:57,680 knows, and you may have drawn a picture of this, that that's 422 00:26:57,680 --> 00:27:00,680 where this function should take place. 423 00:27:01,600 --> 00:27:04,640 So they're not building a whole other area or they're not 424 00:27:04,640 --> 00:27:06,680 guessing. So you're being really explicit. 425 00:27:06,680 --> 00:27:11,560 You're, you've visualized that this would be a setting in the 426 00:27:11,560 --> 00:27:15,280 account setting area, OK, around managing your e-mail 427 00:27:15,280 --> 00:27:19,080 subscriptions. So that makes things really 428 00:27:19,080 --> 00:27:23,320 explicit. So with user storage 2.0, you're 429 00:27:23,320 --> 00:27:25,680 adding the when and you're adding the with. 430 00:27:25,800 --> 00:27:28,760 And in this case, when was just the fact that you had an account 431 00:27:29,000 --> 00:27:31,680 OK? It wouldn't be for customers who 432 00:27:31,680 --> 00:27:35,560 weren't logged in or for customers who hadn't signed up 433 00:27:35,600 --> 00:27:37,160 yet. So it was when they had an 434 00:27:37,160 --> 00:27:40,600 active account. So that again, talks about 435 00:27:40,600 --> 00:27:48,080 security gives quite a lot around the both the state of the 436 00:27:48,080 --> 00:27:50,240 account. And of course, it might just be 437 00:27:50,240 --> 00:27:54,400 any time they want to do it. And whenever I choose to update 438 00:27:54,400 --> 00:28:00,160 my subscriptions and the worth of game talks links it back to 439 00:28:00,160 --> 00:28:03,520 the architecture, to the actual reality of the fact there's a 440 00:28:03,520 --> 00:28:06,720 component which needs to be built, which is your account 441 00:28:06,720 --> 00:28:10,400 settings area. So have a read of the white 442 00:28:10,400 --> 00:28:13,800 paper around User Stories 2.0. It isn't perfect, but what it 443 00:28:13,800 --> 00:28:17,760 allows us to do is bring in some of the things we lost from use 444 00:28:17,760 --> 00:28:21,680 cases which aren't used that often and business rules and 445 00:28:21,680 --> 00:28:28,400 process and starts to really allow you to incorporate all the 446 00:28:28,400 --> 00:28:32,640 thinking that you have done as a BA into the user story. 447 00:28:32,760 --> 00:28:35,560 So it doesn't just get lost. So the other thing, of course, 448 00:28:35,560 --> 00:28:39,480 is adding visuals to this and pointing to this is really helps 449 00:28:39,680 --> 00:28:44,280 linking back to mock ups and a process diagram around when, 450 00:28:44,280 --> 00:28:45,800 when do you allow them to do this? 451 00:28:46,040 --> 00:28:49,680 So this feature, for example, which is around being update 452 00:28:49,680 --> 00:28:54,560 your subscription preferences, your emails subscription can 453 00:28:54,560 --> 00:28:57,560 happen kind of whenever throughout your kind of managing 454 00:28:57,560 --> 00:29:02,080 account, your account life cycle and other examples. 455 00:29:02,080 --> 00:29:07,880 There will be specific time periods when things happen like, 456 00:29:07,920 --> 00:29:11,520 you know, the 30th of every month, send an e-mail to 457 00:29:11,520 --> 00:29:14,000 someone. OK, so you can see the timing 458 00:29:14,560 --> 00:29:18,680 and this so that will link to your process diagram and to your 459 00:29:18,680 --> 00:29:20,840 mock ups. And it means that your user 460 00:29:20,840 --> 00:29:24,880 stories are full and complete. So there are 10 top tips to make 461 00:29:24,880 --> 00:29:27,680 your user stories awesome. I hope you got value. 462 00:29:28,120 --> 00:29:31,200 Apologize for my voice today and I'll see you next week.