Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Issue Tracking

Last reviewed: 2020-04-13

๐Ÿ“ Issue Tracking

ย  ย 
Stage Plan
Maturity Complete

Introduction and how you can help

๐Ÿ‘‹ This is the category strategy for Issue Tracking 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:

Overview

Purpose

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.

Essential Intent

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 Issue Tracking can be truly excellent at only one thing, what would it be?" This is Issue Tracking's Essential Intent:

To provide a clear, single source of truth for an idea from inception to implementation that the members of a community can trust and effectively collaborate on from anywhere within the GitLab application without breaking or unnecessarily delaying a member's current flow.

Next, asking "How will we know when we're done?" provides clarity of purpose. This is how we will know:

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.

ย  Criteria 1 Criteria 2 Criteria 3
Minimum (3 of 3) simplifies collaboration 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

Target Audience

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 Issue Tracking's traget audience.

Challenges to address

Where we are Headed

We've written a mock press release describing where we intend to be by 2020-09-01. We will maintain this and update it as we sense and respond to our customers and the wider community.

What's Next & Why

These are the epics we will be working on over the next few releases:

Our group level issue board provides detailed insight into everything currently in flight.

What is Not Planned Right Now

Maturity Plan

This category is currently at the ๐Ÿ˜Complete maturity level, and our next maturity target is ๐Ÿ˜Lovable by 2020-09-01.

We are tracking our progress against this target via this epic.

User success metrics

We are currently using the loose Stage Monthly Active Users (SMAU) definition and intend on migrating to the strict definition as soon as we've implemented the necessary telemtry to measure the defined events.

Why is this important?

Issues are the fundamental medium for enabling collaboration on ideas and tracking that idea as it turns into reality. Over 1 million new issues are created per month and over 200k 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.

Competitive Landscape

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โ€ฆ

Analyst Landscape

What they are saying:

Top Customer Success/Sales issue(s)

Top user issue(s)

Top internal customer issue(s)

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:

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:

GIT is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license