---Subject: Using Azure DevOps + Backlog ManagementDetails: Covering the best practices on ticket management and how we use them at ClarityDuration: 00:16:42---Presenter: Kevin Kramer00:00:00.180 --> 00:00:03.879 - The backlog, this is something everyone's pretty familiar with. 00:00:03.879 --> 00:00:09.633 - I am hoping to be able to run some of this training past the 00:00:09.633 --> 00:00:11.277 - development team as well. 00:00:11.300 --> 00:00:14.192 - And kind of steel bits and pieces and kind of talked to 00:00:14.192 --> 00:00:15.638 - them about things and get some 00:00:15.638 --> 00:00:20.940 - of their feedback. Um, so we're just going to go through 1st. 00:00:21.300 --> 00:00:25.612 - So the backlog levels. I believe everyone on this call um. 00:00:26.510 --> 00:00:29.280 - Potentially, with the exception of gems, since you're still very 00:00:29.280 --> 00:00:32.604 - new, uh, is familiar with the backlog levels and how we use 00:00:32.604 --> 00:00:34.880 - them so. We have 00:00:35.420 --> 00:00:38.340 - Six different backlog levels that we use. By default. We've 00:00:38.340 --> 00:00:41.844 - got the project manager level, which is what we used to group 00:00:41.844 --> 00:00:45.056 - clients to project managers in the backlog. We have the client 00:00:45.056 --> 00:00:47.976 - level where we group the different phases of a client 00:00:47.976 --> 00:00:52.675 - using epics. Uh, we have epics which represent or are intended 00:00:52.675 --> 00:00:57.390 - to represent. Um, either a project or an MVP or a phase 00:00:57.390 --> 00:01:00.790 - and development so that those can be grouped together and 00:01:00.790 --> 00:01:01.470 - managed accordingly. 00:01:02.610 --> 00:01:06.710 - Feature, which should be a collection of user stories that 00:01:06.710 --> 00:01:10.810 - describes a feature, a feature being something like check out 00:01:10.810 --> 00:01:16.605 - or. The submission of a quote would be a feature. 00:01:16.610 --> 00:01:20.220 - And then those would contain user stories which provide the 00:01:20.220 --> 00:01:23.830 - Descriptive and reason for why that functionality needs to be 00:01:23.830 --> 00:01:25.996 - there and how it should operate. 00:01:26.560 --> 00:01:29.752 - And then we roll into task which should be written by the 00:01:29.752 --> 00:01:32.146 - developer. and I think with these architecture review and 00:01:32.146 --> 00:01:34.540 - changes will actually a little bit closer to that. 00:01:35.140 --> 00:01:38.490 - Uhm, but that's ultimately how we measure and track things. 00:01:39.090 --> 00:01:42.704 - Now, the purpose of this part of the training today is really to 00:01:42.704 --> 00:01:44.372 - have more of a discussion around 00:01:44.372 --> 00:01:51.120 - this. Um, and make sure that we as a project management 00:01:51.120 --> 00:01:53.464 - organization including Kyle and 00:01:53.464 --> 00:01:57.254 - Christian. Uh, understand how everything is expected to 00:01:57.254 --> 00:02:00.974 - function and behave and work towards getting us there, 'cause 00:02:00.974 --> 00:02:04.544 - I think. If you were being objective and looking at our 00:02:04.544 --> 00:02:07.256 - backlog, you would say that we're not where we need to be 00:02:07.256 --> 00:02:08.720 - yet. So. 00:02:09.860 --> 00:02:11.126 - This is a couple of quick. 00:02:12.120 --> 00:02:16.292 - Things um, the project management manager, product 00:02:16.292 --> 00:02:20.910 - owner. That is a very simple item. We don't have any 00:02:20.910 --> 00:02:23.862 - documentation requirements for it and we just have clients 00:02:23.862 --> 00:02:28.680 - associated underneath it. That all should make relative sense. 00:02:29.310 --> 00:02:33.126 - The client level is just a grouping that allows us to group 00:02:33.126 --> 00:02:36.942 - the epics underneath it. I used you as an example 'cause they 00:02:36.942 --> 00:02:38.850 - had a lot of really good 00:02:38.850 --> 00:02:42.911 - examples here. So there's no real documentation that goes 00:02:42.911 --> 00:02:46.400 - into their. An epic 00:02:47.890 --> 00:02:50.464 - There's some things that we could do that we probably should 00:02:50.464 --> 00:02:53.272 - start doing at the epic level just to make sure. If someone's 00:02:53.272 --> 00:02:56.314 - new incoming in, they could see some things, but how it looks in 00:02:56.314 --> 00:02:59.356 - the backlog, it's just kind of an epic with a whole bunch of 00:02:59.356 --> 00:03:02.670 - features underneath it. Same with feature and you kind of get 00:03:02.670 --> 00:03:04.140 - the Gist of how it goes down. 00:03:05.130 --> 00:03:09.530 - So at the feature Level I started breaking into a little 00:03:09.530 --> 00:03:11.130 - bit of additional detail. 00:03:11.780 --> 00:03:15.154 - As to what makes a good feature 00:03:15.154 --> 00:03:20.638 - so. One of the things I'm sorry if I'm picking on yawls 00:03:20.638 --> 00:03:24.130 - projects. I was literally just randomly clicking through the 00:03:24.130 --> 00:03:26.070 - backlog looking for good, bad, 00:03:26.070 --> 00:03:28.110 - different examples. So. 00:03:28.930 --> 00:03:32.934 - What makes a good feature? So having a solid description at 00:03:32.934 --> 00:03:36.574 - the feature level will greatly help reduce confusion at least 00:03:36.574 --> 00:03:40.942 - once we get the developers used to using the backlog as it 00:03:40.942 --> 00:03:42.034 - supposed to be. 00:03:42.050 --> 00:03:44.767 - Because in theory, if your task doesn't have enough detail, I 00:03:44.767 --> 00:03:47.731 - should go look at the parent of that, and if that doesn't, 00:03:47.731 --> 00:03:50.942 - maybe even go look at the feature level just so I can get 00:03:50.942 --> 00:03:53.412 - a good understanding of how things would work. I don't 00:03:53.412 --> 00:03:56.129 - disagree with the feedback that I know I would immediately be 00:03:56.129 --> 00:03:58.846 - resented if I paused, and that wasn't talking. Is that the 00:03:58.846 --> 00:04:01.069 - development team currently looks only the task and what's 00:04:01.069 --> 00:04:03.786 - in front of them and doesn't really go any further than 00:04:03.786 --> 00:04:04.033 - that. 00:04:05.230 --> 00:04:09.786 - Um? So I would say the other big thing that makes a good feature 00:04:09.786 --> 00:04:12.450 - is making sure we have properly linked stories, and I think for 00:04:12.450 --> 00:04:14.892 - the most part we're doing that component of it very well. 00:04:15.410 --> 00:04:18.434 - Uh, it's at least having the stories linked where I think we 00:04:18.434 --> 00:04:19.946 - struggle is what the content in 00:04:19.946 --> 00:04:23.837 - the feature is. Um and these are the couple things I put 00:04:23.837 --> 00:04:24.929 - together. They were definitely. 00:04:25.550 --> 00:04:27.900 - Other things that we will need to discuss and I 00:04:27.900 --> 00:04:30.250 - definitely wanna get your input on all of this, which 00:04:30.250 --> 00:04:31.895 - is why I didn't go too crazy. 00:04:33.020 --> 00:04:34.880 - So a user story. 00:04:35.600 --> 00:04:38.878 - Of course, should be kind of Descriptive. The sample I pulled 00:04:38.878 --> 00:04:42.454 - in here isn't quite written in user story format, and I know 00:04:42.454 --> 00:04:43.646 - the reason behind that. 00:04:44.200 --> 00:04:48.980 - Um? Was it was really more like a bug and we were tracking about 00:04:48.980 --> 00:04:50.330 - 1000 things in 1000. Different 00:04:50.330 --> 00:04:52.645 - speeds. But what makes a good 00:04:52.645 --> 00:04:57.205 - user story? So the title of a user story should be a short 00:04:57.205 --> 00:04:58.730 - description of what the user 00:04:58.730 --> 00:05:02.665 - story is. And then in the description of the user story, 00:05:02.665 --> 00:05:05.910 - we should have the user story written and then any additional 00:05:05.910 --> 00:05:09.450 - detail that would be there to support it. And Kyle, I know 00:05:09.450 --> 00:05:13.285 - you've worked a lot with the IW integration to make sure some of 00:05:13.285 --> 00:05:16.825 - this gets populated by default and is less of a manual process. 00:05:16.825 --> 00:05:18.595 - Kind of as we go forward. 00:05:19.320 --> 00:05:21.930 - So and of course we have 00:05:21.930 --> 00:05:25.434 - screenshots. The planning section making sure that we have 00:05:25.434 --> 00:05:28.822 - the priority set will help you manage your backlog correctly. I 00:05:28.822 --> 00:05:32.826 - know a lot of times we set a priority at one point, it 00:05:32.826 --> 00:05:34.366 - doesn't really get touched again 00:05:34.366 --> 00:05:38.123 - until Sprint Planning. Uh, when you guys are prioritizing the 00:05:38.123 --> 00:05:41.831 - work in that Sprint. However, we should be using priority as a 00:05:41.831 --> 00:05:43.994 - tool to plan what goes into the 00:05:43.994 --> 00:05:48.280 - next Sprint. Uh, and things of that nature. And then of course, 00:05:48.280 --> 00:05:49.795 - each story should be broken 00:05:49.795 --> 00:05:53.966 - down. To the actionable tasks, development work can be 00:05:53.966 --> 00:05:58.120 - performed on. And we're going to go through some good and bad 00:05:58.120 --> 00:06:00.080 - examples and how we could do it 00:06:00.080 --> 00:06:01.760 - better. In our little game. 00:06:03.070 --> 00:06:04.534 - We think will drive a lot of discussion. 00:06:05.790 --> 00:06:06.550 - Um? 00:06:07.990 --> 00:06:10.714 - A task how it looks in the backlog sample ticket. Kind of 00:06:10.714 --> 00:06:12.076 - going into what makes a good 00:06:12.076 --> 00:06:16.678 - task. Um, the title of a task should be descriptive of the 00:06:16.678 --> 00:06:18.318 - development that's needing to be 00:06:18.318 --> 00:06:20.260 - done. Right so. 00:06:20.870 --> 00:06:26.790 - Uh. Implement or fix are not good task titles. 00:06:27.490 --> 00:06:30.680 - The majority of our backlog I would say is probably implement 00:06:30.680 --> 00:06:32.420 - or fixed tickets from a task 00:06:32.420 --> 00:06:36.160 - level. Um, as far as a description, we should have a 00:06:36.160 --> 00:06:39.240 - description of the technical work that needs to be done. Of 00:06:39.240 --> 00:06:42.040 - course there's any screenshots are mockups. Those are very good 00:06:42.040 --> 00:06:45.604 - examples. Uh, to provide to the development team and the 00:06:45.604 --> 00:06:47.134 - planning section is just as 00:06:47.134 --> 00:06:49.584 - important. Um, just because you 00:06:49.584 --> 00:06:53.334 - cannot. Does the title up there? Does it have to have the you 00:06:53.334 --> 00:06:56.582 - want to have, like an action in there since it's a task? Or do 00:06:56.582 --> 00:07:00.908 - you care? When you say discriptive like it needs to be 00:07:00.908 --> 00:07:04.572 - like. Fix is not descriptive, but it's flashing Aaron sales 00:07:04.572 --> 00:07:08.268 - order editor. An admin would be fine, but you don't care either 00:07:08.268 --> 00:07:11.348 - way doesn't necessarily have to have the verb in there. 00:07:12.080 --> 00:07:14.530 - Well, I would say it should be. 00:07:15.870 --> 00:07:19.210 - Yeah yeah I would 00:07:19.210 --> 00:07:24.674 - say uhm. Ideally, these are written by the developer, so 00:07:24.674 --> 00:07:27.495 - keep that in mind, then OK, OK. 00:07:27.500 --> 00:07:31.543 - Helpful, Um, I don't think that necessary. I think this is not a 00:07:31.543 --> 00:07:34.964 - good example because it doesn't have the action that's needed an 00:07:34.964 --> 00:07:39.007 - if that's what you're asking for password, I was yes. I'm sorry I 00:07:39.007 --> 00:07:42.739 - couldn't find a really great example of a task, but at the 00:07:42.739 --> 00:07:46.782 - same time what Kevin Saying is that just the word fix is not 00:07:46.782 --> 00:07:50.203 - good, because that doesn't follow that. No, no, I was just 00:07:50.203 --> 00:07:54.246 - asking about that. This was an example of what he wanted, or if 00:07:54.246 --> 00:07:57.667 - it should ideally have the action in there. I think it 00:07:57.667 --> 00:07:58.911 - should be descriptive and. 00:07:58.960 --> 00:08:03.006 - You know, kind of have an action word in there. Since it is a. 00:08:03.010 --> 00:08:05.458 - Just between you 2. 00:08:06.060 --> 00:08:11.839 - No. Hi. So kind of why all of these things are 00:08:11.839 --> 00:08:15.349 - important though is really, and how the development team used 00:08:15.349 --> 00:08:16.753 - the task and stories. 00:08:17.400 --> 00:08:20.160 - Um, and that's because when they get there, they are 00:08:20.160 --> 00:08:21.540 - looking at something like this. 00:08:23.140 --> 00:08:24.648 - Most of the time. 00:08:25.940 --> 00:08:28.850 - Your developers not going to click into the ticket except 00:08:28.850 --> 00:08:30.596 - maybe once before they start it. 00:08:31.110 --> 00:08:36.270 - So. If we were in a room and I ask for a show of hands, how 00:08:36.270 --> 00:08:38.594 - many times you get people to say no? I don't know what to do. 00:08:39.150 --> 00:08:42.246 - On my task, even though you put out very clear instructions in 00:08:42.246 --> 00:08:47.003 - the ticket. I would imagine I would see a room full of hands 00:08:47.003 --> 00:08:49.810 - up right now. Yep. 00:08:49.810 --> 00:08:53.225 - So just kind of walking 00:08:53.225 --> 00:08:58.130 - through. If I'm even when I've had development tickets, I don't 00:08:58.130 --> 00:09:02.162 - necessarily click into it. That is a bad behavior as a whole, 00:09:02.162 --> 00:09:05.858 - but its behavior is going to be hard to change, so. 00:09:06.720 --> 00:09:11.102 - When I look at this example and then I did pick on you 'cause 00:09:11.102 --> 00:09:12.980 - you had a couple of examples 00:09:12.980 --> 00:09:16.400 - here. Review user story implement changes. 00:09:17.700 --> 00:09:20.700 - Well if I'm a developer and that's my task, then that could 00:09:20.700 --> 00:09:23.700 - make me feel overwhelmed. Have to go like track down when I 00:09:23.700 --> 00:09:27.679 - actually need to do. And we can look through a few 'cause part 00:09:27.679 --> 00:09:30.811 - of this exercise. I want to do today will actually involve us 00:09:30.811 --> 00:09:33.943 - having you guys pull up some of your backlog and go through. 00:09:34.720 --> 00:09:39.462 - Um? But I will pause right there before we go into our next part 00:09:39.462 --> 00:09:42.630 - and just see if there's anything that I just kind of Glaze 00:09:42.630 --> 00:09:44.214 - through or didn't make sense at 00:09:44.214 --> 00:09:47.680 - all. And then we're going to kind of transition into the 00:09:47.680 --> 00:09:50.220 - discussion portion, and for that, Daniel I think we just 00:09:50.220 --> 00:09:53.776 - need to put a marker of the time in the meeting so we can 00:09:53.776 --> 00:09:55.046 - truncate that out of the 00:09:55.046 --> 00:09:57.420 - training video. Um, so just at 00:09:57.420 --> 00:10:01.370 - this point. Uh, and then save the rest of the report the 00:10:01.370 --> 00:10:04.502 - recording. So we have. We can take it and dissect the feedback 00:10:04.502 --> 00:10:08.934 - out of it. Stop recording now. I'd only want to capture it 00:10:08.934 --> 00:10:12.394 - because will probably discuss things that will miss and I 00:10:12.394 --> 00:10:16.546 - think for what I believe Jim is working on, the training side 00:10:16.546 --> 00:10:20.352 - would be helpful for some of the documentation he's working on. 00:10:20.352 --> 00:10:23.948 - Yes. Just for whatever we're posting to whatever training 00:10:23.948 --> 00:10:25.778 - repository would cut it off 00:10:25.778 --> 00:10:29.214 - right here. All right, any questions or comments for we 00:10:29.214 --> 00:10:32.932 - dive in and start looking at some real world examples. Kind 00:10:32.932 --> 00:10:37.326 - of run through my little game here and then we can pull up 00:10:37.326 --> 00:10:41.720 - some of yalls backlogs and talk through some things we can do to 00:10:41.720 --> 00:10:43.072 - improve as a team. 00:10:43.110 --> 00:10:47.454 - I foresee sportin a epic scope and Kevin, you know about this, 00:10:47.454 --> 00:10:51.798 - 'cause you refine some of my projects. But as far as epics, 00:10:51.798 --> 00:10:56.142 - what is the best practice for using those so the best practice 00:10:56.142 --> 00:11:00.486 - for using an epic? The way we operate internally? And this is 00:11:00.486 --> 00:11:04.226 - not. It is most certainly not in line with what agile and scrum 00:11:04.226 --> 00:11:07.278 - will tell you to do. This is just how we've adapted it to fit 00:11:07.278 --> 00:11:09.030 - our needs. Um? 00:11:10.410 --> 00:11:14.682 - Is. For using the epic level to sort out your project phases 00:11:14.682 --> 00:11:18.210 - like using epic for your MVP or for phase one. And that way when 00:11:18.210 --> 00:11:21.486 - someone saying oh that can wait till phase two, you can move it 00:11:21.486 --> 00:11:24.762 - to a different epic and not have to see it while you're working 00:11:24.762 --> 00:11:26.022 - on the phase one stuff. 00:11:26.580 --> 00:11:29.946 - Um, an epic. In general, I believe you probably have the 00:11:29.946 --> 00:11:33.006 - best definition from it because you know, I've had this 00:11:33.006 --> 00:11:36.984 - discussion before, but if you want to talk to how an epic is 00:11:36.984 --> 00:11:40.380 - traditionally used. You're welcome, yeah. OK so 00:11:40.380 --> 00:11:44.280 - traditionally an epic would be categorized an exact same manner 00:11:44.280 --> 00:11:49.350 - and have the same format as a user story. It would be. It 00:11:49.350 --> 00:11:54.030 - would be called an epic user story in a traditional sense of 00:11:54.030 --> 00:11:59.100 - agile. What the difference is is that there would be a very very 00:11:59.100 --> 00:12:03.000 - broad user story. So for instance in epic user story 00:12:03.000 --> 00:12:08.850 - might be as a user. I need to be able to make a purchase on. 00:12:09.650 --> 00:12:15.290 - Uh, I need to pay my taxes online. Yeah online on the 00:12:15.290 --> 00:12:19.351 - website. Well, that obviously has a bunch of smaller user 00:12:19.351 --> 00:12:22.939 - stories and features underneath it 'cause you have to be able to 00:12:22.939 --> 00:12:26.228 - capture payments. You have to be able to sort through products 00:12:26.228 --> 00:12:30.414 - you have to be able to add the categories in there. You have to 00:12:30.414 --> 00:12:34.301 - be able to filter through the catalog. You have to be able to 00:12:34.301 --> 00:12:37.590 - use the search, so the general epic user stories in a 00:12:37.590 --> 00:12:41.178 - traditional sense would be more of a general sense of what needs 00:12:41.178 --> 00:12:45.065 - to happen in the cases of things like trying to think of an 00:12:45.065 --> 00:12:46.261 - example that everyone would 00:12:46.261 --> 00:12:51.649 - understand. Um? An example of having a target check out so 00:12:51.649 --> 00:12:54.859 - that multiple checkouts can happen at. You know, you can 00:12:54.859 --> 00:12:57.106 - check out and then have items go 00:12:57.106 --> 00:13:01.473 - to different locations. And that might be a smaller user 00:13:01.473 --> 00:13:06.530 - story, but if it's an in depth feature that has a lot of 00:13:06.530 --> 00:13:10.031 - complication to it that would traditionally become an epic 00:13:10.031 --> 00:13:13.921 - user story so you can breakdown the epic user story 00:13:13.921 --> 00:13:17.811 - into smaller features and user stories so that it's a 00:13:17.811 --> 00:13:20.145 - workable item. Does that make sense? 00:13:21.610 --> 00:13:25.020 - And uh, and Clint to your question, we typically don't go 00:13:25.020 --> 00:13:29.050 - that high level because we go in and do an in-depth discovery and 00:13:29.050 --> 00:13:32.460 - really focused on the features. 'cause we have a starting point 00:13:32.460 --> 00:13:36.033 - for our platform. If we were building our platform from 00:13:36.033 --> 00:13:39.322 - scratch, um, in most of our development, we would use the 00:13:39.322 --> 00:13:41.415 - epics in a more epic user story 00:13:41.415 --> 00:13:46.987 - fashion. Uhm, but we use that as an organizational ever. 00:13:46.990 --> 00:13:50.160 - Yeah, organization mechanism to group kind of the project phases 00:13:50.160 --> 00:13:54.598 - and we saw what happens if we go too crazy with them with excela 00:13:54.598 --> 00:13:58.719 - health because each feature also had its own epic and it made it 00:13:58.719 --> 00:14:00.621 - very hard for you to navigate 00:14:00.621 --> 00:14:02.790 - your backlog. Cross. 00:14:05.460 --> 00:14:06.710 - Did that answer your question? 00:14:08.550 --> 00:14:11.736 - It did, yeah, I could just clear on that. 00:14:12.930 --> 00:14:14.138 - I was thinking, uh? 00:14:14.890 --> 00:14:19.349 - Kevin Hart and soft stops for you. AG like that would be epic 00:14:19.349 --> 00:14:22.779 - 'cause there was so much sub categories under that that 00:14:22.779 --> 00:14:26.552 - absolutely should have been an epic category or an epic user 00:14:26.552 --> 00:14:30.325 - story and the way we would have tracked that internally. Jim 00:14:30.325 --> 00:14:33.069 - just the way we have traditionally done things. 00:14:33.570 --> 00:14:37.405 - Is in a perfect world where we weren't in a scramble when that 00:14:37.405 --> 00:14:40.945 - came about. We would have said, OK, we're not going to. We're 00:14:40.945 --> 00:14:42.125 - going to look at. 00:14:42.950 --> 00:14:46.110 - Hard so hard stops. This scenario is a feature hard 00:14:46.110 --> 00:14:47.690 - stops. This scenario is a 00:14:47.690 --> 00:14:51.640 - feature. And kind of broken those down under the phase of 00:14:51.640 --> 00:14:54.770 - the project would have been how we would have actually 00:14:54.770 --> 00:14:58.213 - implemented if we would have done it ideally anyway in our 00:14:58.213 --> 00:15:01.656 - process works. What did you mean earlier when you said there 00:15:01.656 --> 00:15:03.534 - would be epics under the user 00:15:03.534 --> 00:15:08.814 - story? I said it would be epic under the client, so we use. 00:15:08.820 --> 00:15:12.681 - Level to the epic level to kind of group the features and stuff 00:15:12.681 --> 00:15:16.245 - by phase of project, right? Right, like Jim, I think I set 00:15:16.245 --> 00:15:19.809 - up the The Realty one project today with exactly how how we 00:15:19.809 --> 00:15:23.670 - would start out with doing that. So I just have you as the 00:15:23.670 --> 00:15:27.234 - product owner then then is the client and then right under that 00:15:27.234 --> 00:15:31.392 - the first step it would be phase one and then I made a discovery 00:15:31.392 --> 00:15:34.659 - folder under that and that's going to have all my discovery 00:15:34.659 --> 00:15:38.223 - tasks that for the first phase and then we'll just keep adding 00:15:38.223 --> 00:15:41.490 - features in. As you know we kind of build out their 00:15:41.490 --> 00:15:43.290 - documentation. Got it. 00:15:44.340 --> 00:15:48.335 - Other 00:15:48.335 --> 00:15:54.646 - questions. This is like the most important 00:15:54.646 --> 00:15:58.502 - part of our job, so I want to spend as much time as we can on 00:15:58.502 --> 00:15:59.948 - this. I do have a question. 00:16:00.470 --> 00:16:01.270 - Um? 00:16:02.820 --> 00:16:06.486 - And this is more kind of how we're going to proceed moving on 00:16:06.486 --> 00:16:09.870 - in the future I guess. But what are the differences between what 00:16:09.870 --> 00:16:14.100 - we need to do now? An what are the and what we are planning to 00:16:14.100 --> 00:16:16.074 - do in the future? I think that's 00:16:16.074 --> 00:16:19.396 - an important distinction. I think will work on defining 00:16:19.396 --> 00:16:21.573 - that throughout this discussion. Garrett, I think 00:16:21.573 --> 00:16:24.683 - that's that's where we're kind of going forward. And then 00:16:24.683 --> 00:16:28.104 - ideally the training after next I would come and like I 00:16:28.104 --> 00:16:31.214 - did with the architecture of you put together the process 00:16:31.214 --> 00:16:34.013 - policy and procedure guide so that we have something 00:16:34.013 --> 00:16:38.367 - documented on what the now is, and then we can put a road map 00:16:38.367 --> 00:16:40.233 - together for the longer term goals. 00:16:41.330 --> 00:16:42.350 - All right?