 My name is Victor Wu and I am a product manager here at GitLab, and GitLab is the first single application for the entire DevOps lifecycle. And so today, I'd like to take this time to talk about one of the stages in that lifecycle, the planned stage. In particular, I'd like to talk about project or a portfolio and project management in particular, PPM as it's often known. And I'd like to talk about how we at GitLab use GitLab the application to create GitLab and in particular focus on the planned stage of creating GitLab. And within the planned stage, focus on portfolio and project management. So how do we GitLab as a company use GitLab to application to continue using a creating GitLab with PPM. So with that in mind, I'm going to show a couple of screens and demo some of a couple of features that we use ourselves every day within GitLab. So what you see on the screen here is a list of issues in GitLab. Everything starts with the issue, all concepts, ideas start with an issue. And in particular, you can see issues are scoped within a project. So if you squint your eyes a little bit here, you can see this issue is in the GitLab CE project. This issue is in the GitLab EE project. And both of these roll up into the GitLab org group. And so this is a listing of all the issues within that group. And I've already pre-filtered by the label plan and the label portfolio management. The label plan represents the planned team. So as I mentioned earlier, the DevOps lifecycle as we see it at GitLab is separated into many stages. And one of the stages is the planned stage and also corresponds to a team within GitLab. And I'm the product manager for that particular team. So I'm just showing you some of the issues within that plan area, product area in particular. And so all issues are created by Insight GitLab by a variety of folks. It could be customers. It could be users of the software. It could be ourselves. It could be community folks. It could be people who just want to contribute to GitLab, whether ideas or code, and they just create an issue. So anybody on the internet can come to GitLab.com, start an account, create an account and start an issue. And so we discuss these issues and these issues are rolled into the product itself. So it's really exciting. And so that's one way to organize ideas and essentially work. Another way to do it in GitLab and approaching more the portfolio way, so at a higher level in scope is what we call EPICS. So EPICS are at the surface, they look similar to issues. You know, it's another list where you saw a list of issues here and now you see a list of EPICS. And you can see again, I've already pre-filtered by the plan label to get only plan EPICS. So again, I'm just looking at EPICS that are relevant to the plan team. So right away, you can already see that EPICS just like issues can have labels associated with them. And so if you click on a particular EPICS, let's click on this EPIC, you can see it's associated with labels, participants notifications, very similar to an issue. So if you're watching this video, you've probably seen GitLab and an issue tracking, but maybe you haven't seen EPICS. And so EPICS is similar to an issue in that way. You can have a description. So let me show you this EPIC, you can see a description here. This EPIC doesn't have a description. But what's relevant is that you can see a list of issues associated with an EPIC. So an EPIC is a container that contains multiple issues. And the idea is that an EPIC is a higher level abstraction. It's a feature. It's a strategic initiative. So one way you would use EPICS, or in particular how we use EPICS at GitLab, is if we have a lot of different ideas that came in from issues, we organize them together. Maybe we create an extra one, maybe we break up an issue and split it up multiple, and then we group together those issues into an EPIC as a logical feature. So for example, this feature is called close EPICS, sort of ironically enough, we're using EPIC to track the feature to close an EPIC itself. And you can see this particular EPIC has a bunch of issues here. This EPIC has only three issues. And so you can see in this EPIC, some of these issues have already been enclosed, they've been completed, some are still ongoing. And in this EPIC, there's only three issues and none of them have been started yet, or none of them have been completed yet, they're all still open, and work has not commenced yet. A different way to use EPICS, aside from gathering issues together, is maybe you just have a high level of strategic initiative, and you don't know what it's going to be like yet. So we call that top down planning, as opposed to bottoms up planning. Bottoms up planning is what I just described, you know, for the past five minutes, it's a lot of issues, they're coming together, and they're just, you know, sporadic ideas, and you organize them together. Top down planning is saying something like, I have this new awesome idea. Maybe I am the CEO of a company, and I have this strategic initiative that I want to accomplish in the next quarter. I'm going to create an EPIC and assign that to a team to break down the EPIC into further issues. So instead of creating the EPIC after you have the issues, this is creating the EPIC first, and then assigning issues to it. So you can probably guess that it doesn't really matter in Guild Lab, you can do either one, because all you need to do is go to the EPICS list, click create EPIC, you know, put a title, click create EPIC, and then you'll get an EPIC and you can quickly add issues to it. So it really doesn't matter whether you do top down or bottoms up planning. What is relevant is something called the roadmap view that we've invented, which we think is pretty awesome. So this roadmap view is essentially showing you all the EPICS that are relevant. And so again, you saw the EPICS list previously here filtered by plan. And then now this is another list of EPICS filtered by plan, but instead of showing them, you know, just rows of data, as it were, we're showing rows of timelines of these EPICS. So in particular, you can see that this particular EPIC, I chose the January 8th as the start date and March 22nd as the end date or due date of this EPIC. And so if we search for that particular EPIC, looking for it really quickly, you can see that it starts in January ends in March, precisely matching what I set here. And so the idea here is that imagine these issues didn't exist yet. And I said that I wanted to accomplish this feature within, you know, the first quarter of 2019, I would set these dates, and then I would view it here. And it's a forward-looking plan. It's not, it doesn't reflect what's actually happening, but it's a plan forward into the future. So you can see this is my particular roadmap of EPICS. And you can see I've planned a lot of things far into the future. And many of these, I've put a fixed start date and a fixed end date. And then there's another type of start date and end date, which are dynamic, which I'll get to later in this video. But I just wanted to mention that the way that I do top-down planning is I've created an EPIC. I don't know what the scope is. Yeah, I haven't really fleshed it out. Maybe there's one or two EPICS, maybe it's just a blank EPIC with zero issues, but I can set it far into the future with a start date and end date. And I can communicate, which this is the important part, I can communicate this roadmap, you know, to more senior executives within GitLab. I can communicate this to my peers and other product groups. I can communicate it to the engineering team that's working within plan or other engineering teams, or just anybody within GitLab. And also just as important, I can communicate with the outside world because we work transparently, and this is, you know, everything I'm showing to you is public on the internet. I'm not on, you know, some private VPN. I'm just connected to the internet on my computer here. And so this is a roadmap view. And so say I have this roadmap view and, you know, these EPICS are far into the future, so I probably don't have to worry about them right now. It's planned for the future. I, you know, talk to the engineering teams. They think it's feasible and makes sense. That's fine. But say, you know, it's, you know, I got to work on the next, you know, I got to start work, maybe flesh out the actual work for the EPICS that are coming up. So this red bar, so today is October 19th, if you see my screen right here, and then that's smack right here. So these EPICS probably should be fleshed out, or the ones coming up should be fleshed out really soon because we're going to work on them per this timeline, right? And ones that are, you know, have started in the past, we're already working on them. So what do we do at GitLab is we, you know, like many teams and organizations, we work in sprints or iterations in the agile terminology. And so in GitLab, we work in one month sprints, we start on the eighth of a month, and we end on the eighth of a month, or, you know, the seventh actually, so we go from the eighth to the seventh, the seventh is the code freeze. So we work in one month sprints. And within GitLab, those are called milestones. So I'll show you what that is here. So we have a bunch of milestones here. As you can see, we have the 11 point, one milestone, 11.2, 11.3, and so on and so forth. And so they go from the eighth to the eighth, and then for two more weeks. So the way we, we, there's a little, you know, technical nuance here, it goes, it looks like it's going six weeks because the month is the coding sprint, and then there's two more weeks to do where we harden the code, and then we do a release. So suffice it to say that we do one month sprints at GitLab. And so how do we turn this epic into milestones? Well, it's actually pretty simple, right? So say that I have this particular epic. So this one here, and you can see all the issues here. So what we do is we look at a different view. And so this is where it gets very interesting. We look at something, what we call issue boards inside GitLab. And so I'm going to switch to a different view here. So we looked at epics, we looked at roadmaps, and we looked at issues. Now I'm going to show you a road, an issue board. So an issue board in GitLab is similar to a combine board or an agile board, but we've taken it to a whole new level so that you can use boards for many varieties of things. So right now this is not a combine or agile board, because the lists are not workflow stages. Instead, these lists are milestones, right? So you can see it's the 11.6 milestone, the 11.7 milestone, the 12.0 milestone, 12.1 milestone, so on and so forth. So these issues are issues that I care about, and that I've actually already slotted to be worked on in the 11.6 milestone. And by the way, I've already filtered this by certain issues, so they're not all issues in GitLab. I've done some filtering to relevant to my team. But anyways, so back to this point, so in the 11.6 milestone, I've already scheduled 10 issues or slotted 10 issues in worth a total of 11 points of weight. So at GitLab, we also have story points. So you can see this issue has five story points, this issue has three points, this issue has not added any points yet. So it's zero when you do the math here. And in GitLab, we call these weights. So that's why you have this cool looking weight symbol, but they're equivalent to story points in the, say, the agile world. And so this 11.6 is the 11.7. And what's really awesome in this board is you can drag the issue from one place to another. So I'm not going to do that, because obviously this is production data, and I don't want to screw things up. And so, but you can drag issues from one column to another. So say you're talking, not say this is me, you know, this is what we do at GitLab. I've already communicated with the engineering managers, and they've told me like, you know, what's the capacity, and so on and so forth. So within the product plan area of GitLab, my particular team, we have a sub team that works on portfolio management. And we know approximately that they can accomplish, you know, x number of issues or x number of points. And so this is a, you know, a conservative estimate. And I've already gotten ready and started planning 11.6. So 11.6 hasn't started. So in our process, we don't we don't freeze the scope yet. But as we get closer to kickoff, which is the 8th of November 8th, then this will be frozen. And, you know, per our process, you're not supposed to add additional issues. But what I wanted to show you here is that you can already, even though you're, you haven't planned, you haven't gotten to the future, you can already start planning. So 11.6, 11.7, 12.0, and so on and so forth. What's really interesting is we have another list called the backlog. And so you can, these are all the issues that are not slotted into a milestone. And we've used the GitLab milestone, but we have a named backlog. And if you click on black log, you'll see that there's actually no dates. And so that we have that flexibility there. Also, very pertinently is you, this is how you can do backlog grooming. So in, you know, in the agile world, you want to take your backlog. And so we've named this milestone backlog to convey that idea. And you can move issues around. So I can move them up or down. And what that does is once I move something around, it saves to the system. And that represents your ordering and your priority. So again, you know, remember sort of the agile, common board, and how, you know, when these ideas were first developed, a lot of these digital tools did not exist. And people actually did them on physical white boards and use stickies. And you have to move stickies around to represent these things. This is exactly that concept of boring from that physical analogy. And so this is what is pretty cool. It's not an agile board, it's not a common board. It's a, it's a milestone planning board, as well as a backlog grooming UI. A different, so what we did in GitLab is that we took this same interface. And we've also applied it, of course, to the typical agile, you know, Kanban style board, where you have in development and review and QA and UAT and so on and so forth. In particular in GitLab, we don't have that many stages. We don't have that many rigor stages. We have QA. We have, you know, we have folks who are verifying the feature. We have code review, which is the stage, but we don't have, you know, five or six stages in GitLab in particular. So that's why we only have two stages here. And that's why, you know, this board looks a little bit sparse. But what's really, really interesting is that it's the exact same UI, right? So if you go to this board and click edit, you can further filter and associate with the board with the plan issues, which I've done. And I've created another board here called 11.5 plan workflow. And I have scoped it to the plan issues. But notice I've also scoped it to the 11.5 sprint. And by doing that, this becomes your exact agile workflow board that you see in many tools out there, where you have, you know, like I mentioned, you know, in dev and QA and review and so on and so forth. And you're dragging the issues. And of course, you can drag these issues over, which again, I won't do. But once, you know, you know, this particular engineer has finished this issue. And they're assigned to this issue by this avatar. You can see they will drag this issue to in review. And then once it's done, they will drag it to closed. So, so you can see with GitLab boards, you already, it's versatile to serve two use cases, the milestone list and the workflow board. And I'm going to actually show you a third, a third use case. And this third use case is pretty awesome. It's what I call the assignee board. And so what you have here is again, sort of the same idea with a pre filtering. So now I filtered by the plan label, the 11.5 milestone. Again, I'm, I'm, I'm caring about this particular sprint. And I further filtered it by the back end team. And so at GitLab, our teams are further, you know, from engineering side or further split up from a front end team and a back end team. And they're each with a respective engineering manager. So that's why we have this particular board so that that team can work closely together. And you'll notice that every list now is not a milestone, it's not a label, but it's a, it's a person, it's an assignee. So these are all the issues that are assigned to Felipe for the 11.5 milestone. And so you can see all the work that's assigned to Felipe. And you can see that they have six issues worth 17 weight. Yarka has five issues worth two weight and so on and so forth. So you can see at a glance what everybody is working on, you know, if Brett, you know, you know, needs to take, you know, emergency leave for whatever reason, then maybe Yarka can can jump in and help and maybe Sean, the engineering manager, who is also represented here, who doesn't have any work because, you know, he's full-time managing, then he can maybe drag an issue from Brett to Yarka. Or maybe Yen says, you know, oh, I'm finished all my work. I can, I can help. And Yen says, oh, you know, Mario, you're working on this. It looks like it's taking a long time. Do you need some help? Why don't I drag the issue over to my column? And I'll start working on that. And maybe Sean will actually start doing some development of his own. Maybe he needs to jump in and he can do so as well just by dragging issues. So this is a very helpful assignee board. So, so, so we have assignee boards, we have label boards, and we have, which, you know, represent workflow, as we saw in this case, and we have milestone boards, which represent backlog grooming and dry and managing issues across sprints. So essentially sprint planning. And what's interesting is that you can do that, you can actually have mixed boards, if you wanted to get very, you know, excited and innovative. And so all you have to do is just add a label list, an assignee list, or a milestone list. And once you do that, you can click a button here. So if I wanted to add Winnie here, and, you know, he's not on the particular, the plan backend, he means on another team. But if we wanted to say, like, oh, let's bring him in and have him help out, we could do that. Or I can, you know, put in a milestone list with the assignee list next to each other. So there's many more use cases that that could happen. I don't want to dig too deep into that, because this video is going to get very long already. But you can see the power of boards at GitLab. So, so we've covered up to now we've covered issues, we've covered, you know, sprint planning, backlog, grooming, we've covered workflow tracking, in particular, you know, this case where you're seeing issues being moved over, and you can see the points moving over. And then I also wanted to mention really quickly, we have a burnout chart as well. So this is the 11.4 milestone, you can see the issues burning down. So again, very stuff that you would see typically in a agile PPM style workflow is all within GitLab. And, you know, that this is GitLab's vision and strategy is to provide all the functionality in one place. And of course, today, we're just talking about portfolio and project management. We're not even talking about the other awesome features and functionality of GitLab. And we're just restricting to PPM for today. And I'd like to wrap up by saying how this all comes together back at the epic level or the portfolio level. So what's really, really interesting is that say I planned this issue far in the future, Gen 8, March 22nd. And then later on, I've actually scheduled these issues into milestones. So rather than do that here, because again, I don't want to mess up this production data, I'll show you a epic where that's already been done. And you can see that this is an epic that's ongoing, this epic called close epics. So if you look all the way here, it has already started and it's ongoing. It's targeted to be finished in late November. And the reason why that date is here from, you know, late August to late November is that we didn't use the fixed date anymore or more accurately once we started this epic and started scheduling the issues or planning the issues into sprints. We and in GitLab sprints are called milestones. What we did was we clicked a button called from milestones for both the start and due dates. And what that does is really amazing. What it does is that it sucks in the milestones that have been assigned to all these issues. And it says like there's one, two, three, four, five, nine issues here of all these nine issues. Look at all their milestones and find the milestone with the earliest start date. That particular start date is turns out to be September 8th and turns out that milestone is 11.4. So that's exactly what this is. And analogously, on the other side, the latest date is November 22nd. So this epic turn from a top down planning epic that you schedule for the future and it became an actual, it became an actual, became a reflecting what the work is actually scheduled. So that's really amazing because now this is your single source of truth. You don't have to use separate tools. You don't have to say that. I'm using one tool to do portfolio planning and having a roadmap view. And then I don't know if that actually reflects the issues. Everything is reflected here. And then so the, so the, so the final use case I wanted to show, which is or click through, which I think is pretty awesome is that you have your epic view, your roadmap view here. Like I mentioned, you share it with the world. And in particular, this is shared with the world. But anybody here. So, you know, in the case, maybe it's your, your CEO, your executive, a C suite. And they're looking at this particular roadmap view in many tools. That's all they can see. They see this view and they don't, they can't find the details or maybe they don't even know if this is a source of truth because the data is not synced up because you're using different tools. But with gildlab, everything is synced up automatically. We get that for free. It's almost cheating. And the reason is we use one database. And in particular, how that manifests itself is that suppose you're looking at this roadmap view and you're saying, Oh, this, this epic called closed ethics. It seems pretty interesting. I want to click through and find out more about it. And in particular, I want to find out why it's going to end in November, or more, maybe I want to know, you know, how it started and, you know, who, who is doing the development. I just want to find out more information. There's just this bar is not enough. So the person just, you know, it could be me. I just click on the epic right here. Boom. It goes into the epic. And I say, Oh, wow, there's a lot of great information here. I can see the labels who's been chatting about this. I am receiving notifications for this epic. But more pertinently, I can see, wow, there's all these issues that are in scope for this epic. And then I'm going to click on one of those epics. So I'm going to click this epic close and reopen epic via quick action. And I'm going to see that, Oh, wow, this, this issue was created a long time ago, as you can see. But what's also interesting is that it was, it was scoped for 11.4 milestone. So it's already closed, meaning the issue is already merged into master. And part of this milestone, that's going to, going to end really soon in two days in particular, you can see, and wow, oh, okay, here's the actual code at support for closing epic. So I'm going to go to there and click there. And I can see, Oh, wow, okay. So, you know, this was started by Kushal on the front end team. It was last assigned to Douglas, so he probably was responsible for reviewing the code because, you know, at GILLAB, that's, that's what we do. We assign it to, for merge requests, we assign to the reviewer. And I can click through and see the details. Wow, look at all these details. I can see approvals. I can see, you know, some CICD information. And I can see all the the gruesome details of this merge request. I can see the actual code diff. And I can see, you know, there's 38 discussions that were made previously. So I can see the code diff here, you know, this is again, a new awesome feature. And so I'm even beyond the, the planned stage of the DevOps life cycle right now. So this is a bonus material as it were. So I can see the diff. I can see all these things that were made. I can see all the commits that were made. And I can see all the people that were participating. And so, so to me, this is pretty amazing because we went from the epic high, high, very high level strategic view, the CEO view of the roadmap view. And we want, we went all the way to, to the commit level, to the actual, as you can see, we can, to the actual commit, to see the actual code diff. So I think this is a very powerful feature. And so I'll leave it at that. So that wraps up Agile, PPM or GitLab project portfolio, GitLab portfolio project management. Apologize that. And yeah, please check out all the features we have at GitLab, visit about.gitlab.com to get more information there, visit our documentation to learn more. And I hope to see you again next time. Thank you.