The GitLab DevOps lifecycle contains the Plan stage. The product vision of Plan is to enable all people in any size organization to:
This product vision is achieved through several product categories collected into groups.
In the Team Planning group, we have the Project Management, Kanban Boards, and Time Tracking product categories. These are focused on helping individual product development teams deliver tangible business value to their customers, by enabling them to ship software, and in particular, the most important priorities, at a high velocity, sustainably over a long-period of time (avoiding burnout). Kanban Boards will increasingly play a crucial role here, with teams congregating within one or several boards that serve as a central location for collaboration, progress tracking within a sprint, and even retrospective evaluation afterward. Project Management improvements will continue to be the glue that ties issues and their many attribute objects together, including labels, milestones, weights, and assignees. Time Tracking is a strategic area to incorporate management of the most important resource of Team Planning, namely that of individuals and their valuable time.
In the Enterprise Planning group, we have Agile Portfolio Management. Agile Portfolio Management builds on Team Planning by helping multiple teams deliver a coherent experience for customers, with potentially many different product and services. In particular, a portfolio of initiatives are managed at the director level, and even at the executive level. Agile Portfolio Management will thus be focused on work breakdown plans that support both top-down and bottoms-up planning, as well as help business sponsors make crucial decisions of where to invest resources that have longer-term business ramifications, using ROI analysis, resource planning, financial management, and other tools.
In the Certify group, we have Requirements Management, Quality Management, and Service Desk. Requirements Management will help organizations with more rigorous requirements planning to track and manage changes and traceability of their intended software (and even hardware) capabilities. Quality Management will help organizations maintain processes and artifacts to manage and track software quality. Service Desk will continue to help the customers of GitLab to easily send in feedback, whether it be bugs, performance problems, or general feature requests. In particular, Service Desk will be improved to truly realize the vision of bringing customers, support teams, and product devlopment teams all closer together within one tool, in order to reduce DevOps end-to-end cycle times and create the right software.
See many interesting features coming in 2019, as of late December 2018.
There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.
Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.
Plan, organize, and track project progress with issues, kanban boards, labels, weights (story points), milestones (sprints and releases), time tracking, due dates, and assignees, using Scrum, Kanban, SAFe, and other methodologies. This category is at the "viable" level of maturity.
Visually prioritize, manage, and track work execution with powerful and flexible kanban boards. This category is at the "viable" level of maturity.
Estimate, track, and report on time spent on issues. This category is at the "viable" level of maturity.
Plan and manage strategic portfolios, programs, and projects with multi-level work breakdown epics, roadmaps, and milestones. This category is at the "viable" level of maturity.
Gather and manage the use cases and requirements to meet business objectives. This category is planned, but not yet available.
Plan and track testing and quality of your product. This category is planned, but not yet available.
Connect your team using GitLab issues, to external parties directly via email for feedback and support, with no additional tools required. This category is at the "viable" level of maturity.
The overarching goal of Plan is to have GitLab be the primary planning tool for successful medium and large enterprises of the future. In particular, see specific timeline targets of category maturity levels in Plan, representing goal metrics of 2019.
We also aim for the following placements in analyst reports (if they will be published in the given year):
|Gartner Enterprise Agile Planning Tools||Visionaries||Leaders||Leaders, above all other providers|
|Forrester Value Stream Management Tools||Strong Performers||Leaders||Leaders, above all other providers|
Our overaching goal is specific to successful companies of the future. This is a goal aligned with the vision of GitLab, to allow everyone to collaborate on all digital content, since we believe successful companies will drive the innovation of digital collaboration more broadly.
It's an ambitious and relevant goal since successful companies of the future will be digital companies, with software becoming a key business enabler, if not a key business driver. Since software is eating the world, all successful businesses will undergo digital transformations. Conversely, a business may fail for many reasons, and one of them will be a lack of digital transformation.
It's a goal with expansion built in, since we are currently in the midst of a digital transformation. Silicon Valley style tech companies have already shown the software industry how an Agile DevOps approach to product development is a significant benefit, if not key differentiator, to growing a business. Now medium to large businesses who use tech but aren't fundamentally tech companies across many different verticals need to undergo digital transformations of their own. Those who fail to do so will not survive. Those who are able to transform will have renewed opportunities. We want GitLab to be at the heart of this transformation, helping all these businesses realize the promise of Agile DevOps.
So while GitLab may serve businesses today, our focus is on becoming the primary planning tool of successful companies of tomorrow. And that very distinction informs our strategy.
Our strategy is not to compete with existing vendors head-on today, and definitely not on a feature-by-feature basis. Tools such as Jira, Trello, and Clarity CA have been in development for a long time, and have amassed significant feature sets. Convincing customers to choose GitLab over these tools based on feature comparisons is not a good strategy, at least not in isolation. GitLab is a newer application and does not have all these features. We would typically lose in these isolated comparisons. Furthermore, by trying to achieve parity, we would be building features focused on existing workflows of current companies who have been using these features for a long time, even features that are antithetical to Agile DevOps.
Instead, our strategy is neatly summed up with three parts:
We believe that the future of an Agile DevOps style transformation, as it pertains to running a successful business, involves continuously planning, breaking your plans based on feedback, and re-planning. Planning is important to align your business goals and internal operations. It's a way to bring some semblance of order in an otherwise chaotic business context impacted by uncertainty from many sources. At the same time, plans need to be continuously broken (voluntarily) to adapt to new information. A successful company thus can perform this plan-break-plan-re-plan cycle at a high velocity, capturing business opportunities ahead of competitors, and even creating new markets along the way. This is exactly what we believe the future of GitLab Plan facilitates. Project Management and Agile Portfolio Management (with Kanban Boards too) are the key product categories that allow businesses to manage all this information. We are architecting these information systems not for rigidity, but for flexibility. Plans are made to be broken. A business culture should incent constant revision of plans based on the latest information available. And we believe GitLab should be a tool that encourages that very ethos.
These are inherently big risky bets, because many customers are just starting their digital transformations, and don't believe or recognize that they should be moving to these future ways of working. We are building features that customers may not want now, or may not even want in the future, because even though we have high confidence of this future vision, we may not get all the granular details right. At the same time, this prioritization also specifically means we are not building certain features that customers want now. So, to mitigate these risks, we are taking customers on a journey, and traveling together. We are closely collaborating with strategic customers who understand the future of Agile DevOps. In particular, these are large enterprises who recognize the plan-break-plan-re-plan approach, and are doing the best to adopt these new ways of working, even as they struggle internally to make those transitions. We are partnering with these customers to shape our roadmap, implement specific future-vision-type features, and having them closely participate in our product development. Through these partnerships, we will identify the details and build the relevant features that future successful businesses will eventually adopt. And thus, we will win tomorrow, since we are building the future today, ahead of competitors. In addition, some customers are open to new ways of working, and trust GitLab for guidance. These are also key collaborators that have an open mind and are willing to give GitLab's version of the future a shot, today.
The final part in our strategy is leverging our GitLab-wide single application approach. If we are focused on strategic partnerships to invent the future, it means that it is harder to win customers of today, especially if we are not catering to their needs specifically. Fortunately, GitLab is already a leader in SCM and CI. Customers are already buying GitLab for these features, and often these customers naturally transition their project management and even portfolio management needs over to GitLab over time. Furthermore, since GitLab pricing tiers do not silo product areas, the friction of adoption for GitLab Plan is very low for these already-paying customers. Thus, this already-installed-and-available advantage also offsets some risk of focusing on the future, and increase usage of GitLab Plan today.
Over time, many of the market leaders in the project management space have implemented features that have introduced a large amount of complexity into the system. Complexity introduces the following challenges:
A great example are the four problematic features Fogbugz identified on slide 11:
We strive to have users getting value out of Plan within a few clicks. As such, we are strategically not implementing features that may garner additional marketshare from legacy project management tools in the short term. We believe taking a long term view and re-architecting this space is the proper way to help software development and DevOps teams plan work.
GitLab supports deep Jira integration, allowing teams to use Jira for issue mangement, but still leveraging the benefits of GitLab source control and other native GitLab features.
We follow the general prioritization process of the Product Team. In particular, we consider reach, impact, confidence, and effort to identify and plan changes in upcoming milestones (monthly iterations).
All GitLab team-members use Plan features, more so than other GitLab stages, so it's important we are continuing to support GitLab team-member workflows and prioritizing them. See issues scheduled for the next few milestones that directly benefit GitLab team-members.
There is a video call weekly meeting where any stakeholder can bring up topics relevant to Plan. Usually, at least the product manager, engineering managers, and designers attend this meeting. Engineers will often attend this meeting (if they can, depending on timezones), as well as other folks such as product marketing. Throughout the week, if there are other video calls necessary to discuss specific topics, Plan folks create them, inviting specific individuals to collaborate, but they are open for all to attend.
All other collaboration happens asynchronously in GitLab issues and Slack (#g_plan).
We love community code contributions to GitLab. Read this guide to get started.
Please also participate in our issue tracker. You can file bugs, propose new features, suggest design improvements, or continue a conversation on any one of these. Simply open a new issue or comment on an existing one.
notin issue/mr/epic list views and boards Premium
There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!