- You are here:
- GitLab Direction
- Product Stage Direction - Plan
- Category Direction - Team Planning
The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Last reviewed: 2020-09-20
📝 Team Planning
Introduction and how you can help
👋 This is the category strategy for Team Planning in GitLab; which is part of the Plan stage's Project Management group. Please reach out to the group's Product Manager, Gabe Weaver (E-mail), if you'd like to provide feedback or ask any questions related to this product category.
This strategy is a work in progress and everyone can contribute:
- Please comment and contribute in the linked issues and epics on this page. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
- Please share feedback directly via email, Twitter, or schedule a quick Zoom for us to connect.
GitLab's mission is to build software so that everyone can contribute. Issues are the fundamental medium for enabling collaboration on ideas and tracking that idea as it turns into reality.
The goal of a Category's "Essential Intent" is to provide a concrete, inspirational statement. Another way to think of it is answering this single question – "If Team Planning can be truly excellent at only one thing, what would it be?" This is Team Planning's Essential Intent:
Empower teams to continuously deliver customer and business value with the shortest possible cycle times.
Next, asking "How will we know when we're done?" provides clarity of purpose. This is how we will know:
- Issues take less than 1 second to load and there is never more than a 1 second delay in propagating changes on an issue to any member; Members never interact with an issue that does not contain the most recent changes.
- Within 15-30 seconds of first seeing an issue above the fold, any community member can understand the purpose of the idea, that it is up to date and relevant, how it contributes to the wider community's purpose or goals, what the intrinsic value is, where it is in its lifecycle, what the next action is to move the idea forward, who owns that action, and that it sets a reasonable expectation regarding when the idea will be fully implemented that can be trusted with a high level of certainty. Issues that do not satisfy this criteria should not be trusted. Communities never have more than 1% of Issues that are untrusted and no single issue remains untrusted for more than 5 days. We do not rely on humans to determine whether an issue can be trusted or not, but humans are responsible for maintaining trust.
- Issues leverage autonomation to empathetically encourage wider community members to improve the quality of the issue, remove many manual processes involved with issue management, and help community members focus on contributing to the top 10% of ideas that will yield 90% of the total value for the beneficiaries of the issue.
- New ideas are always welcome from anyone (whether an end user, team member, or internal stakeholder), but they are never duplicated. This helps focus the diverse perspective from the wider community around a singular idea to yield the best possible outcome. We do not rely on humans to prevent duplication.
- Issues should be organized in a way that is easily discoverable and accessible to the community the issue serves; but also in a way that optimizes an individual's ability to interact with it based on their personal workflows and how they work best.
- Every single change to issues, including the configuration of data properties present on issues such as label and milestone management, are transparent, traceable, auditable, and easily reversible.
- Boards support other objects that move through statuses such as Epics and Merge Requests.
- Teams can automate the movement of objects between lists based on rules they define.
- Boards can be configured to support Timeboxed or Continuous Planning models with the click of a button.
- Changes to data on objects reflected on issue boards is propagated to all connected clients and rendered in under a second.
- Teams can reliably communicate when any object on a Board will be completed with 99% accuracy.
- Team Members can immediately understand what next steps they need to take on which object and in what order just by looking at the Card.
- Boards provide built in modes for various "Agile" practices such as backlog refinement, prioritization, conducting release planning, or holding a retrospective.
- Boards have integrated analytics that helps teams continuously improve their processes.
- Boards expose rich contextual data about the relationships and current status of related objects.
- Teams never have to leave their current Board to manage or interact with any objects represented on a Board.
How we prioritize
We use the following decision framework when evaluating what to work on. Each idea must meet all three of the minimum criteria and two of the extreme criteria.
|Minimum (3 of 3)
||reduces the friction to contributing
||aligned with market direction
|Extreme (2 of 3)
||enhances the ability to build trust
||decreases manual effort
||increases clarity and purpose
As issues are one of the primary, fundamental mediums for collaborating on ideas within GitLab, every single one of our internal and external personas falls within Team Planning's target audience.
Challenges to address
- 60% of enterprise software projects have overuns. Sources: 1,2,3,4
- The market is littered with fragmented, overly complicated issue tracking and project management tools that are slow, cumbersome, and prioritize enforced workflows over facilitating meaningful collaboration. Most are not organized around how teams actually prefer to plan and track work; and require advanced configuration and numerous integrations with third-party services before they can provide the level of traceability and compliance that enterprises require.
- GitLab is also contributing to this problem.
- Organizations struggle to quantify the value of their work; leading to prioritization by the "loudest voice in the room" as opposed to business results and customer value.
Where we are Headed
What's Next & Why
- Consolidate Epics and Issues into a single object
- Outcome: Orient around a foundational object and set of primitives (widgets, parenting, and so on) that enables Plan to minimize technical debt, reduce duplication, decrease time to value to solve our customer's current JTBD, increase SuS, drive cross-stage integrations, increase productivity for our users during the collaboration process, and more efficiently expand into adjacent markets that serve knowledge workers. This also puts the proper foundation in place to deliver on extensible issues
- Progress: Start MVC 0 and MVC 1 in 14.2.
- 99.95% availability
- Outcome: Performance and availability for Project Management features adheres to our target SLA.
- Progress: Based on the insights from this review request, we will target the highest value performance improvements and continue to devote a large portion of engineering capacity to reach SLA compliance.
- Manage sprint and release cadence
- Team velocity and volatility
- Outcome: Teams are able to set better delivery commitments and increase the speed at which they improve processes.
- Progress: Shipping Iterations in 13.2 provides us with the appropriate timebox behavior to provide accurate velocity, volatility, and team capacity feedback. We will be collaborating with Manage:Optimize on measuring velocity in the next few releases.
- Extensible Issues, types, & statuses
- Outcome: Issues can have a specific type which also determines other characteristics of the issue such as which fields are shown and what workflows the type of issue should leverage. Ultimately, users can customize issue types based on a library of widgets and custom fields so the data with an issue can be tailored to how organizations want to flow work items through their value streams.
- Progress: We are starting work on customizable issue types in 13.10 followed closely by which will be followed by customizable issue statuses.
- Usability, performance, & quality of life improvements
- Custom Fields
- Outcome: Teams can track additional meta data on issues without cluttering up the core issue experience.
- Configurable Workflows
- Outcome: Teams can sequence types of issues through different workflows / statuses. For those compliance minded organizations, workflows will optionally support tollgates.
- Automation Engine
- Outcome: Teams can create automation sequences for transitioning issues to different statuses, updating meta data based on given events, and self-serve creating solutions to help improve efficiencies around Issue management.
- Swimlanes on Issue Boards
- Why: So teams can gain more visibility into their workflows by organizing issues in horizontal lanes across lists that group issues according to different contexts such as epics, assignees, milestones, and label.
- Progress: The MVC for Epic Swimlanes shipped in 13.6.
- Integrated analytics on Issue Boards
- Why: So that teams have burndown charts and cumulative flow diagrams specific to their team and workspace.
- Real-time Boards
- Why: To allow teams to collaborate in real time on Issue Boards to improve the efficiency and effectiveness of planning and staying in sync on who is working on what.
Our group level issue board provides detailed insight into everything currently in flight.
What is Not Planned Right Now
- Integrating machine learning and natural language processing. While this will be important in the coming years, we need to provide a base level of support for modern agile teams before introducing optimizations.
- Sub-issues in the traditional sense. Based on our understanding of how they are used in other project management products, we feel like there is a better approach that will require less issue management overhead.
This category is currently at the 😁Viable maturity level, and our next maturity target is 😍Complete.
We are tracking our progress against this target via this epic.
User success metrics
We are tracking Monthly Active Users (MAU). Given we only receive usage ping data from a subset of instances actively using GitLab, the reported figures are likely substantially lower than reality.
Why is this important?
Issues are the fundamental medium for enabling collaboration on ideas and tracking that idea as it turns into reality. Over 5 million new issues are created per month and millions are interacted with on a daily basis across all instances of GitLab.
Improving collaboration on issues and how they are tracked directly correlates to a decrease in overall cycle time for a given change within a team's DevOps workflow.
The project management tools market is dominated by Jira (31%), Microsoft (18%), Smartsheet (6%), and Trello (5%). To be competitive, GitLab needs to solve for the following customer comments in the immediate future:
We’ve been told to use gitlab’s milestones to capture agile sprints, as they’re the only thing that can have burn down, they work well with boards and have concepts of time. The default way epics get their start/end dates is based on the milestones of the issues attached though – doesn’t make sense as an issue shouldn’t be assigned to an agile sprint until the sprint is eminent. (root of problem is that gitlab milestone must either be equated to agile milestone or agile sprint, not both – you’re missing a concept)
Needs to be a way to have a team velocity, as a scrum master be able to go through and say “This feature requires ~100 points of work, we can do 25 points per sprint, will take 4 sprints (8 weeks) – you want it done in 6 weeks, will either require to be simplified or increased resourcing.”
Need burn-down chart/progress status of sprints, features, initiatives, and milestones.
During sprint planning, need a way to see what my team’s velocity has been last several sprints to have a good idea of how much we should be planning for upcoming sprint.
Need an easy way to see how much I’m assigning to each team member during sprint planning (team members aren’t interchangeable – sprint can have user stories less than velocity, but if user stories are only doable by one team member then the work can’t get done).
Need to be able to answer questions around “which teams/members are working on this feature?”, “are we still on track to meet this milestone?”, “we want to add this new feature, how will that slow down other development?”, “This team is needed for another project, how will that effect timelines on this project?”, etc…
What they are saying:
- Within the next few years, over 2/3 of organisations will adopt a product-centric delivery model and move away from project management practices.
- "Agile" adoption remains strong and shows no signs of slowing down.
- Successful project/product management solutions must function as part of the overall Value Stream Delivery Platform and serve as a hub for planning and measuring value delivery.
- Competitive products should also provide feedback in the form of qualitative and quantitative metrics such as customer value and satisfaction, delivery velocity and volatility, business outcomes, cycle times, and organizational effectiveness around adopting modern DevOps and "Agile" practices.
Top Customer Success/Sales issue(s)
- Overview of Issue Boards across ALL projects (👍 120, +4, +6, +3, +7, +3, +2)
- Provide a way to work with a referenced issue from anywhere in the product without leaving your current context (👍 6, +3, +0, +0, +0, +1, +0)
- Manage sprint and release cadence (👍 5, +2, +1, +1, +0, +0, +0)
- Overview of Issue Boards across ALL projects (👍 120, +4, +5, +4, +4, +7, +5)
- Improve the efficiency and experience of weighting an issue backlog (👍 0, +0, +0, +0, +0, +0, +0)
- Custom Statuses Per Group (👍 25, +2, +1, +11)
Top user issue(s)
- List of all subscribed issues (👍 268, +18, +11, +12, +18, +16, +4)
- Trello Powerup: Add ability to attach issues (👍 299, +9, +12, +14, +15, +12, +5)
- Desktop Push Web Notifications (👍 235, +12, +7, +15, +22, +4) and an overhaul of how we handle notifications in general via something like a Unified Notifications Center (👍 121, +7, +2, +6, +5, +20, +16)
- Access issue custom fields from project level (👍 191, +13, +13, +9, +8, +15, +0)
- Remove list labels when closing an issue (👍 222, +12, +11. +12, +36, +27, +3)
- Add control over images in Markdown (👍 184, +2, +4, +17, +9, +8, +0)
- Add branch references to GFM (👍 135, +1, +2, +6, +5, +8, +0)
- Subissues on issue board (👍 95, +1, +2, +1, +1, +1, +0)
- Create personal issue boards (👍 84, +5, +2, +4, +3, +1, +6)
- Multiple projects issues on same Kanban/Board (👍 50, +1, +1, +1, +0, +0, +2)
- Configure view when clicking on Issues tab to be issue board (👍 46, +0, +1, +0, +0, +2, +0)
- Show tasks completed on Issue Card (👍 54, +2, +1, +1, +6, +1, +2)
- Add Time Tracking column totals to Issue Board (👍 46, +1, +3, +0, +1, +2, +1)
- Import/Export label configuration & Issue Board layout (👍 58, +4, +3, +3, +2, +4, +5)
- Filter by (and board config) Project on Group Issue Board (👍 97, +11, +9, +10, +8)
Top dogfooding issues
- Add an existing branch to a specific issue (👍 129, +4, +1, +3, +8, +7, +0)
- Attachment manager (👍 125, +2, +4, +6, +8, +8, +0)
- Provide first class support for Issue Task Lists and Tasks (👍 78, +7, +7, +6, +6, +4, +0)
- Burndown chart in issue boards (👍 13, +3, +0, +2, +0, +2, +1)
- Real time boards (👍 138, +5, +4, +6, +25, +3, +13)
- Horizontal Swimlines (👍 41, +2, +5, +6, +2, +4, +7)
Top Strategy Item(s)
One of our one year goals is to provide first-class support for modern "Agile" methodologies. Here are the next most important items to that end:
- Refactor how we handle Milestones. Right now, Milestones are largely stateless so it's impossible to calculate a velocity from Milestone to Milestone as we are retaining very little historical information in Milestones.
- Introduce some concept of a team so we can begin to measure and track capacity.
- Support multiple milestones per Issue or something similar that enables an issue to be associated to be a release and a sprint.
- Improve the integration of reports, milestones, and epics within Boards.
Another goal is to make it easier to collaborate while staying in flow. In order to enable users to interact with Issues from anywhere within the application, we will need to complete some fairly massive refactoring to support soft-real time functionality. These are the next most important steps:
- Add support for websockets.
- Complete our implementation of GraphQL and refactor the frontend to use GraphQL / Subscriptions.
As GitLab is expanding into larger organizations, we've received feedback that GitLab is not extensible enough to support the growing number of use cases are customers expect Plan to natively support. A long running and large strategic theme that this category is contributing to is making GitLab more flexible to support more diverse use cases. In the near term, we are contributing towards:
Another goal is to integrate analytics such as burndown charts and cumulative flow diagrams directly into Boards. In order to do that, we need to:
- Introduce the ability to define consistent workflows. The working approach is to abstract the ability to do this from the existing behavior of customizing stages in cycle analytics reports.
- Make a lot of improvements outlined in the
Category:Team Planning direction that directly impact the quality of data we can show on a Card.
We also want to provide a more seamless flow from top down planning all the way to the issue level. As we work on improving epics and our roadmapping capabilities, we will also need to focus on: