 Hi, my name is Ty Davis and today I'm going to be walking you through how to do Agile Project Management at GitLab. This is something that we define as part of our manage and plan stages, as part of the 10 stages that we have as the DevOps lifecycle. It is a great starting point for organizations looking to plan out the Agile projects that their teams will be approaching and tying that to your SCM and tying that to your CICD and your security as part of that DevOps end to end. So what we're going to do is we're going to take a look at this mock organization, healthcare provider incorporated. They've broken down their organization into value streams or into specialty areas with groups or with subgroups. You can see that here with online experience, hospital, laboratory, pharmacy, specialist primary care and then they have PLMO management as a project and this is where they're going to do a lot of their high level Epic boards and moving those from in progress to done and directly correlating those with issues and subepics and these value streams or specialty groups. When we take a look at how hierarchy works instead of GitLab, in this particular case we have these groups that I just mentioned and then underneath them that we have large Agile teams and intake, patient records, staff scheduling, billing. We're going to be looking at billing and the four project levels underneath billing which we'd consider these either Scrum or Kanban teams that make up the larger Agile team of billing. These projects are where your repositories are going to exist. This is where your issue boards are going to exist and seeing progress that's done with those specific projects. You have the ability at the billing subgroup level to see everything that's happening with these projects. It rolls up to billing and the same thing will happen at a roll up to hospital and then that can roll up the highest level to healthcare provider incorporated where leadership or execs have visibility into the organization as a whole and progress that's being made with all of the different areas and groups. Before we dive into that project, we're going to look at the issue or sorry, the EPICS. EPICS are going to be rolled up again to this very high parent-to-ancestor level. When we're at this high portfolio level, we're probably going to be looking at just maybe a strategic theme that's going to be broken down into our larger EPICS and then broken down into a feature into an issue. So we as leadership, we looked at this. We've seen that this is the five important areas for us that we want to improve upon. Maybe if we look at improve overall ARP since we'll be talking billing, I can see that there's a sub EPICS directly correlated with that. Maybe this is a larger EPIC or maybe this is actually just a feature. In this case, it's a feature that accept all major methods of payment. I have that traceability. If I were to go into that feature or sub EPICS, I can see that there's another feature correlated with it right here and I can see all the issues that are directly correlated with this sub EPICS that I've defined. So it has that great traceability of showing that hierarchy of EPICS to sub EPICS to issues, keeping that correlation amongst themselves and giving that leadership or that exacter or maybe a director VP visibility into what is specifically associated with a sub EPICS. Going back here to health care provider, this is where we're going to start. I mentioned we're going to get into billing and this is where I'm going to go into patient billing here. I am going to head over to the board view. You can see that I landed right on the repository there. And this is where we're going to start doing our backlog grooming. We're going to do our sprint planning or release planning. In this case, I am doing scrum. So I have some sprint setup. This is looking at the current sprint, but I want to do sprint planning. I'm going to go over to that board view that I've set up using what we define and milestones, which is where we define our sprints. Milestones and GitLab is a time box. We'll look at that. Actually, I'll just show you that right now. You can see over here in milestones, I've defined sprint one through five. You could define releases if you wanted, like a 12.0, 12.1. If you're doing more of a con bond approach, but milestones. This is where we do time boxing and we define our sprints. And then you could take those sprints, bring over to your sprint planning board, give them each a lane, and this is where we can start doing our dragging and dropping, assigning issues to that sprint. In this case, I'm in sprint two. Let's say we're already currently in sprint one. So that's ongoing and we're planning for the next one or maybe we are. We are just completing sprint one and beginning sprint two. So I've moved issues over to sprint two. They're now assigned to that sprint. I'm going to go to current sprint. Let's just say, for instance, now we are in sprint two and dev team, we see all the issues that have been assigned to sprint team or sprint two and this is actually filtered by sprint two so I can see everything specific that is only associated with sprint two. So drag and drop these issues over. Maybe it's me tie the developer. I'm coming in here. I say, OK, I want to work on that issue. I'm going to assign it to myself. It's now in progress. The same can be done for other issues. You know, maybe Dan is going to take this one. We'll see here. DT is going to take this one and then Mark is going to take this one. So now we are in our current sprint. We're working on these. We've came in here, self organized. So these are the issues that we're working on and we're moving forward. Those we have scope labels inside of GitLab. This is how you can build out your workflows. Let's say I move my from in progress to review. We can see that that status reviews label has now taken ownership and remove the end progress. So this gives us very easy ability to filter if you want to see if anything's in a specific a core layer with specific tag. If I'm a scrum master or a product owner and I want to have visibility in the team board, I can take a look here. I could see what's assigned to Dan and Ty and Dave. And then just make sure that there's no bottlenecks. If there's any struggle somewhere where where something's not moving through, I can we could try to help alleviate and hope in those areas diving into specific issue. Now, let's see how the structure is built out with an issue. I can see on the right side here, we have the epic that it's tied to who's assigned to the milestone that it's part of. You can add specific time tracking in here. If you want to add some hours to give it a due date, labels that's associated with that add any other labels. Maybe you're doing safe. It's part of an agile release train. And then the weight you can add in here, whether you're doing maybe a favorite nacho scale or or card deck of cards, however you do that, you can add that weight in here. And then you have a few other options on the right. You can give it a title description and then you can have a specific task. Maybe we need some more minute to dues that will make this issue or user story move along. And those tasks can be defined in the description. We'll have a related merge request. So I can see I've already opened one up here. And if I want to just create a new merge request, I can do that here. This is a very big piece of GitLab because no other tool out there has a direct correlation with agile project management and their merge pull request. So their their their SEM and agile project management. Most everything else is just an integration. Maybe you're integrating another tool with GitLab to have that kind of benefit. And so what you have the ability to do is use GitLab to create a merge request and that dev can go in there. They can check out their branch. They can use their IDE. They can use our Web IDE that's built in. This is very beneficial on the business side. A lot of people at GitLab from HR to marketing actually use our own tool and use this built in Web IDE to make changes on the company site merge request. We're not going to get into this. We could do that in different demo, but great collaboration area. Let's say that we we did run a pipeline and we close that pipeline out or sorry, close that pipeline. Apologies. So we run we check out our branch. We make our changes. We commit and push that and then the pipeline passes. Then we can merge that to master and that's going to close out that issue. So we can see that it's closed out to it's going to close issue. Sixteen and that's going to help us as we progress through agile and I don't have to make any extra effort as a developer to go in and move my issue from and review to done. It's going to do that automatically. And then I can continue on to the next issue. I want to take a look at, you know, if we need to see how burned down is going. We can see this is actual release that we have at GitLab. It could take a look by issue weight or issues. It gives us great visibility into progress as part of that sprint or that release. Over here is showing you how many issues are closed and open. It's a great spot to track that progress of teams. So summarizing, you know, what what we've, you know, for agile project management and there's a lot more we can get into. But it is a great starting point and planning out what teams need to do, how you're going about microservices or applications and planning for those. And directly tying that to SCM, directly tying that to your CICD. All in one application makes it very, very easy inside of GitLab to do. If you have any questions, feel free to reach out. We're more than happy to help. Thank you for joining.