1 00:00:08,865 --> 00:00:12,565 What proven practices are there for managing your Power Platform 2 00:00:12,625 --> 00:00:16,430 or Dynamics 3 65 product backlog in Azure DevOps? How 3 00:00:16,430 --> 00:00:20,270 much detail should your user stories contain, and how do 4 00:00:20,270 --> 00:00:24,050 you ensure that what you're doing enhances your user's experience? 5 00:00:24,695 --> 00:00:28,375 If you use an agile approach like Scrum to build Power Platform or 6 00:00:28,375 --> 00:00:31,675 Dynamics 3 65 applications, you won't wanna miss 7 00:00:31,970 --> 00:00:35,809 The insights that Danica Hill shares in this episode of 8 00:00:35,809 --> 00:00:39,329 Amazing Apps, the podcast for Dynamics 3 65 and Power Platform 9 00:00:39,329 --> 00:00:43,155 professionals that wanna build amazing Agile business apps. I'm 10 00:00:43,155 --> 00:00:46,535 your host, Neil Benson. I'm a Microsoft MVP, 11 00:00:46,915 --> 00:00:50,390 and I've coached and trained Thousands of business apps 12 00:00:50,390 --> 00:00:54,170 builders to use scrum since I first used it myself in 13 00:00:54,230 --> 00:00:57,925 2008, and I'm on a mission to help you use 14 00:00:57,925 --> 00:01:01,605 agile practices to build amazing business apps for your 15 00:01:01,605 --> 00:01:05,409 users as well. This is episode 152. If you're 16 00:01:05,409 --> 00:01:09,189 listening to the audio podcast, you'll find show notes with links to resources 17 00:01:09,409 --> 00:01:11,270 and a transcript at amazingapps.show/one52. 18 00:01:13,649 --> 00:01:17,395 And if you're watching on YouTube, You'll find them in the description, down 19 00:01:17,395 --> 00:01:21,075 below. Here's Danny Cahill. Danny, welcome 20 00:01:21,075 --> 00:01:24,740 back to Amazing Applications. I was just looking to see how many times 21 00:01:24,740 --> 00:01:28,340 you'd been on this show before, and I thought it was 2, 22 00:01:28,340 --> 00:01:31,940 3, maybe 4. It's actually 6th. This is your 6th appearance. Welcome back, my 23 00:01:31,940 --> 00:01:35,785 friend. Thank you. Yeah. That's my favorite show. 24 00:01:35,785 --> 00:01:38,925 Right? It's everybody's favorite show, Danny. 25 00:01:39,705 --> 00:01:43,440 Absolutely. Yeah. Yeah. Thank you. Yeah. Yeah. Absolutely. And it's always a 26 00:01:43,440 --> 00:01:47,220 pleasure to, you know, discuss with you and bounce ideas, 27 00:01:47,360 --> 00:01:51,195 and And you have been actually well, that's why I'm 6 times, right, because you 28 00:01:51,255 --> 00:01:54,695 have been kind enough to kind of host some of my 29 00:01:54,695 --> 00:01:58,429 conversation with other guests. Right. Yeah. Absolutely. So that counts too. 30 00:01:59,130 --> 00:02:01,609 I noticed you've been doing a lot of work with Hamish recently. So if you 31 00:02:01,609 --> 00:02:05,450 and Hamish wanna do a takeover episode, you're more than welcome. We'd love to to 32 00:02:05,450 --> 00:02:09,185 have you. But today, we're gonna focus on managing 33 00:02:09,405 --> 00:02:12,685 the product backlog, which is something a lot of teams struggle with. A lot of 34 00:02:12,685 --> 00:02:16,470 teams could do very, very differently From 1 organization to the next, what do 35 00:02:16,470 --> 00:02:20,150 you think the biggest challenge is that business apps teams have managing their 36 00:02:20,150 --> 00:02:23,855 product backlogs? What have you seen out there in the wild in your experience? Yeah. 37 00:02:23,855 --> 00:02:27,375 So the number 1 challenge, really, what I what I see, Radey, is kind of 38 00:02:27,375 --> 00:02:31,135 structuring almost what is the best or what is the the right 39 00:02:31,135 --> 00:02:34,730 structure for The the project that you are in. And there is no 40 00:02:35,530 --> 00:02:39,290 I found that there there are tapes or there is way you can structure 41 00:02:39,290 --> 00:02:43,065 your backlog, but Every project will be different, and every project will have 42 00:02:43,065 --> 00:02:46,825 to kind of adapt slightly to how the 43 00:02:46,825 --> 00:02:50,349 client works, where they are in the journey on managing for the 44 00:02:50,349 --> 00:02:54,030 backlogs and so forth. Right? So it's always a bit of a tweaking. I 45 00:02:54,030 --> 00:02:57,505 found myself, Like, how I use to structure the the 46 00:02:57,505 --> 00:03:00,545 backlog and in my head as well, and how I would recommend my clients to 47 00:03:00,545 --> 00:03:04,270 do if they don't know it, they just want our recommendations is I 48 00:03:04,270 --> 00:03:08,030 always try to follow a bit of a high level process. Right? So 49 00:03:08,030 --> 00:03:11,550 even if you have your kind of story map, I do I don't do 50 00:03:11,550 --> 00:03:15,265 often, Like, real story mapping, but I cannot follow the 51 00:03:15,265 --> 00:03:18,584 same process where I decompose the high level phases 52 00:03:18,864 --> 00:03:22,189 Yeah. Of a of a user, of a client 53 00:03:22,409 --> 00:03:25,769 throughout the journey. Right? And those will be my big building 54 00:03:25,769 --> 00:03:29,575 blocks. It's easy for me to understand, And then I go 55 00:03:29,575 --> 00:03:32,935 to the level of so that would be my epics, and then I have my 56 00:03:32,935 --> 00:03:36,770 features, and then I go down to the level. But that's how I structure it, 57 00:03:36,930 --> 00:03:40,610 But it's a bit of a challenge I see, and if there is an 58 00:03:40,610 --> 00:03:44,450 existing backlog already, like everyone is doing it differently, like 59 00:03:44,450 --> 00:03:48,215 sometimes by apps, by technology Yep. 60 00:03:48,375 --> 00:03:51,895 By and, you know, it sometimes it makes sense. Right? And I was not there 61 00:03:51,895 --> 00:03:54,855 at the beginning with the person. I cannot really judge. But if I would start 62 00:03:54,855 --> 00:03:58,440 from from scratch, I would strive to structure it that way. I'm not really 63 00:03:58,440 --> 00:04:02,200 fine. Responded directly to your question and maybe responded way more. But yep. Okay. 64 00:04:02,200 --> 00:04:05,564 So let let's let's tackle some of those ideas 1 by 1. Imagine 65 00:04:05,724 --> 00:04:09,344 Mhmm. You're in a greenfield scenario, so there's no backlog management 66 00:04:09,405 --> 00:04:13,180 tool there Mhmm. Today. First of all, Who 67 00:04:13,180 --> 00:04:16,860 do you think should manage the backlog? Do you, as a expert in 68 00:04:16,860 --> 00:04:20,675 managing requirements, do you take that responsibility on? Or do you like 69 00:04:20,675 --> 00:04:24,435 your product owner? Who's typically, you know, somebody from the customer side? Do 70 00:04:24,435 --> 00:04:28,275 you coach them in how to get to grips with, you 71 00:04:28,275 --> 00:04:32,000 know, Jira, Azure DevOps or some other tool. Who do you think should do 72 00:04:32,000 --> 00:04:34,900 most of the work? Yeah. Oh, 73 00:04:35,360 --> 00:04:39,005 look. Very early. I I would start if I can start 74 00:04:39,005 --> 00:04:42,685 from from an ideal project. Right? Very early on, you 75 00:04:42,685 --> 00:04:46,360 wanna you wanna coach your product owner and make him 76 00:04:46,360 --> 00:04:49,880 responsible that they are the owner of the product backlog. Like, this 77 00:04:50,040 --> 00:04:53,724 there is no there is no question about that. Right? They need to 78 00:04:53,724 --> 00:04:57,425 know that they own the product backlog and what is in there. 79 00:04:58,044 --> 00:05:01,185 What it means owning? They're making decision on prioritization, 80 00:05:02,200 --> 00:05:05,960 They make decision on namings and how we 81 00:05:05,960 --> 00:05:09,655 want to structure this. The challenge we often have is A lot 82 00:05:09,655 --> 00:05:12,555 of them don't have a clue on how to do that. 83 00:05:13,735 --> 00:05:17,190 They know their business pretty well, right? They know the business, They're 84 00:05:17,190 --> 00:05:20,710 pretty, you know, high stake, but I hire in the in the 85 00:05:20,710 --> 00:05:24,550 management layer and everything, but they have never done 86 00:05:24,550 --> 00:05:28,175 of have never done product ownership, They don't know exactly what is a 87 00:05:28,175 --> 00:05:31,695 product backlog. How do we who how do I even name that thing? So we 88 00:05:31,775 --> 00:05:35,510 it's a bit of a guidance where most of the time Look. Ideal 89 00:05:35,510 --> 00:05:38,870 scenario, the product owners have done that in the past. They know the product their 90 00:05:38,870 --> 00:05:42,570 product backlog. We can just guide them maybe on restructuring a bit, 91 00:05:42,905 --> 00:05:46,745 What makes sense to do before another epic because, otherwise, it 92 00:05:46,745 --> 00:05:50,525 does it breaks the system or something. That's ideal. But most of the time, 93 00:05:50,985 --> 00:05:54,810 they are they are new. And then in this case, we would 94 00:05:54,810 --> 00:05:58,570 often come up with a a structure of the product 95 00:05:58,570 --> 00:06:02,315 backlog based on the language and that High level 96 00:06:02,315 --> 00:06:05,835 journey that we have discussed. So we have those workshops maybe with, you know, with 97 00:06:05,835 --> 00:06:08,815 the client and stakeholders. We map those high level, 98 00:06:09,660 --> 00:06:13,199 steps in the journey, which then leads to 99 00:06:13,259 --> 00:06:16,940 epics. And we do that together in consultation with the client, and we 100 00:06:16,940 --> 00:06:20,655 would most of the time, One of us or myself, I would 101 00:06:20,655 --> 00:06:24,014 create the epics because they don't know the tool. So it's almost like a 102 00:06:24,014 --> 00:06:27,840 guidance throughout the beginning, But throughout the 1st few 103 00:06:27,840 --> 00:06:31,379 weeks, 1st few months, that is slowly transitioning. 104 00:06:31,840 --> 00:06:35,599 Right? Yeah. They start, taking over DevOps, and 105 00:06:35,599 --> 00:06:39,345 then we Tag them in in in user stories. We tag them in 106 00:06:39,345 --> 00:06:41,925 features. We tag the metrics. And then gradually, 107 00:06:43,240 --> 00:06:47,000 Ideal scenario is that you have a very senior BA or even the product 108 00:06:47,000 --> 00:06:50,735 owner going in, and then we'll Groom the 109 00:06:50,735 --> 00:06:54,495 product backlog. We change split the epics into epics or 110 00:06:54,495 --> 00:06:58,040 kind of group some features together or, You know, 111 00:06:58,040 --> 00:07:01,800 cancel them completely or rename them. Right? But that is kind of a 112 00:07:01,800 --> 00:07:05,455 bit of a journey that I've seen, but Yeah. 113 00:07:05,455 --> 00:07:08,735 That is kind of an ideal scenario I would I would see. Yeah. I I've 114 00:07:08,815 --> 00:07:12,195 my my experience mirrors yours exactly, Danny. So I'm working with 115 00:07:12,599 --> 00:07:16,440 1st time product owners, people who understand their business very well. They're in operations. They're 116 00:07:16,440 --> 00:07:20,175 in sales. They're marketing. They're some kind of leadership position. They know the business 117 00:07:20,175 --> 00:07:23,455 processes. They know existing systems. They know the business challenges they wanna try and solve 118 00:07:23,455 --> 00:07:26,575 and the outcomes they're looking for. They don't know how to use Azure DevOps. They 119 00:07:26,575 --> 00:07:30,350 don't know an epic from a feature. And so we drive the tool 120 00:07:30,350 --> 00:07:34,130 at the beginning, with their blessing and their oversight. And then gradually, 121 00:07:34,430 --> 00:07:37,965 they get more hands on with it. I still quite often have one of the 122 00:07:37,965 --> 00:07:41,324 developers who's got a background as a business analyst, still doing most of the day 123 00:07:41,324 --> 00:07:44,970 to day work in Azure DevOps. Yeah. The accountability for what's in 124 00:07:44,970 --> 00:07:48,810 scope, what's next, what's high priority, what's not is always with the 125 00:07:48,810 --> 00:07:51,645 customer's product owner. So my experience is very similar to yours. 126 00:07:52,365 --> 00:07:56,044 Yeah. Yeah. Yeah. Absolutely. Yeah. Glad to hear. Yeah. If, 127 00:07:56,205 --> 00:07:59,664 if you have a choice of which backlog management tool to use, 128 00:08:00,240 --> 00:08:03,280 Jira is very popular here in Australia. As you as you know, Atlassian is a 129 00:08:03,280 --> 00:08:07,040 big Australian tech company. Microsoft Azure DevOps is 130 00:08:07,040 --> 00:08:10,775 very popular, of course, amongst the Microsoft community, And there are there are dozens or 131 00:08:10,775 --> 00:08:14,535 hundreds of others. Do you have a preference if given 132 00:08:14,535 --> 00:08:17,815 the choice? I have a strong preference for DevOps. Yeah. Good. And 133 00:08:18,055 --> 00:08:21,410 Good. It's a it's a preference. I've used it for many 134 00:08:21,410 --> 00:08:25,190 years. I just use very, I think 135 00:08:25,330 --> 00:08:29,125 a few years ago, I used Jira on another project, but that's it. Like, 136 00:08:29,665 --> 00:08:33,505 I think it's a personal preference in term of just a project that 137 00:08:33,505 --> 00:08:37,170 was involved with is plan ahead DevOps 138 00:08:37,170 --> 00:08:40,370 already, or they let us make the choice and we went with DevOps? So very 139 00:08:40,370 --> 00:08:44,130 strong preference for DevOps. Yeah. Yeah. What about yourself? Yeah. I I 140 00:08:44,210 --> 00:08:47,565 mostly, I've been using Jira for the past few years, but when we get a 141 00:08:47,565 --> 00:08:51,005 chance, we'll use Azure DevOps. And I don't know what it is about 142 00:08:51,005 --> 00:08:54,680 Jira, but it's quite often just badly configured or it's It's an 143 00:08:54,680 --> 00:08:58,360 enterprise tool that's being configured for lots of different teams. And then I can 144 00:08:58,360 --> 00:09:01,800 say, hey. Look. I wanna run a scrum team following these principles and these 145 00:09:01,800 --> 00:09:05,495 practices. Jira hasn't been configured for that kind of approach. 146 00:09:05,715 --> 00:09:09,450 And Yeah. So it's just there's there's just some weird things like 147 00:09:09,610 --> 00:09:13,290 You have to finish the sprint, and then you have to manually 148 00:09:13,290 --> 00:09:16,650 start the next sprint. Like, one sprint should follow another naturally. I don't know. There's 149 00:09:16,730 --> 00:09:20,055 Yeah. Just some things I don't like about Jira. Yeah. Right. Okay. But it's very 150 00:09:20,055 --> 00:09:23,814 popular. Azure DevOps just seems to be a bit more natural. And, of 151 00:09:23,814 --> 00:09:27,530 course, it's where most of my developers do, You know, pipelines 152 00:09:27,750 --> 00:09:31,510 and source control, everything's been driven from there. I 153 00:09:31,510 --> 00:09:35,030 haven't seen I haven't seen many of my teams use 154 00:09:35,030 --> 00:09:38,455 GitHub. And I know that that is you know, there's a lot of overlap these 155 00:09:38,455 --> 00:09:41,595 days between GitHub and Azure DevOps from a technical perspective. 156 00:09:42,375 --> 00:09:45,595 I'd say DevOps is still stronger from a boards and backlog perspective. 157 00:09:46,520 --> 00:09:49,820 I haven't seen I haven't seen anybody drive us towards using GitHub. 158 00:09:50,520 --> 00:09:54,360 Yep. Yep. That makes sense. You you talked a little bit about the 159 00:09:54,360 --> 00:09:58,065 hierarchy of Items that are in a backlog. Are you 160 00:09:58,065 --> 00:10:01,825 always using user stories, and is that the smallest, you know, 161 00:10:01,825 --> 00:10:05,649 type of item in your backlog? How do you How do you structure the hierarchy 162 00:10:05,649 --> 00:10:09,490 of items? Yeah. It really, again, depends the size of the of the whole 163 00:10:09,490 --> 00:10:12,995 project. Right? If it's very simple, Maybe we have features and 164 00:10:12,995 --> 00:10:16,835 user stories. Right? And that's it. If it's a bit bigger, you go 165 00:10:16,835 --> 00:10:20,610 to the level of epics. If it's quite large, I would sometimes so 166 00:10:20,610 --> 00:10:24,050 I I had a project where I created something above epics because I had I 167 00:10:24,050 --> 00:10:27,650 needed, like, 5 levels almost to structure. It's just from a structuring 168 00:10:27,650 --> 00:10:31,365 perspective, right, where, it could have been 169 00:10:31,365 --> 00:10:35,144 different projects too. Right? So it's kind of, you know, but basically yeah. 170 00:10:35,204 --> 00:10:38,690 Usually, epics feature user stories And then 171 00:10:38,690 --> 00:10:42,529 sometimes, and I have been introduced again to the concept of 172 00:10:42,529 --> 00:10:46,130 task by a product owner on on one of for one of my client, and 173 00:10:46,130 --> 00:10:49,945 it start It starts to yeah. And it's 174 00:10:50,025 --> 00:10:53,705 it helps sometimes where you have a user story and it's 175 00:10:53,705 --> 00:10:57,280 more a few guys need to do something specific, then we can 176 00:10:57,280 --> 00:11:00,980 create task for us. And it's almost like reminders 177 00:11:01,200 --> 00:11:04,945 to kind of you know, I need to Investigate this 178 00:11:04,945 --> 00:11:08,705 for that specific feature or I need to do a bit of design for 179 00:11:08,705 --> 00:11:12,280 that. This is how I would use task. It's not linked to so we 180 00:11:12,280 --> 00:11:15,960 don't really track tasks in, you know, in boards as well 181 00:11:15,960 --> 00:11:18,840 because I think you can track them as well in boards. Yes. I we used 182 00:11:18,840 --> 00:11:22,225 to do that in the past a years ago with another product owner, but that's 183 00:11:22,225 --> 00:11:25,985 not what I'm I'm talking about. It's more task where you can just manage 184 00:11:25,985 --> 00:11:29,765 your own workload within and everybody sees where you are. 185 00:11:29,990 --> 00:11:33,830 So it's used pretty loosely, to be fair. But, 186 00:11:33,830 --> 00:11:37,530 yeah, those are my 3 levels. Just on on the task thing, 187 00:11:37,935 --> 00:11:41,154 Yeah. When teams are using tasks and they've got a Kanban 188 00:11:41,615 --> 00:11:45,134 board style, visualization for tracking their 189 00:11:45,134 --> 00:11:48,900 work, The user story or the the product backlog item would remain 190 00:11:48,960 --> 00:11:52,720 on the left hand side, and the tasks would move through the columns until they're 191 00:11:52,720 --> 00:11:55,964 all done. Whereas if you don't wanna use tasks, 192 00:11:56,185 --> 00:11:59,944 generally, the whole story or the whole product backlog item moves 193 00:11:59,944 --> 00:12:01,964 through the columns towards done. 194 00:12:03,640 --> 00:12:07,160 Sounds like you're occasionally using tasks where that's helpful, but you're 195 00:12:07,160 --> 00:12:11,000 still you're not, you know, tracking the progress of individual tasks across the 196 00:12:11,000 --> 00:12:14,545 board. Working at a product backlog item level? Yeah. We 197 00:12:14,705 --> 00:12:18,465 we're really using user story as you mentioned, and we move user stories 198 00:12:18,465 --> 00:12:21,850 from one phase another. You know, analysis dev. We can talk about that a bit 199 00:12:21,850 --> 00:12:25,610 later. The task you can even see them on the board. Right? In DevOps, you 200 00:12:25,610 --> 00:12:28,805 can see, Like a little number 201 00:12:29,265 --> 00:12:33,105 and and indication how many task are open underneath just as an 202 00:12:33,105 --> 00:12:36,820 indication. It doesn't force anything. It's just there and as an indication, 203 00:12:37,040 --> 00:12:40,720 it's used loosely. We haven't really structured it, so 204 00:12:40,720 --> 00:12:44,420 that helps on it's that 1 project where I I'm using task. Otherwise, 205 00:12:45,345 --> 00:12:49,025 No. Okay. So for those of you not, not watching the YouTube 206 00:12:49,025 --> 00:12:52,865 version of this, discussion, I I kinda threw my head into my hands 207 00:12:52,865 --> 00:12:56,530 when Danny talks about tasks because there there are a couple of anti patterns I've 208 00:12:56,530 --> 00:13:00,130 seen, and and Danny doesn't sound like he's falling into these anti 209 00:13:00,130 --> 00:13:03,565 patterns. But I used to see teams With a product backlog item, 210 00:13:03,865 --> 00:13:07,565 and then they they would create tasks underneath or subtasks, sometimes they're called. 211 00:13:07,625 --> 00:13:10,985 And those subtasks would look like analysis, design, 212 00:13:10,985 --> 00:13:14,350 development, testing, deployment. And so it's a series of waterfall 213 00:13:14,490 --> 00:13:18,250 steps for each product backlog item. And so we 214 00:13:18,250 --> 00:13:21,875 just had a 100 tasks all called analysis and a 100. Yeah. Just 215 00:13:22,275 --> 00:13:26,035 Very repetitive, not very helpful. But, if you don't 216 00:13:26,035 --> 00:13:29,795 use tasks like that and you do use them occasionally as really important stuff that 217 00:13:29,795 --> 00:13:33,200 needs to get done, needs to get tracked, And the other people might be interested 218 00:13:33,200 --> 00:13:36,900 in, then I think that's a very fair, fair use of some tasks. So, 219 00:13:37,520 --> 00:13:41,115 I applaud you, Danny, in in, you know, figuring out what works for your team 220 00:13:41,115 --> 00:13:44,954 because that's what it's all about. Right? Yeah. Yeah. Absolutely. Yeah. I'll be 221 00:13:44,954 --> 00:13:48,530 keen to to understand as well how you, yeah, How you manage your 222 00:13:48,530 --> 00:13:52,130 analysis task in user story or your analysis activities and user 223 00:13:52,130 --> 00:13:55,975 story, but we can Yeah. We can, yeah, Talk about 224 00:13:55,975 --> 00:13:59,415 that in a sec. Well, let's let's go to the next because that's that's where 225 00:13:59,415 --> 00:14:02,590 that's where user stories start. Right? We Yeah. 226 00:14:03,150 --> 00:14:06,910 I would typically have, similar to you, at the outset of 227 00:14:06,910 --> 00:14:10,510 the project, a series of epics, maybe 12, 15, or 20 228 00:14:10,510 --> 00:14:14,275 epics, You know, from small and mid sized project, and that 229 00:14:14,275 --> 00:14:18,035 defines the scope of the project. Mhmm. And then we we start to refine 230 00:14:18,035 --> 00:14:21,790 those epics, which is the most important epic. Oh, it's Contact management. Contact management's 231 00:14:21,790 --> 00:14:25,230 always a good one because it's kind of the foundation for a lot of the 232 00:14:25,230 --> 00:14:28,925 other features that are gonna come later. So we start with contacts. We'll 233 00:14:28,925 --> 00:14:32,605 refine that epic down into creating a contact, updating a 234 00:14:32,605 --> 00:14:36,125 contact, duplicate detection and emerging contacts, 235 00:14:36,125 --> 00:14:39,760 importing contacts, and so on. And so we're splitting. That's the 1st shot. 236 00:14:39,760 --> 00:14:43,520 Split the epic down Yep. Into something smaller, maybe a feature, maybe 237 00:14:43,520 --> 00:14:47,220 a user story. And then we start to enrich that 238 00:14:47,585 --> 00:14:51,125 Product backlog item with a decent user story title 239 00:14:51,265 --> 00:14:55,105 or description, and then some acceptance criteria and and the estimates 240 00:14:55,105 --> 00:14:58,930 get, created and and off we go. Is that similar or completely 241 00:14:58,930 --> 00:15:02,230 different to your process? So 242 00:15:02,930 --> 00:15:06,425 most of the tasks that we could define, I guess, From a feature perspective and 243 00:15:06,425 --> 00:15:09,865 in breaking them down when we have our workshop or grooming 244 00:15:09,865 --> 00:15:13,625 session, and then we decompose them in those user 245 00:15:13,625 --> 00:15:17,160 stories. But I've So I would follow the same in in most 246 00:15:17,160 --> 00:15:20,780 scenarios. Now where I'm finding some challenges, 247 00:15:21,720 --> 00:15:25,404 and maybe your your input might help me here, is Sometimes 248 00:15:26,265 --> 00:15:29,705 a task might require a decent amount of analysis 249 00:15:29,945 --> 00:15:33,720 sorry, the user story might require this amount of analysis. And we 250 00:15:33,720 --> 00:15:37,480 kind of it's because we we we thought about as a user story 251 00:15:37,480 --> 00:15:41,080 when we discussed that feature, and then we we now it's time to implement 252 00:15:41,080 --> 00:15:44,585 that feature, and then we that that user story, and we realize it's 253 00:15:44,585 --> 00:15:48,425 actually a lot of analysis. I I need to talk to integration team. I need 254 00:15:48,425 --> 00:15:51,880 to talk to this, And then we need to figure out how we got so 255 00:15:51,880 --> 00:15:55,560 it's a lot of kind of analysis. And then, basically, that 256 00:15:55,560 --> 00:15:58,875 user story, which is big, 257 00:15:59,334 --> 00:16:03,175 then it's becoming this is where sometimes I don't know I don't 258 00:16:03,175 --> 00:16:06,780 have a process in my head what best to follow where I would then 259 00:16:06,800 --> 00:16:10,060 say, okay. That is my analysis user story, 260 00:16:10,520 --> 00:16:14,220 and I will I will spend some time I will spend some time 261 00:16:14,904 --> 00:16:18,685 Or doing the sprint analyzing and kind of making 262 00:16:19,305 --> 00:16:23,144 a bit of a design and then decomposing that in maybe other 263 00:16:23,144 --> 00:16:26,560 user stories. Sure. This is 264 00:16:26,560 --> 00:16:30,240 typically what I would follow because then it's assigned to me. It is always assigned 265 00:16:30,240 --> 00:16:33,865 to one of my team member for the the print, and it fits 266 00:16:33,865 --> 00:16:37,704 within the sprint, and we can finish it within the sprint. But I'm 267 00:16:37,704 --> 00:16:41,225 not sure if that's the best way. I feel there is better way to to 268 00:16:41,225 --> 00:16:45,010 do it. What What would you recommend? I think my my 269 00:16:45,010 --> 00:16:48,690 approach is probably fairly similar, and it's not the same approach. Like you said, it's 270 00:16:48,690 --> 00:16:52,345 not the same approach every time. Different customers Yeah. Want us to work slightly 271 00:16:52,345 --> 00:16:56,105 differently. Generally, there'll be a developer in the, in 272 00:16:56,105 --> 00:16:59,850 the team. Who's got a business analysis background. That developer 273 00:17:00,150 --> 00:17:03,990 is working closely with a product owner and the subject matter experts, and they 274 00:17:03,990 --> 00:17:07,770 have a, an epic broken down into features or user stories, 275 00:17:08,135 --> 00:17:11,674 And they have a status that says either in analysis 276 00:17:11,974 --> 00:17:15,815 or not ready. Quite often, we just call it not ready. And that's 277 00:17:15,815 --> 00:17:19,289 where a Product backlog item is being enhanced 278 00:17:19,289 --> 00:17:23,049 with better descriptions or, maybe a wireframe of how 279 00:17:23,049 --> 00:17:26,774 the user interface might look or some sample data Or, you know, whatever it 280 00:17:26,774 --> 00:17:30,375 is that that the an analyst needs to gather. Like you said, 281 00:17:30,375 --> 00:17:33,900 integration requirements. And and so once it's We'll see. Analyst 282 00:17:33,960 --> 00:17:37,580 feels it's ready. They'll bring it up in the next 283 00:17:37,640 --> 00:17:41,375 product backlog refinement meeting. We used to call it grooming, but the 284 00:17:41,375 --> 00:17:44,015 the scrum guide updated that language a couple years ago. So now we call it 285 00:17:44,015 --> 00:17:47,775 refinement. Sometimes we call it elaboration. And that's where the developers roll 286 00:17:47,775 --> 00:17:51,210 there with the analyst and the prop owner and saying, okay. This one's we think 287 00:17:51,210 --> 00:17:55,050 it's ready. Okay. Well, let's take a look at it. So the developers will 288 00:17:55,050 --> 00:17:58,585 discuss it, ask some questions, try and Dive a little bit 289 00:17:58,585 --> 00:18:02,345 deeper to this. Once they feel it is ready, then they'll estimate it, and 290 00:18:02,345 --> 00:18:06,025 that's where we hope the estimate's pretty low. 1, 2, 3, 5 291 00:18:06,025 --> 00:18:09,770 points. Anything bigger than that, and it's still a feature. It 292 00:18:09,770 --> 00:18:13,390 probably needs to get split again. So we try and, you know, 293 00:18:13,530 --> 00:18:17,325 figure out what what kind of size it is. And once everybody's happy, all 294 00:18:17,325 --> 00:18:21,165 the developers are comfortable. They know enough about it to estimate it. Doesn't have to 295 00:18:21,165 --> 00:18:24,950 be 100% perfect. You might not have every answer to every question to 296 00:18:24,950 --> 00:18:28,630 that stage, but we know enough to estimate it. Yep. And it's ready to take 297 00:18:28,630 --> 00:18:32,265 into a sprint. So we update the status. And When 298 00:18:32,265 --> 00:18:35,945 we're doing sprint planning, we can look at all the product backlog items that are 299 00:18:35,945 --> 00:18:39,304 in that ready status, and we can consider bringing those into into the sprint 300 00:18:39,304 --> 00:18:42,890 backlog. Something similar, I think. Yeah. Yeah. Something 301 00:18:42,890 --> 00:18:46,650 similar. I think is that true yeah. Yeah. Okay. And 302 00:18:46,650 --> 00:18:50,445 you don't estimate the analysis time. You don't estimate? No. Because this 303 00:18:50,445 --> 00:18:53,885 is what sometimes we do here I mean, I'm doing 304 00:18:53,885 --> 00:18:57,565 is okay. For the sprint, because maybe it's a big 305 00:18:57,565 --> 00:19:01,340 analysis task. Right? A lot of it's for the screen. We 306 00:19:01,340 --> 00:19:04,720 kind of put a u some user stories against 307 00:19:04,940 --> 00:19:08,665 the analysis. Sorry. We put the story points against 308 00:19:08,665 --> 00:19:12,265 the analysis time, which helps us a bit 309 00:19:12,265 --> 00:19:15,940 estimating the capacity for Okay. 310 00:19:15,940 --> 00:19:19,320 That's that's where so this is where I have my user story 311 00:19:20,100 --> 00:19:23,940 with a lot of details in there, but I still need 312 00:19:23,940 --> 00:19:27,645 to do quite some analysis. Is not ready for dev, then we would kind 313 00:19:27,645 --> 00:19:31,405 of consider this as the analysis user story, put some story points 314 00:19:31,405 --> 00:19:35,240 so that we can kind of, You know, estimate the capacity, and then 315 00:19:35,240 --> 00:19:39,000 from there, we would probably create additional user stories. I don't know 316 00:19:39,000 --> 00:19:42,695 if that's the best way to do it. But Yeah. I I 317 00:19:42,695 --> 00:19:46,295 I encourage my teams only to estimate the work that's gonna 318 00:19:46,295 --> 00:19:49,970 generate a product that the product owner has asked for. So, 319 00:19:50,049 --> 00:19:53,090 Yep. Typically, it's it's some working software. Right? I want I need this this button 320 00:19:53,090 --> 00:19:56,289 or this feature or this workflow, whatever it is. Or it could be, I need 321 00:19:56,289 --> 00:19:59,945 this document. I need to use a guide or I need a, yeah, as 322 00:19:59,945 --> 00:20:03,705 is system description, you know, whatever the, the artifact is. 323 00:20:03,705 --> 00:20:07,549 So we estimate all of that work There then there's work that the dev 324 00:20:07,549 --> 00:20:10,830 team needs to do to get things done. Right? I need to stand up a 325 00:20:10,830 --> 00:20:14,565 new environment. I need to do some analysis on a user story. I need to, 326 00:20:15,345 --> 00:20:19,185 spend some time upskilling Danny. He's gonna I'm gonna train him in 327 00:20:19,185 --> 00:20:22,470 all the data migration, jobs that we've got running. Yeah. 328 00:20:22,870 --> 00:20:26,710 That work, we don't estimate because it doesn't drive 329 00:20:26,710 --> 00:20:30,365 functionality for the end users. It's not something they care about. And so, 330 00:20:30,365 --> 00:20:33,005 yeah, if we have to do a lot of that work, the team will just 331 00:20:33,005 --> 00:20:36,525 say, Hey, look, we normally get, you know, 50 story points per sprint 332 00:20:36,525 --> 00:20:40,110 done, but we've got all these chores to do. Gonna reduce our 333 00:20:40,110 --> 00:20:43,790 capacity to 40 because we have more chores than usual. There's always 334 00:20:44,030 --> 00:20:47,655 Yeah. There's always, work the team needs to do that the product 335 00:20:48,055 --> 00:20:51,755 might not necessarily consider valuable, and so we we call those chores, 336 00:20:52,375 --> 00:20:56,030 and everything else is a is a story. Yeah. Okay. 337 00:20:56,030 --> 00:20:59,010 Cool. Yeah. So it's, sounds pretty similar. 338 00:21:00,350 --> 00:21:03,970 Tell me about the type of acceptance criteria that you're writing 339 00:21:04,225 --> 00:21:07,765 On a product backlog, I'm gonna use your story. Yeah. 340 00:21:07,985 --> 00:21:11,605 So look, I wouldn't draw I mean, I would encourage 341 00:21:12,360 --> 00:21:15,820 BA to help me write or write the the acceptance criteria 342 00:21:16,120 --> 00:21:19,685 most of the time. But then 343 00:21:19,805 --> 00:21:23,645 because I would prefer them to be written from kind of a business lens more, 344 00:21:23,645 --> 00:21:27,485 you know, so and and I strive to follow the 345 00:21:27,485 --> 00:21:31,260 best I can, some some exam 346 00:21:31,419 --> 00:21:35,100 I mean, a consistent way of writing those acceptance criteria that I've learned from 347 00:21:35,100 --> 00:21:38,785 other good BAs before I've worked. Right? So I'm not Claiming it's mine, 348 00:21:38,785 --> 00:21:42,385 but, you know, kind of giving the scenarios, like, even that 349 00:21:42,385 --> 00:21:46,220 scenarios, if this happened then and it kind of And 350 00:21:46,220 --> 00:21:49,420 it's kind of a nice way if I have a few scenarios even as a 351 00:21:49,420 --> 00:21:52,880 as a dev or an architect when I go through this. It's kind of 352 00:21:53,304 --> 00:21:57,145 Making me empathize with the scenario I need to think about 353 00:21:57,145 --> 00:22:00,525 when I'm designing the system. It helps me even kind of writing 354 00:22:00,780 --> 00:22:04,380 scenarios later. And even if I'm doing my own unit testing, it tells me go 355 00:22:04,380 --> 00:22:08,140 through this. Am I meeting the acceptance criteria? So this is what I 356 00:22:08,140 --> 00:22:11,934 would strongly recommend doing, And I would 357 00:22:11,934 --> 00:22:15,775 have to write them. Sometimes I'm I'm writing them because, well, for whatever reason, I'm 358 00:22:15,775 --> 00:22:19,510 the only one on the project or The b there isn't a really a a 359 00:22:19,510 --> 00:22:23,210 real BA on the project helping me, but, otherwise, I would strongly recommend 360 00:22:23,590 --> 00:22:27,130 the business or the BA to really write them that way. 361 00:22:27,455 --> 00:22:31,215 Yep. Makes sense. Are you reading the same? Yeah. Same. So we 362 00:22:31,215 --> 00:22:34,995 call it behavior driven development, BDD, given, when, then, 363 00:22:35,159 --> 00:22:38,600 And we we use that that structure, and that's how we write the 364 00:22:38,600 --> 00:22:41,980 acceptance, acceptance criteria. 365 00:22:43,135 --> 00:22:46,914 Our testers can really easily turn those into test cases. 366 00:22:47,135 --> 00:22:50,700 What we find though, is, You know, as you begin to 367 00:22:50,700 --> 00:22:54,540 enrich your user story with those acceptance criteria, if you 368 00:22:54,540 --> 00:22:57,280 uncover quite a lot of them, that could really 369 00:22:58,015 --> 00:23:01,695 Highlight that this story is way more complicated than we initially thought. Yeah. We might 370 00:23:01,695 --> 00:23:05,215 need to revise the estimate. Normally, we've done all the acceptance criteria before 371 00:23:05,215 --> 00:23:08,840 estimation. But if you see a a user's degree with 372 00:23:08,840 --> 00:23:12,279 2 or 3 acceptance criteria, well, that's okay. If you see 1 with 7 or 373 00:23:12,279 --> 00:23:16,004 8, 10 acceptance criteria, like, oh, wow. You know, I need to create a contact. 374 00:23:16,004 --> 00:23:18,565 If the contact is this type or that type or the other type or if 375 00:23:18,565 --> 00:23:21,924 it's Tuesday or if it if it's every other Thursday or if the weather is 376 00:23:21,924 --> 00:23:25,610 wet, you know, all these Strange scenarios that come up 377 00:23:25,610 --> 00:23:29,290 whenever you wanna just create a contact. That shows you you might need to split 378 00:23:29,290 --> 00:23:32,934 your user story. So really really good way of, iterating 379 00:23:33,075 --> 00:23:35,495 to get to the, you know, this this is ready. 380 00:23:36,595 --> 00:23:40,419 Yep. Yep. Yep. Yep. Yep. Absolutely. Do you document anything? So that's 381 00:23:40,419 --> 00:23:44,259 maybe another question I'll have for you. So where would 382 00:23:44,259 --> 00:23:47,720 you document some of your design ideas? Do you document them 383 00:23:48,115 --> 00:23:51,955 In the user story somewhere or in separate documents and you link it 384 00:23:51,955 --> 00:23:55,715 or somewhere else completely, where do you have that? We try and keep 385 00:23:55,715 --> 00:23:59,380 it Really lightweight. So quite often, it'll just be a comment 386 00:23:59,600 --> 00:24:03,440 in Azure DevOps. So Yeah. When we're when we're estimating, the 387 00:24:03,440 --> 00:24:06,965 developers will say, well, we're estimating this on the basis that We think, 388 00:24:07,505 --> 00:24:11,044 we can solve this with a custom table, 2 flows 389 00:24:11,585 --> 00:24:15,129 and, a form. Right? And 390 00:24:15,129 --> 00:24:17,950 so it that's the that's the kind of design idea. 391 00:24:18,570 --> 00:24:22,174 Yep. That's good enough for estimating. Then 392 00:24:22,174 --> 00:24:25,794 once the sprint starts, we 393 00:24:26,335 --> 00:24:30,014 have normally 3 people, working in a team on a user 394 00:24:30,014 --> 00:24:33,679 story, at least 3 people. There's the analyst who's maybe done the refinement who knows 395 00:24:33,679 --> 00:24:36,559 it best. That could be the product owner. It could be a subject matter expert 396 00:24:36,559 --> 00:24:40,019 or one of the developers who's a business analyst. Plus 397 00:24:40,455 --> 00:24:44,215 The developer who's gonna build most of the functionality, and 398 00:24:44,215 --> 00:24:47,655 it might be a couple because it might be a professional developer and a maker. 399 00:24:47,655 --> 00:24:51,290 Yep. So there might be a couple of developer developers. And then 400 00:24:51,350 --> 00:24:55,030 we have another developer, because in scrum, everybody's a developer. But 401 00:24:55,030 --> 00:24:58,794 this is a, a tester. Right? Somebody with a professional 402 00:24:58,855 --> 00:25:02,615 qual quality assurance background, and they are gonna test it. So the we call 403 00:25:02,615 --> 00:25:05,195 it the 3 amigos, and they have a quick meeting, 404 00:25:06,290 --> 00:25:09,650 when they're ready to pick up this product backlog or sprint backlog 405 00:25:09,650 --> 00:25:13,305 item, and they say, right, have we confirmed we got everything? We still think it's 406 00:25:13,305 --> 00:25:17,065 ready. That design, it still looks appropriate. Yes. Have we learned anything new? No. It's 407 00:25:17,065 --> 00:25:20,105 all good. Let's let's get started. And then they come up with a little plan 408 00:25:20,105 --> 00:25:23,580 that says, alright. It's Tuesday. The sprint ends, 409 00:25:24,220 --> 00:25:27,920 at 2 weeks from today. So I'm going to try and have it built. 410 00:25:28,060 --> 00:25:31,565 I'm gonna do a quick demo with a product owner on Friday, then it's gonna 411 00:25:31,565 --> 00:25:34,865 be ready for testing. When do you think that, how long are you gonna be 412 00:25:35,005 --> 00:25:37,805 take to test all that? I can get the test done on Monday evening. Okay. 413 00:25:37,805 --> 00:25:41,590 What's gonna be done By Tuesday, halfway through the sprint. Great. 414 00:25:42,210 --> 00:25:45,810 And so, yeah, the the 3 of them in those 3 amigos session, well, just 415 00:25:45,810 --> 00:25:49,515 a good a good sanity check everybody's ready to start work. Yeah. Off 416 00:25:49,515 --> 00:25:53,195 we go. Yeah. Yeah. Yeah. Yeah. Yeah. Cool. Yep. Perfect. Thank you for 417 00:25:53,195 --> 00:25:56,940 that. Yeah. Are you are you doing it differently whenever Whenever you're ready to go 418 00:25:56,940 --> 00:26:00,140 and start work on it or or capturing your design ideas, how much design are 419 00:26:00,140 --> 00:26:03,740 you doing up front? No. It's it's very, actually, very similar, I 420 00:26:03,740 --> 00:26:07,445 think, to what to what you do, I think, in your team is just some 421 00:26:07,445 --> 00:26:10,804 high level concepts. Right? So, basically, I would if I 422 00:26:10,804 --> 00:26:14,299 have Access to making changes to DevOps or ask the client to make 423 00:26:14,299 --> 00:26:17,840 changes to DevOps. I would recommend I myself try to have 424 00:26:18,059 --> 00:26:21,519 an additional box with design ideas in there 425 00:26:21,725 --> 00:26:25,404 Where instead of having and and then having them probably to the 426 00:26:25,404 --> 00:26:28,580 same level as as you at the beginning is, what 427 00:26:29,059 --> 00:26:32,659 Kind of automation or workflow do you wanna use? Flow, this, 428 00:26:32,659 --> 00:26:36,200 that. What kind of tables do we thinking? Just because when we 429 00:26:36,419 --> 00:26:40,085 discussing, we have some ideas. We We just want to capture them so that it's 430 00:26:40,085 --> 00:26:43,705 not forgotten when we start working on this. Right? So we capture them then, 431 00:26:43,924 --> 00:26:47,630 and then as we go through The user 432 00:26:47,630 --> 00:26:51,230 story, if I would work on the user story, I would 433 00:26:51,230 --> 00:26:54,955 often have maybe a small diagram Next 434 00:26:54,955 --> 00:26:58,555 to it or a small presentation or as an empty 435 00:26:58,555 --> 00:27:02,315 diagram or whatever, then I would document. I will store them as 436 00:27:02,315 --> 00:27:05,770 attach not in the box. Don't know that that at the touchpoint in DevOps 437 00:27:06,310 --> 00:27:09,830 in a specific SharePoint location that we have linked to Azure 438 00:27:09,830 --> 00:27:13,655 DevOps, and then we link Document will link URL, 439 00:27:13,655 --> 00:27:17,015 so we point to those URLs. So, basically, I would say, you 440 00:27:17,015 --> 00:27:20,855 know, design ideas would be this, this, that table, and then that 441 00:27:20,855 --> 00:27:24,390 portal to me and this and that, and then entity diagram, and 442 00:27:24,390 --> 00:27:27,830 then no hyperlink to Perfect. An entity 443 00:27:27,830 --> 00:27:31,565 diagram or or a conceptual diagram or something. Right? And 444 00:27:31,565 --> 00:27:35,245 this is stored then in a linked SharePoint folder to that users 445 00:27:35,405 --> 00:27:39,250 to that user story effectively in that case. So this is basically how, 446 00:27:39,630 --> 00:27:43,470 you and then that folder in SharePoint, I'm actually 447 00:27:43,470 --> 00:27:47,054 working with another with another client where they have a bit 448 00:27:47,054 --> 00:27:50,735 more structure in those folders as well. So for example, if, 449 00:27:51,375 --> 00:27:54,960 documentation is stored there as well. So for you a user story feed, a 450 00:27:55,200 --> 00:27:58,960 documentation is required. We would store that documentation there with a specific 451 00:27:58,960 --> 00:28:02,480 subfolder of that folder of that DevOps 452 00:28:02,480 --> 00:28:06,275 item. Yeah. Good. Okay. Yeah. Yeah. Do do 453 00:28:06,275 --> 00:28:10,115 you have to do much of a design document before the project 454 00:28:10,115 --> 00:28:13,960 gets started? Do you find, maybe a enterprise architecture 455 00:28:13,960 --> 00:28:17,340 team or solution architecture team requires you to do some kind of upfront 456 00:28:17,880 --> 00:28:21,385 design documentation that they have to approve Before you get 457 00:28:21,385 --> 00:28:25,225 started, I know Microsoft Fast Track, for example, is pretty 458 00:28:25,225 --> 00:28:28,525 keen for Microsoft partners to create the solution 459 00:28:28,585 --> 00:28:32,410 blueprint document Yeah. Which is It's not even a it's 460 00:28:32,410 --> 00:28:36,250 not even a solution architecture, but it's, covers all the big topics, like how 461 00:28:36,250 --> 00:28:40,030 we're gonna do data migration, how we're gonna do integration, and addresses, 462 00:28:40,815 --> 00:28:43,875 Probably the top 12, 15 things you need to consider. 463 00:28:44,575 --> 00:28:48,255 Those are really good documents, I think, to create. Long as they're reasonably 464 00:28:48,255 --> 00:28:51,900 lightweight, And we're not bound by them, or we can negotiate them 465 00:28:51,900 --> 00:28:55,280 later. Do you find yourself doing a lot of that with bigger customers? 466 00:28:56,245 --> 00:28:59,765 Yeah. Actually, I'm doing quite quite a lot of this kind of work, right, which 467 00:28:59,765 --> 00:29:03,205 is kind of kind of between discovery and, 468 00:29:03,525 --> 00:29:07,030 envisioning and and kind of one of the output that I that I 469 00:29:07,030 --> 00:29:10,570 use is is a solution blueprint, which has very similar, 470 00:29:11,270 --> 00:29:14,710 you know, subsections as what is in the Fast Track, 471 00:29:14,710 --> 00:29:18,255 right, which is effectively it's kind of the the 472 00:29:18,255 --> 00:29:21,855 question you need to ask. You you need you need a high 473 00:29:21,855 --> 00:29:25,409 level approach for each of those topics before you you start. 474 00:29:25,409 --> 00:29:29,110 Right? The Yeah. It's essential question you wanna ask that you wanna have documented 475 00:29:29,250 --> 00:29:32,885 in a high level way kind of And kind of have 476 00:29:32,885 --> 00:29:36,405 your I use often like those 477 00:29:36,405 --> 00:29:40,185 conceptual diagrams, a bit of an high level architecture diagram, 478 00:29:40,610 --> 00:29:44,290 And then integration with maybe an integration diagram high 479 00:29:44,290 --> 00:29:47,030 level, what are the concept or the system, 480 00:29:47,705 --> 00:29:51,545 What what what are the direction of the integration or so 481 00:29:51,545 --> 00:29:54,920 that we at least have a had a discussion doing that, you know, 482 00:29:55,320 --> 00:29:59,080 discovery or project envisioning, whatever you call it. We had a discussion 483 00:29:59,080 --> 00:30:01,820 about those topics, and we have an idea 484 00:30:03,575 --> 00:30:07,015 To also kind of provide a bit of an estimate when you're going to do 485 00:30:07,015 --> 00:30:10,555 the roadmap on the whole thing, but an idea of how we're going to approach 486 00:30:11,300 --> 00:30:14,680 So that there is no big surprises halfway through the project 487 00:30:14,980 --> 00:30:18,820 that we suddenly cannot integrate with the system, and that 488 00:30:18,820 --> 00:30:22,465 integration is effectively deal breaker or whatever. Right? We 489 00:30:22,465 --> 00:30:25,125 don't wanna have we wanna limit the number of surprises. 490 00:30:26,225 --> 00:30:29,904 That's that's really the key of that, I think, that that solution blueprint that that 491 00:30:29,904 --> 00:30:33,649 project is that you wanna limit the risk and the surprises down the project. You 492 00:30:33,649 --> 00:30:37,250 will always have some, but you wanna limit them and at least 493 00:30:37,250 --> 00:30:41,085 address the biggest one. Alright. That sounds very similar to what I'm doing. I I 494 00:30:41,085 --> 00:30:44,065 know I've had to take it a step further when I'm working with 495 00:30:44,924 --> 00:30:48,385 regulated organizations where there's a very mature enterprise architecture. 496 00:30:49,150 --> 00:30:51,390 And I try not to do it all upfront, but I give them the high 497 00:30:51,390 --> 00:30:55,150 level picture just to begin with. And as the project proceeds, we'll go deeper 498 00:30:55,150 --> 00:30:58,485 into a topic. Like, we're gonna do an integration with this 499 00:30:58,965 --> 00:31:02,725 Existing system. Here's our design pattern for for that 500 00:31:02,725 --> 00:31:05,980 integration. We're gonna use Boomi or we're gonna use MuleSoft or 501 00:31:06,140 --> 00:31:09,980 use, Azure functions and and logic apps, get that kind of 502 00:31:09,980 --> 00:31:13,820 approval. And I think that they like to have some oversight of those 503 00:31:13,820 --> 00:31:17,535 patterns because, You know, they want us to reuse existing patterns where we 504 00:31:17,535 --> 00:31:21,295 can or, at least stick within the bonds of what they can support 505 00:31:21,295 --> 00:31:25,039 later. So Yeah. Yeah. A little bit of upfront design. Never 506 00:31:25,039 --> 00:31:28,400 heard anybody. I just try not to get everything, you know, set in concrete before 507 00:31:28,400 --> 00:31:32,000 we start. Absolutely. Yeah. Because things change so fast and quickly that 508 00:31:32,250 --> 00:31:36,035 yeah. What are some of the challenges your your you or your customers 509 00:31:36,035 --> 00:31:39,395 have faced recently when it comes to managing a backlog? Anything that that's really 510 00:31:40,050 --> 00:31:43,490 You know, people are grinding their teeth about that, you 511 00:31:43,490 --> 00:31:46,470 can you can help us solve and avoid. 512 00:31:48,524 --> 00:31:52,144 Look. I have seen so I think a structure 513 00:31:52,524 --> 00:31:54,865 like I said, a structure and and and 514 00:31:56,120 --> 00:31:59,960 Managing a product backlog itself requires a 515 00:31:59,960 --> 00:32:03,799 bit of, I think, of experience and and kind of you had you had 516 00:32:03,799 --> 00:32:07,544 to done it in in the past to kind of be familiar with it. Right? 517 00:32:07,544 --> 00:32:11,225 And I and clients that haven't done it using a tool like 518 00:32:11,225 --> 00:32:15,039 DevOps or Jira Would manage your product backlog, you know, in 519 00:32:15,039 --> 00:32:18,020 Excel, I've seen those scenario whose where, 520 00:32:19,280 --> 00:32:22,735 you know, you you you jump into or you start a project And 521 00:32:22,735 --> 00:32:26,115 then the client opens, you know, a spreadsheet 522 00:32:27,375 --> 00:32:30,975 full of requirements and columns with statuses and 523 00:32:31,135 --> 00:32:34,799 Yeah. And the filters stop broking, and then, you know, the next day, 524 00:32:34,799 --> 00:32:38,559 they open the spreadsheet and it doesn't load because there's so many things. I have 525 00:32:38,559 --> 00:32:42,345 seen those scenarios. Right? And I've I've been in those meetings where it's 526 00:32:42,345 --> 00:32:46,185 challenging even to go through the requirements and follow the statuses. 527 00:32:46,185 --> 00:32:49,565 Right? So I think the 2 here and and how you manage it 528 00:32:50,170 --> 00:32:53,930 also plays a big role. And when I see that, I I strongly 529 00:32:53,930 --> 00:32:57,770 recommend my client to take a look at that 530 00:32:57,770 --> 00:33:00,815 other tool that is made for that, right, and Kind of 531 00:33:01,435 --> 00:33:05,195 help them converting whatever they have somewhere else, whether 532 00:33:05,195 --> 00:33:08,400 it's spreadsheets or word document or Yep. 533 00:33:08,640 --> 00:33:12,400 Into a tool like DevOps. So that's one of the challenge I have 534 00:33:12,400 --> 00:33:16,075 seen. When you are in DevOps, I guess, Like we 535 00:33:16,075 --> 00:33:19,835 discussed at the beginning, right, is that adoption of the tool that will take a 536 00:33:19,835 --> 00:33:23,570 bit of time. Yep. I think I think the 537 00:33:23,570 --> 00:33:27,350 advice would be is just you you you just need to allow 538 00:33:27,570 --> 00:33:31,054 your client time to To 539 00:33:31,054 --> 00:33:34,895 onboard and get familiar with it. Right? It just takes 540 00:33:34,895 --> 00:33:38,735 time, but it happens. Like, if you actively engage them, if you everyday 541 00:33:38,735 --> 00:33:42,169 open DevOps or if you Work in DevOps. You tag them in 542 00:33:42,169 --> 00:33:45,929 DevOps, in comments. They kind of forced after 543 00:33:45,929 --> 00:33:49,309 some time to kind of capture their thoughts and the details there. 544 00:33:49,605 --> 00:33:53,284 And after a bit of time, everybody's using it. And then 2 months from now, 545 00:33:53,284 --> 00:33:57,060 suddenly the plan is using it and and really driving it as well. 546 00:33:57,140 --> 00:34:00,340 Yes. And that's kind of a a success. Right? So I think this this is 547 00:34:00,340 --> 00:34:03,320 also a challenge. Just give time for 548 00:34:04,420 --> 00:34:08,155 the organization to adopt it and And use it because 549 00:34:08,155 --> 00:34:11,034 maybe at the beginning, they won't like it or they don't wanna use it and 550 00:34:11,114 --> 00:34:14,574 so step by step. And then after a few weeks, a few months, 551 00:34:14,770 --> 00:34:17,349 I've seen that they really start using it. Yeah. 552 00:34:18,530 --> 00:34:22,215 Those would be the 2 ones, to be fair. Yeah. Okay. One 553 00:34:22,375 --> 00:34:24,775 1 1 final question for you, Danny. And then Yeah. If you've got a few 554 00:34:24,775 --> 00:34:27,015 minutes, I'd love to do a little bit of a retrospective with you. We can 555 00:34:27,015 --> 00:34:30,650 get to know you a bit better, what you've been up to recently. Where do 556 00:34:30,650 --> 00:34:34,190 you stand on deleting product backlog items? 557 00:34:34,570 --> 00:34:37,790 Like, I don't delete. Okay. Sorry. Go ahead. 558 00:34:38,705 --> 00:34:42,545 So Ryan Ripley, he's a professional scrum trainer from Agile for Humans. He 559 00:34:42,545 --> 00:34:46,225 is big on deleting, pruning Yeah. Your product 560 00:34:46,225 --> 00:34:49,900 backlog item to be as small as Really realistically possible, and 561 00:34:49,900 --> 00:34:53,660 that includes hard deleting, you know, tearing up Yeah. Getting 562 00:34:53,660 --> 00:34:57,255 rid of items that are never gonna get delivered. He, I don't know, wanted he 563 00:34:57,255 --> 00:35:00,635 tells a story about he was at a conference, and he had to stay standing 564 00:35:01,175 --> 00:35:04,640 until he called out the you know, how old is your product? Oldest product backlog 565 00:35:04,640 --> 00:35:08,319 item. Yeah. And the 1 guy remains standing the longest. Had a 9 year 566 00:35:08,319 --> 00:35:12,160 old product backlog item, you know, had been at the bottom of the 567 00:35:12,160 --> 00:35:15,985 product backlog for 9 years. And Ryan said, just delete it. It's 568 00:35:15,985 --> 00:35:19,025 never gonna get delivered. If it has hasn't been important to anybody in the last 569 00:35:19,025 --> 00:35:22,740 9 years, it's never gonna get done. So Yeah. I don't 570 00:35:22,740 --> 00:35:26,340 know. You don't like deleting? Well, if I make a mistake, 571 00:35:26,340 --> 00:35:29,619 yeah, if I make a mistake, I create, you know, I, of course, I will 572 00:35:29,619 --> 00:35:33,415 delete it, but otherwise Well, you have the removed state, so I 573 00:35:33,415 --> 00:35:37,175 usually don't if someone had an idea somewhere at some point, maybe 574 00:35:37,175 --> 00:35:40,990 it made sense. So I would I would change the status to removed 575 00:35:40,990 --> 00:35:44,510 from the product backup, which is that soft delete. Yep. Inactive in 576 00:35:44,510 --> 00:35:48,265 Dynamics with the reason, We try to always try to add a reason in 577 00:35:48,265 --> 00:35:51,464 the comment removed because it has been merged with this one or Right. 578 00:35:51,625 --> 00:35:55,319 Whatever whatever the reason, it goes out of of the 579 00:35:55,319 --> 00:35:58,920 listing. It goes out. You can but you can always find it and find the 580 00:35:58,920 --> 00:36:02,140 reasoning why. Yeah. I don't know. 581 00:36:03,425 --> 00:36:07,185 I agree. Maybe I yeah. And maybe after, yeah, maybe after 582 00:36:07,185 --> 00:36:10,960 5 years, if you look at your history and But why would you? 583 00:36:10,960 --> 00:36:14,480 I mean, it's there. It's invisible. Yeah. It doesn't 584 00:36:14,480 --> 00:36:18,000 it doesn't bother me. I think it could be really nice if, you know, if 585 00:36:18,000 --> 00:36:21,355 you come up to me 3 years into the project or after we're going live 586 00:36:21,355 --> 00:36:25,195 and tell me, whatever happened to my idea, I had suggested this thing, or my 587 00:36:25,195 --> 00:36:28,395 boss suggested this thing, and we can go and trace it back and say, yes. 588 00:36:28,395 --> 00:36:31,920 Look. It was in here. It was discussed by the product owner. Yeah. She 589 00:36:31,920 --> 00:36:35,600 she deprioritized it. She she conferred with your boss, and they agreed it 590 00:36:35,600 --> 00:36:38,545 wasn't, worth spending a lot of time and money on. 591 00:36:39,424 --> 00:36:42,984 And that saves us creating a new item to to go with 592 00:36:43,105 --> 00:36:46,700 do the same kind of evaluation all over again, If we can go and 593 00:36:46,700 --> 00:36:50,220 find that old old item. So I, I really like it. Yeah. And yeah, I 594 00:36:50,220 --> 00:36:54,060 wouldn't, I wouldn't encourage people to delete stuff if there's an convenient way 595 00:36:54,060 --> 00:36:57,525 of hiding things And keeping the mode of, out of harm's 596 00:36:57,525 --> 00:37:01,365 way. Yeah. Cool. Yeah. Yeah. Yeah. I have 1 question for you, though, 597 00:37:01,365 --> 00:37:05,200 if possible. So I know and then you I think you commented on 598 00:37:05,200 --> 00:37:08,880 on someone's LinkedIn post somewhere, mine or maybe someone 599 00:37:08,880 --> 00:37:12,655 else, That and you you had a a way of writing 600 00:37:12,655 --> 00:37:15,235 user stories in a reverse 601 00:37:16,495 --> 00:37:20,160 Yeah. Format, not starting with as a actor. I do. You were 602 00:37:20,160 --> 00:37:23,359 writing it differently. Can you can you tell me 603 00:37:24,480 --> 00:37:28,285 remind me how you do it and why? Yeah. So the A very 604 00:37:28,285 --> 00:37:31,724 common user story template is, as a 605 00:37:31,724 --> 00:37:35,505 actor, I can Yep. Do something so that I get some value. 606 00:37:35,960 --> 00:37:39,720 First of all, I don't think having the actor, enumerated in the 607 00:37:39,720 --> 00:37:43,400 user story is helpful. Quite often, we have lots of different 608 00:37:43,400 --> 00:37:46,934 types of users who can use a feature. Right? I don't wanna say Yeah. As 609 00:37:46,934 --> 00:37:50,295 a customer services user or as a sales user or as a marketing user or 610 00:37:50,295 --> 00:37:53,674 as an operations manager, I can so that. It's just 611 00:37:53,869 --> 00:37:57,550 Hard to read. Yep. Instead, I just dropped that bit off. I 612 00:37:57,550 --> 00:38:01,335 dropped the actor and say, so that So 613 00:38:01,335 --> 00:38:04,955 I start with the value statement at the at the beginning so that we can 614 00:38:05,335 --> 00:38:09,095 enhance our customer experience. I can merge 615 00:38:09,095 --> 00:38:12,900 customer records together. And then what I do 616 00:38:12,900 --> 00:38:16,500 is I use the tagging feature in Azure DevOps to 617 00:38:16,500 --> 00:38:20,234 tag which roles can use this feature, right? Or you'll be targeting 618 00:38:20,234 --> 00:38:23,914 really with it. And so if I ever wanna say, should we all these features 619 00:38:23,914 --> 00:38:26,894 we built for sales analysts or finance, 620 00:38:27,900 --> 00:38:31,500 analysts. I can quickly search your filter on the 621 00:38:31,500 --> 00:38:35,040 tag and all the user stories that we're building for the those people 622 00:38:35,260 --> 00:38:38,735 show up on the list. Yeah. And it's a much easier way of 623 00:38:38,735 --> 00:38:42,335 organizing, by by persona or stakeholder or user 624 00:38:42,335 --> 00:38:46,119 role, what we're building for. And the value statement at 625 00:38:46,119 --> 00:38:49,420 the start just reinforces the fact that we 626 00:38:49,880 --> 00:38:53,595 need to focus on creating valuable Functionality. 627 00:38:54,214 --> 00:38:57,974 And if you can't describe the value, then is it 628 00:38:57,974 --> 00:39:01,700 really worth doing the work? Sometimes you just have to do the work. Yeah. Focus 629 00:39:01,700 --> 00:39:04,520 on the Yeah. Yeah. Yeah. Yeah. Yeah. 630 00:39:05,220 --> 00:39:08,359 Yeah. If I may just ask then on this one. So 631 00:39:09,005 --> 00:39:12,445 This assume that you deliver that user story in kind of the 632 00:39:12,445 --> 00:39:16,065 same time frame more or less. Right? Or 633 00:39:17,190 --> 00:39:20,790 What would you do if the sales team needs that user 634 00:39:20,790 --> 00:39:24,390 story right now or did that feature right now and then the customer 635 00:39:24,390 --> 00:39:28,225 service needed in In 2 months' time, like, would you split the user 636 00:39:28,225 --> 00:39:31,905 story, or what would you No. I'd I'd try not to. 637 00:39:31,905 --> 00:39:35,285 So, yeah, it's always a good a good analysis question to ask is, 638 00:39:35,539 --> 00:39:38,740 Who's gonna use this feature? And the product owner says, oh, the the sales team. 639 00:39:38,740 --> 00:39:41,480 Great. Okay. We're good. Yeah. As a sales user, I can. 640 00:39:42,099 --> 00:39:45,240 But a good question to ask is anybody else? 641 00:39:45,575 --> 00:39:49,335 Yeah. Are there other teams who could Yeah. Get value from 642 00:39:49,335 --> 00:39:53,095 this functionality if we delivered it? And oh, yeah. Well, the customer service 643 00:39:53,095 --> 00:39:55,720 team might occasionally need to do it, but not as often. Yep. So The real 644 00:39:55,720 --> 00:39:59,420 priority is for the sales team. Okay. Well, I'll just tag customer service, 645 00:39:59,960 --> 00:40:03,020 as a persona on this user story. So I'll try and build it once. 646 00:40:03,915 --> 00:40:07,355 You might need to have a 2nd user story Mhmm. 647 00:40:07,755 --> 00:40:11,595 Because we forgot. We forgot the customer service needed this functionality as well. Mhmm. 648 00:40:11,595 --> 00:40:14,690 And the way that we built it 1st time was we only 649 00:40:15,150 --> 00:40:18,590 enable this, you know, through security rules. We only enabled it for the 650 00:40:18,590 --> 00:40:21,970 sales users. And so we have a 2nd user story 651 00:40:22,315 --> 00:40:26,155 Just focused on customer service because we need to add the security privileges 652 00:40:26,155 --> 00:40:29,675 to their security role. So Yep. I try not to do it 653 00:40:29,675 --> 00:40:33,490 twice. Yeah. Yeah. Yeah. Cool. So it's a it's a more of case by 654 00:40:33,490 --> 00:40:37,250 case, again, scenario that yeah. Yeah. I would 655 00:40:37,250 --> 00:40:40,875 have 2 user stories only if I forgot to ask Upfront the 656 00:40:40,875 --> 00:40:44,555 first time. Who who else could benefit from this functionality? Yeah. Yeah. 657 00:40:44,555 --> 00:40:48,234 Well, it's often the case, like, I'm having a situation now where kind of 658 00:40:48,234 --> 00:40:51,990 very similar requirements or feature being delivered, 659 00:40:52,690 --> 00:40:56,529 but so the product owner is liaising us with business with different 660 00:40:56,529 --> 00:41:00,155 business areas. Mhmm. And then 1 business area is very 661 00:41:00,155 --> 00:41:03,595 keen on having it. So we we have all the requirements for them, and we're 662 00:41:03,595 --> 00:41:07,160 ready, and then we deliver that now. Right. The other 663 00:41:07,160 --> 00:41:10,920 business area is a bit more busy or they there are requirements for 664 00:41:10,920 --> 00:41:14,760 them and tell. Basically, they take a bit more time to 665 00:41:14,760 --> 00:41:18,265 providing us the details. So That feature for them with the 666 00:41:18,265 --> 00:41:22,105 details for them, maybe what kind of let's 667 00:41:22,105 --> 00:41:25,779 say connection roles. Add connection roles, that kind of roles they wanna have or 668 00:41:25,779 --> 00:41:29,619 something comes a few sprints later. In that case, I would have 669 00:41:29,619 --> 00:41:33,275 2 user stories Because one, I wanna push 670 00:41:33,275 --> 00:41:37,115 the first one I wanna push Yes. Through the cycle and deliver, and then the 671 00:41:37,115 --> 00:41:40,095 other one which is very similar for another user 672 00:41:41,060 --> 00:41:44,820 Group, I would push it later. Yeah. Oh, absolutely. You're 673 00:41:44,820 --> 00:41:48,234 all yes. You're always gonna have, Those 674 00:41:48,234 --> 00:41:52,075 enhancement user stories that enhance an earlier released feature. For 675 00:41:52,075 --> 00:41:55,115 whatever reason, great idea. You wanna get the Yep. You wanna get the value out 676 00:41:55,115 --> 00:41:58,880 there as quickly as you can and as earlier releases you can. And if 677 00:41:58,880 --> 00:42:02,500 somebody else wants to increment or iterate on that functionality later, 678 00:42:02,640 --> 00:42:05,680 some kind of enhancement, maybe maybe just roll it out to a different group of 679 00:42:05,680 --> 00:42:09,465 users or a different business unit. Yeah. It's fine. Up yeah. Do that 680 00:42:09,465 --> 00:42:13,065 all the time. Cool. Have you got a couple of seconds you can stay on 681 00:42:13,065 --> 00:42:16,089 and and let me know How to how to reach you, how to find you, 682 00:42:16,089 --> 00:42:19,230 and what you're up to recently. So, I like to call this the retrospective, 683 00:42:19,849 --> 00:42:23,525 segment in the in the podcast. So for those who don't know 684 00:42:23,525 --> 00:42:26,405 Danny, Danny and I, you know, live reasonably close together. You're just down in the 685 00:42:26,405 --> 00:42:30,165 Gold Coast, which is, what, 50 k's from Brisbane, and we 686 00:42:30,165 --> 00:42:33,630 catch up occasionally. You've missed, You missed a very fun 687 00:42:33,630 --> 00:42:37,230 presentation I did last night at the, Queensland business apps user 688 00:42:37,230 --> 00:42:41,025 group. I was in costume doing my how to How to 689 00:42:41,025 --> 00:42:43,925 solve the Elon Musk problem in in Dataverse. 690 00:42:44,705 --> 00:42:48,085 But, what what kind of events have you got coming up soon, Danny? 691 00:42:48,530 --> 00:42:52,070 Yeah. That was an that that was an interesting topic that you presented 692 00:42:52,130 --> 00:42:55,575 yesterday. Yeah. Look. 693 00:42:55,895 --> 00:42:59,035 I'm hoping to go at the, Nordings 694 00:42:59,335 --> 00:43:02,695 Nordic Summit while I'm traveling in Europe end of 695 00:43:02,695 --> 00:43:06,480 September. Great. So Copenhagen this year? 696 00:43:06,620 --> 00:43:10,460 Yep. Yeah. Correct. Hoping to get that one. I have a bit of 697 00:43:10,460 --> 00:43:14,025 traveling and then for, yeah, for 698 00:43:14,025 --> 00:43:17,865 leisure Europe happening, so try to cause us you know, 699 00:43:17,865 --> 00:43:21,645 we don't travel to Europe that often for me. It's like a 24 hours 700 00:43:22,410 --> 00:43:26,170 plane ride. Right? So but, yes. So that's 701 00:43:26,170 --> 00:43:29,849 planned. Nothing really other from 702 00:43:29,849 --> 00:43:33,635 a Professional perspectives, where to 703 00:43:33,635 --> 00:43:37,315 find me on LinkedIn? You're always pretty active on LinkedIn. I love 704 00:43:37,315 --> 00:43:40,940 following your content there. Thank you. Yeah. You you're 705 00:43:40,940 --> 00:43:44,220 pretty active too. Mhmm. Yeah. I I I'll just try and keep up with you 706 00:43:44,220 --> 00:43:47,660 and Hamish, really. You're always publishing these really 707 00:43:47,660 --> 00:43:50,865 colorful series of conceptual diagrams diving deep into 708 00:43:51,244 --> 00:43:54,684 industry accelerators or different applications. Have you got any more of those 709 00:43:54,684 --> 00:43:58,300 planned? What kind of content are you brewing for us at the 710 00:43:58,300 --> 00:44:02,140 moment. Yeah. So I'm in a series which takes a 711 00:44:02,140 --> 00:44:05,935 lot of time, but it's in a series of of kind of concepts 712 00:44:05,995 --> 00:44:09,755 where I explore kind of the major components of 713 00:44:09,755 --> 00:44:13,290 the poor platform. So I started with the high level, You 714 00:44:13,290 --> 00:44:17,070 know, Microsoft Biz Apps. What is in Biz Apps? It's a bit of diagramming, 715 00:44:17,130 --> 00:44:20,890 right, which to be fair, what was was got a 716 00:44:20,890 --> 00:44:24,725 lot of attraction, like, comments, and so that was so that kind 717 00:44:24,725 --> 00:44:28,485 of encouraged me to continue, and then I went 1 level down to the poor 718 00:44:28,485 --> 00:44:31,930 platform, and then, again, decomposing this. Then I I'm doing 719 00:44:31,930 --> 00:44:35,450 now data so Dataverse, I had a diagram plus an 720 00:44:35,450 --> 00:44:39,255 explanation to you to a YouTube video. Then I had poor apps, 721 00:44:39,335 --> 00:44:43,174 And I had Scott Duro jumping me on a call, depicting the 722 00:44:43,174 --> 00:44:46,775 whole thing. I just did Power BI with Greg 723 00:44:46,775 --> 00:44:50,470 Nash, is a poor VI MVP. He also went in kind of 724 00:44:50,870 --> 00:44:54,310 and it is it it is I like doing those 725 00:44:54,310 --> 00:44:58,045 diagram, but it's really helps me understand. Like, I've learned so 726 00:44:58,045 --> 00:45:01,724 much from I knew I think I knew poor apps, like, even model driven 727 00:45:01,724 --> 00:45:04,545 apps and stuff, but having a conversation with another 728 00:45:05,190 --> 00:45:09,030 Expert, like, telling the stories and how to use specific things. It's 729 00:45:09,030 --> 00:45:12,790 just enriching you so much. Right? So it's it's a big it's 730 00:45:12,790 --> 00:45:16,285 how I learn, Basically. Right? So I have those planned for the other 731 00:45:16,285 --> 00:45:20,125 parts. I'm hoping to get Nick done when I think he already asked 732 00:45:20,125 --> 00:45:23,410 if he wanted to do with me the pages one. So 733 00:45:23,869 --> 00:45:27,170 he he he was keen to do that. I'll do 1 on automate 734 00:45:27,630 --> 00:45:31,309 for Vultr agents. So but it really takes a bit of time, so it's 735 00:45:31,309 --> 00:45:34,775 it's It's a few weeks, months sometimes work. 736 00:45:35,475 --> 00:45:39,315 So this I I have. And then, occasionally, whatever 737 00:45:39,315 --> 00:45:42,680 I have, What I like doing right now is sometimes some 738 00:45:42,900 --> 00:45:46,339 small post on design ideas. You know, I 739 00:45:46,339 --> 00:45:50,105 stumbled lately on this new sub grids That you can you 740 00:45:50,105 --> 00:45:53,785 click on a sub grade and that opens up in a model view. Yeah. Like 741 00:45:53,945 --> 00:45:57,545 so one of my plan, I had a strong requirements around that, and it's really 742 00:45:57,545 --> 00:46:01,010 kind of, You know, they were very hap so I kind of posted. So when 743 00:46:01,010 --> 00:46:04,690 I have some ideas like that during my work, I try to quickly, you 744 00:46:04,690 --> 00:46:08,055 know, Share it to the community. But other than that, nothing 745 00:46:08,055 --> 00:46:11,734 else, really. Apart from all these videos and 746 00:46:11,734 --> 00:46:15,119 blogs and YouTube posts and everything else you do, Not 747 00:46:15,119 --> 00:46:18,720 much. I love it. Well, you also 748 00:46:18,720 --> 00:46:22,420 have, of course, your functional consulting course. We talk a lot today about 749 00:46:22,765 --> 00:46:26,605 Managing requirements. Your course is super helpful. If anybody who wants 750 00:46:26,605 --> 00:46:29,725 to dive much deeper into the kind of topics Danny and I have discussed today, 751 00:46:29,725 --> 00:46:33,540 he has The best course on it. I've I've taken it. I've loved 752 00:46:33,540 --> 00:46:37,220 it. It complements Hamish's work really well too, but you go deep 753 00:46:37,220 --> 00:46:40,835 into the stages of, Product backlog items 754 00:46:40,835 --> 00:46:44,675 and Azure DevOps and other topics, that we've discussed today, and I find it really 755 00:46:44,675 --> 00:46:48,115 useful. So encourage my teams to go through it. I encourage all of you 756 00:46:48,115 --> 00:46:51,690 listening watching today to go through that as well. I'll I'll include a link to 757 00:46:51,690 --> 00:46:54,650 that in the show notes as well as Danny's YouTube channel and your blog and 758 00:46:54,650 --> 00:46:58,434 everything else, Danny. Thanks so much for joining. Amazing. 759 00:46:58,494 --> 00:47:02,095 Thank you, Neil. So, 7th time next time, or was that 760 00:47:02,174 --> 00:47:04,974 that's the 6th time now? This is the 6th. Yeah. I think the next time 761 00:47:04,974 --> 00:47:07,840 will be the 7th. We'll have to we'll have to find another topic, we'll have 762 00:47:07,840 --> 00:47:11,460 you back on as soon as we can. Amazing. Thank you. 763 00:47:11,680 --> 00:47:15,440 Thanks, Danny. Bye. See you. My biggest takeaway 764 00:47:15,440 --> 00:47:19,184 from my conversation with Danny was the Practical use of 765 00:47:19,184 --> 00:47:23,025 documentation in addition to whatever is written in your user story, 766 00:47:23,025 --> 00:47:26,484 a solution blueprint, a user interface, wireframe, 767 00:47:27,030 --> 00:47:30,550 or example data in a spreadsheet. I'm generally a fan 768 00:47:30,550 --> 00:47:34,250 of minimalist user stories that encourage conversations 769 00:47:34,470 --> 00:47:38,305 between developers and users, But Danny shared with us some great reasons 770 00:47:38,445 --> 00:47:42,285 to enrich our user stories without going to the extreme of writing 771 00:47:42,285 --> 00:47:46,050 an old fashioned upfront requirement specification. What was 772 00:47:46,050 --> 00:47:49,810 your biggest takeaway from this episode? Visit the customer company page 773 00:47:49,810 --> 00:47:53,650 on LinkedIn or the amazing apps LinkedIn group, and let Donnie know. 774 00:47:53,650 --> 00:47:55,615 Until next time, Keep experimenting.