GitLab Source Code Group, 28 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Torsten Linz - Sr. PM - Create:Source Code a Proposal for Prioritization&Planning

Description

https://gitlab.com/groups/gitlab-org/-/epics/6592

A

Hello, this is torsten, I'm addressing the source code group. I have thought about privatization and planning, and I want to share my thoughts and ideas.

A

So in the past, what we have done is we have typically created a planning issue. It looks like this and I've recently added, basically the key themes that tell the story what the certain milestone is about.

A

What this gave us is a clear view on a specific milestone, but it didn't give us a clear view of what's coming after that milestone and after that milestone.

A

So we didn't have a very good predictability and view of let's say what's coming in the next three month, and I hope that we can change this um and here's my proposal how to do this practically and really consider it only a proposal. Please criticize it and let's, let's work with it together, so that we can make this better.

A

uh So the idea is that we use this epic, uh under which we had linked uh those different uh planning issues and that we use that for our a bit more long-term planning.

A

As I said, the goal should be that we have a prioritized backlog that will carry us three milestones and basically, we have uh two lists in here and what is higher in the list has a higher priority very simple um and by the way this is really nice. If you think this one is higher, you can just move it up right. So this is a nice functionality of the issues that you can move these lists up and down for each entry.

A

We should have enough information that we can easily assess the priority and compare two entries and say which one is more important. In many cases it will be enough to have the title and maybe also the labels. In some cases we want to add additional information. Like uh you know, this is addressing a specific customer risk.

A

Something like that, and what's also very helpful, is of course, the effort right. So we need to know for the planning how much effort it is so that we know does it fit into the capacity, and I add the effort, just as a simple number after the title.

A

Yes, so we want to prioritize given the guidelines from the company around next prioritization. We want to prioritize features and bugs and maintenance separately, and so that we can look at that. We can make a deliberate decision on what should be the percentage of features and what should be the percentage of works and maintenance.

A

uh I think the mix we have to find for our group. We are more mature um than many others, so I expect there is less feature work happening than for a team. That is, you know, starting a new category. That's all feature and no maintenance.

A

Of course um we'll have to find that that right mix for us, then I think we need to distinguish two types of bugs those bugs that reduce risk are typically labeled, with availability, limit security and infidel and those that address customer issues, and I think in the recent month we have focused a lot on the first one and we need to find a good balance between these two types of bugs.

A

Then, of course, we want to honor our gitlab value collaboration and we have other teams in the company that need our help and we will make our best to prioritize that work as well and then. Finally, this goes a bit beyond privatization.

A

We can put tentatively a milestone, so, of course, if something is deliverable that milestone is set, and it's likely to happen in that milestone.

A

um Of course, this is not a commitment as we know, but then we have those those things that are farther in the future and we could even say okay. This is going to happen in 15.4 and this is more tentative and we should aim to get this right better in the future. So this is about privatization.

A

Then the next question is: how do we plan a milestone? So here's my proposal when we start this planning, we first mark all the issues that are likely to slip with a red dot so that we are aware of it.

A

Then we uncheck all the boxes here, these boxes we can use and or this is the idea we use them just for the planning just to facilitate discussion between me and the engineering managers. um What do we want to add to the milestone?

A

And basically we go through each list and let's say we make a plan for 50 50 features, 50 of the capacity and bugs 50 of the capacity, and then we would just go top down and mark those that we want to add here for since I I've added those already, but you can imagine, I would just add those, and then we count uh the number of weight story points and once we've reached, for instance, those 15 points that would be half the capacity of the back-end team.

A

We would stop and we would make that the plan for the milestone- and uh probably we would do that in two separate steps for front end for back end as we have done in the past and once we're happy with our checkboxes here and we think okay. This is a good plan for 15.3. In this case, we would label these as deliverables and also add the proper milestone and remove the 15.3 from all those that didn't make it in and, for instance, change it to 15.4 or something else right.

A

That's basically it. Let's see how this works. um Oh yeah, I forgot then, once we've we've made that plan. I would create such a planning issue here, and this is more for the purpose of storytelling, what's going to happen in a milestone for the benefit of the team and also for the benefit of the customers, so that it's a bit clear what are the themes of the milestone, and that would be the main purpose of this all right. Let's see this works.