 Our first talk of the day for GitLab Commit at KubeCon comes from Melissa Ushikov. Melissa is a group manager of product management for GitLab's plan and ecosystem groups. Prior to GitLab, she served as a senior product manager at AgileCraft, which was acquired by Atlassian, and led teams building software to help organizations plan and execute work. Melissa is passionate about using software to create environments where everyone can contribute. In keeping with our theme of innovating together on the DevOps platform, Melissa will give us a product update to share where GitLab has come over the past year and celebrate some of our community contributions and major features. Then, Melissa will give us a deep dive into the plan stage at GitLab, along with some of the roadmap for some of the exciting features to come. As a product leader for this stage, she'll share how she approaches building a software planning tool that is a core component of the DevOps platform and some of the unique experiences and workflows that arise when everything is in a single application. Hi, good day, everyone. My name's Melissa Ushikov. I'm the product manager, I'm a group manager and product for the plan and ecosystem stages. Before we get started, I have a required slide to share. We plan ambitiously and our roadmaps are subject to change without notice. Information presented in this session should not be used for the purpose of any material purchase decisions, nor is it a promise of any sort. All right, now that that's out of the way, let's get started. Welcome, I'm excited that you're here and I'm humbled that you took time to attend my session. We have a lot of stuff to cover. I'm gonna start off by sharing some of the recent enhancements that we made to GitLab. I'm then gonna walk through the themes for the upcoming year. And finally, I'm gonna do a deep dive on plan in GitLab and talk about our roadmap. I even have some small segments where you can participate via chat and you can influence our roadmap. All right, let's get started. I wanna start by highlighting our amazing community. Over the first eight months of this year, you've contributed 2,200 improvements. That's 464 more than the same amount of time last year. And actually, April of this year, shattered the record for most contributions in a single month, so great job. Each month we announced an MVP that has contributed in an outstanding way to help make GitLab better for everyone. And I'm gonna highlight the last six MVPs. Five store made numerous improvements to GitLab pages over the last four months. Cornelius added the original GitPod integration and expanded it by adding an option to open code changes in GitPod from a merge request. If you haven't tried out GitPod, I encourage you to do it. It's great. Andrew helped improve the usability of epic initial boards by adding more data to them and even sorting options. Matthew contributed significantly to the package stage with his work on the Davian and Helm package registries. Lee added a time tracking report feature and it allows you to see who has spent time on an issue and you can even add notes. Yogi made multiple contributions to GitLab status page and improved its performance and polished the UI. Let's give our MVPs a virtual round of applause. I also wanna thank the entire community for believing in the vision and innovating together. I think it's incredible to have a group of people around the world that's helping shape the future of DevOps. It's really hard to summarize all of our recent releases in a single slide, but I tried anyway. I wanna take a few minutes to highlight some of the significant improvements that we've introduced in the last six months. This crowd may be particularly excited about the GitLab Kubernetes agent and it's now available on gitlab.com. The deployment frequency chart helps you understand the efficiency of your deployments over time. This way you can find bottlenecks and focus on improving your practices across your projects and teams. This feature is a part of our effort to natively support Dora4 metrics in GitLab. Now remember how I said I work on the plant stage? I'm biased, but I think Epic Boards are game changers for visualizing and tracking higher level planning and we're gonna talk a lot more about that later on. We have another Kubernetes feature that I thought this crowd might like. CICD tunnels for Kubernetes clusters enable versatile GitOps workflows where deployment logic can be coded in the pipeline. This next one I'm really excited about as well. I'm not a markdown expert. So for me, being able to see a live preview of my markdown while I'm editing is huge. Project level DASP and Secret Detection Execution policies allow security teams to be able to manage scan requirements and not developers. So they can't change them. And this has been something that's been long requested from our security-minded organizations. I'm gonna put links in chat to the release post for these features so you can take a look and decide if you wanna try them out. All right, we're gonna switch gears and talk about the future, but first we have to talk a little bit about the past. Over the last decade, product development has changed and now there's a lot of different specialized roles involved in making great software. At GitLab, our vision is that everyone involved can share the same context in the same environment. This will lead to increased collaboration, innovation, and efficiency. It's our big, hairy, audacious goal to make GitLab the most popular collaboration tool for software development in any industry. That's really exciting for me. In order to serve a diversity of personas and users in GitLab, we wanna reduce the time that you spend on activities that don't directly contribute to your organization's goal. Therefore, we're focused on improving our SaaS offering so that you don't have to take care of upgrades and updates and can enjoy a managed, secure, reliable, highly available GitLab environment. We also found that in order to bring everyone from designers, marketeers, program managers, ML engineers, to developers onto the same platform, the experience has to be frictionless and intuitive. So we're spending significant effort on improving usability. And finally, we believe that finding and triaging and fixing security issues as early as possible is the only way to avoid an existential security crisis. So we're focused on providing you with world-class application security testing capabilities. Those are the themes that are guiding our next year of innovation in all of GitLab. But now, I wanna do a deep dive into the big problems that we're tackling within the GitLab plan stage. The plan stage aspires to build robust planning capabilities that tied directly into the website cycle. Our goal is to empower teams to continuously deliver customer and business value with the shortest possible cycle times. In our roadmap, we are leaning into the adoption through usability theme, and we're making really significant improvements to our existing functionality. Our hope is to address the concern that I'm sure has crossed a lot of your minds. How can we spend less time planning the work and more time doing the work? Like I mentioned earlier, delivering software is a team effort and it involves a lot of different people in an organization coming together. Effectively planning and tracking work is critical to deliver value in a timely manner. A lot of times, teams struggle to collaborate because of silos created by tools. This space is really exciting for me and I'm gonna take a small walk down memory lane, y'all can come with me to explain why I'm so passionate about this. Before I was a product manager, I was a program manager in a really large organization and a big part of my job was making sure that our leaders had status information about our key project. This resulted in me spending a lot of time parsing through different planning tools and tapping people on the shoulders just to get the details that I needed to make status reports. I personally really hated interrupting people's work just to get a status update. And the worst part was that the minute the ink had dried on those reports, they were out of date. And this is because when your coordinated activities are crossed the company with hundreds of people, things happen every day. At the same time, I know that our executives needed this information because they needed to make decisions like staffing, funding, they could help us remove blockers and it was even important for them to reset expectations with customers if needed. I really hated that this process was so ineffective for everyone involved. Now my husband, he's an engineer. So I hear the other side of this too. He is frustrated by having to step away from his work to provide status to management. The silos created by separate tools, they're a huge contributing factor to this problem. And as a result, I've spent the latter part of my career devoted to building tools to make planning and executing work as painless as possible. As a DevOps platform, GitLab has a unique opportunity to help teams make better decisions, have more visibility and deliver more value. GitLab is the place where all of the team's information comes together and you can create a shared understanding of work. Building and maintaining software at scale requires cross-functional collaboration. A lot of organizations use point solutions integrated into a do-it-yourself tool chain. As organizations grow and progress in their agile transformation journeys, this approach is challenging. Tools get out of sync. There's lack of visibility for various roles at different levels and overall, collaboration and communication is inefficient. One customer recently shared with us that they had unintentionally reverted back to talking about software requirements using tools like email and PowerPoint. And this is because they were tracking their work with three different planning tools. In the past, I've worked with organizations that have dedicated teams to maintain and triage integrations between their planning tools. They spent significant time investigating data sinkers and eventually they lost trust in the data. I'm wondering if this sounds familiar to any of you. We believe that planning end-to-end in a single tool will lead to better results. We wanna eliminate silos between people and tools and that means that we have to consider the modern product team. For us, collaboration between engineers, design and product is essential to a great outcome but that's just the start. Up to this point, GitHub had spilled planning capabilities around three distinct objects with different behaviors on each. We offer requirements, ethics and issues and this has unlocked a lot of value. However, we've learned from working closely with our customers that having separate objects with separate behaviors on each has resulted in some usability challenges. For example, epics are only available in groups. Issues are only available in projects. We have assignments on issues and some customers need studies on epics. These are examples but there are a lot of subtle differences between our objects. At GitHub, we dog food our platform so we feel this pain. I can't tell you how many times I've tried to create an issue but then I find I can't because I'm working within a group. In some cases, we ended up duplicating features so that we can achieve parity and ease customer pain but this is not really an efficient approach. So we took a step back and realized that we need to make some changes to simplify the planning system within GitHub. We're working toward consolidating the objects into a more flexible approach using work items. Instead of maintaining distinct objects with special properties, we're merging the objects into a single core work item. Work items will give you all the great functionality that we have in separate objects in a single place. You'll be able to create work item types with distinct properties and work item hierarchies to represent different levels of work. We're also planning to introduce custom fields. This will allow you to capture and define information that your organization needs to plan your work. Status is gonna be a first-class experience so we can better support progress reporting and automation and we're gonna talk a lot more about automation in the next few slides. One of our product principles at GitLab is that things should work by default. So that's our plan within plan. We're gonna launch with some default work items like requirements, issues, features, epics. The difference will be that they'll be powered by the same underlying model. Down the road, you'll be able to create your own work items so your team can use the framework of your choice. We know that organizational change is hard, especially when it's about team processes. Using a flexible model with nested work items and time bounds, our goal is that you can onboard quickly and painlessly. We have strong signals from our customers that they want a planning tool that supports their processes but is not overbearing. Some recent conversations include an enterprise company that wants to consolidate multiple planning tools into GitLab. Their current setup has complicated enforcement or close and data integrations that make their tools really difficult to use. We also talk to a bank that's going through the process of migrating most of their teams to GitLab. They're leaving behind their highly customized planning tool. Our planning capabilities are lighter weight and increase developer productivity and collaboration. Now let's talk about how with some of the features that we're implementing, your team will be even more efficient if you use GitLab. If we set planning frameworks aside, planning DevOps work where DevOps works happens will lead to more transparency, traceability, and collaboration. You can track work end to end. So no more tapping people on the shoulders, jumping between tools, setting up integrations, just to understand the status of work. Today in GitLab, you can already associate a merge request to an issue without any special configuration. Remember how I said we dog food our tool? This is one of the features that I really enjoy. In my time at GitLab, I've found so much value in this. I'm able to follow work along in our issues without talking to an engineer. Since we're globally distributed, there's not a lot of times in a day when the whole team overlaps. So having this information and being able to self-serve is so valuable and it helps me honor our value of working async first. My dev team also benefits from the setup because they're able to mention me on merge requests when, you know, if there's ever code changes and functionality changes proposed, shared context makes collaboration a lot easier. Another feature that helps with traceability and is really helpful is design management. UX designers can attach a design to an issue and we can collaborate directly in the context of an issue. The great part about this is that the whole team can see what's happening and jump into the discussion if they have an opinion. It also keeps the context of why decisions were made all wrapped in an issue. The best part is this all takes place natively within GitLab without setting up any integrations. We want to take the spirit of these features and expand to foster even more collaboration. We want to make it easier for non-technical users to understand the status of work based on downstream DevOps activity. This data will be easy to understand for users that are not developers. We also want to leverage automation to keep work items up to date with the latest and greatest. Okay, so I have a small confession to make. At GitLab, like I said, we dogfoot our issue tracker and we have implemented a lot of automation to help with work and maintenance. Automation helps us label issues, leaves comments and mention team members based on an array of rules. Unfortunately, this currently lives outside the product in the separate of open source repository. We will work toward making this functionality available as a first-class experience in GitLab and reduce the manual setup required to enable it. Now, remember how I was going to need your participation? Get your pencils ready because now is the time. First, let's walk through an example of what this could look like. We already have some automations natively available in GitLab with our emerge request and issue linking capabilities. But we're going to lean into this concept much more in the future. Here, I show how we can automate the status updates and work item assignments on an issue based on MR approvals and pipeline statuses. A work item can be updated based on a linked and marketing approved and if a pipeline associated to a work item fails, we can also assign a team member so they can take a closer look. This is one example of what we can do with automation, but now I want to hear from you. I would love it if you could take one minute and type an idea in chat for how you think work item automation could reduce your team's workload. In case you need some inspiration to get started, remember how I mentioned labels? Think about how labels on a work item could be updated based on downstream DevOps activity. Alright, thanks in advance for your ideas. I'm excited to review them. Teams, planned work and actual work should not exist in isolation. A plan reflects a point in time potential outcome based on the information you have at that moment. However, we all know that things happen. The key is whether a team can change plans and pivot quickly enough. Using downstream DevOps data, we have an opportunity to highlight risk and potential disruption to your plans. It's time for your participation again, so pay attention. We're going to walk through an example of what this could look like. Here I show how we could potentially set thresholds on monitoring alerts and these could be used to inform engineering managers and product managers that they may need to reconsider their plans. If too many monitoring alerts are received, the team is at risk for missing their planned deliverables. So this would be a great time to reevaluate the work prioritized for a milestone and remove some scope. A high number of alerts can also be a signal that there may be some technical debt that needs to be prioritized. So we could surface this information in a team retrospective, which gives teams the ability to consider creating new work to resolve the root cause. Incorporating DevOps data into planning and prioritization processes allows teams to evaluate and prioritize technical improvements objectively. All right, same four minutes last time. I would love if you could take one minute to type into chat an idea for how downstream DevOps data could help your team make better plans. In case you need some inspiration, think about measuring the number of the plans during the number of deployments over time and if changes to that would necessitate prioritizing some things. Thank you all again. With accurate data that's more accurate with the help of downstream automation and as informed by DevOps data, there's less guesswork in your plans. Our existing epic boards and roadmaps give you higher level visibility into your organization's work and they will benefit from work item data that's more accurate. We have planned improvements, like I mentioned, to work item hierarchies so you'll be able to represent even more levels of your organization. You'll be able to drill down from an epic all the way to an MR on an individual work item. We also plan to introduce saved views so you can create and save slices of planning data. This is incredibly helpful when you're sharing a specific item with your organization. For example, the Q3 technical roadmap. Some of you in the crowd may love what you hear, but you're using JIRA, but don't worry, I will share some updates of what we've released and also what we're doing in the future. At GitLab we believe that our customers should have the freedom of choice to choose their tools. We want you to use what makes the most sense for your business and we will support you by playing well with others. Over the last year, we've improved our JIRA integration out of plans for a deeper integration. We have brought JIRA data to GitLab. In case you missed it, you can now view our JIRA issues list in GitLab. We also introduced the ability to create a JIRA issue directly from a GitLab security vulnerability. For developers whose teams leverage JIRA for project management, being able to view and create JIRA issues inside of GitLab reduces context switching and helps you stay in flow. We've gotten really positive feedback about this direction and you've shared that you want to see JIRA issue data in even more places. We plan to surface JIRA issues in key reports like value stream analytics and release reports. Fun fact, seeing JIRA issue data in value stream reports has actually become one of the top highly requested features for that report. And I'm actually not surprised because being able to see end-to-end idea to production is key in a report like value stream. We also now have more GitLab data in JIRA. We've improved our GitLab JIRA development panel integration and now you can see GitLab branches, commits and merger requests directly in your JIRA issues. We also recently introduced the ability to create a GitLab branch from a JIRA issue. We want to make it as easy and streamlined as possible to use both tools together. All right. It's time to put on your PM hat one last time. Same format as last time. What functionality could we add to make using JIRA and GitLab together easier for you and your team? That's the end of my presentation. Thank you for attending and I hope that you are excited to sign him about the future of planning in GitLab. I hope that you can see how planning your work using the DevOps platform will lead to better outcomes. You're looking at the entire picture. If you're interested in learning more or have some ideas after the session, you can always reach out to me with my handle at M-Ushacov. Thank you so much for your time. Have a great rest of your day and enjoy the conference.