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.
This direction page was last reviewed on:
2022-08-18
| Category | Planning Analytics |
|---|---|
| Stage | Plan |
| Group | Project Management |
| Maturity | Minimal |
👋 This is the category strategy for Planning Analytics in GitLab, which is part of the Project Management group with the Plan stage. 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:
Planning Analytic's goal is to provide comprehensive insights that empower small, autonomous teams to optimize their processes so that they are able to more efficiently and effectively continuously deliver customer and business value with the shortest possible cycle times. Features owned by the Planning Analytics category include issue analytics, time tracking, burndown charts, and burnup charts. Check out the Planning Analytics HQ for a full list of the things on our roadmap.
GitLab identifies who our DevSecOps application is built for utilizing the following categorization. We list our view of who we will support when in priority order.
Due to temporary team member allocations and limited investment, we are currently not focused on implementing any Planning Analytics capabilities at this point in time. We are actively working on acquiring the necessary investment to accelerate this category as it is paramount to our customer's success when using GitLab to plan and track work effectively and efficiently.
Our group level issue board provides detailed insight into everything currently in flight.
This category is currently at the Minimal maturity level, and our next maturity target is Viable on 2024-01-01.
Check out our cross-functional Project Management team handbook page to view our current customer value, product quality, and process performance indicators (internal link).
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:
While we are not currently working on the items listed within this section, we believe that solving for them will significantly contribute to Plan's 3-year strategy. Once validated and team capacity is available, we will move these strategic items into our queue for prioritization and implementation.
See the Team Planning Category Direction
See the Team Planning Category Direction
We are currently focused on providing industry-leading solutions for the following Jobs To Be Done (JTBD):
| Job statements | Maturity | Confidence | Source |
|---|---|---|---|
| When monitoring progress, I want to ensure the current scope and status of work are thoroughly captured, so I can increase the accuracy of my reporting and maintain trust with stakeholder. |
|
Researched | Issue |
| When reviewing a plan, I want to identify and enable continual monitoring of high risk items, so I can maintain effectiveness of mitigation plans, even as they evolve. |
|
Researched | Issue |
| When implementing to a plan, I need to monitor value delivery and value return so I can demonstrate that the team is efficiently capturing value for our stakeholders. |
|
Not validated | Issue |
| Job statements | Maturity | Confidence | Source |
|---|---|---|---|
| When reviewing a prior cycle, I can easily reflect on and improve my team's effectiveness. |
|
Not validated | Issue |
| When analyzing past releases, I want to analyze how successful deliverables were in satisfying objectives, so I can decrease the time it takes to course correct and improve future plans. |
|
Not validated | Issue |
| When units of value are released, I want to gather feedback from multiple channels and incorporate it into my plan, so I can iterate on increasing user value as we progress incrementally toward achieving business objectives and maximizing customer value. |
|
Researched | Issue |
| When evaluating and measuring previously delivered work, I want to surface and share any learnings identified while executing toward my strategy, so I can improve future plans based on these insights and articulate the rationale behind any changes. |
|
Researched | Issue |