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

Plan:Portfolio Management Backend Team

Plan:Portfolio Management backend team

The Plan:Portfolio Management backend team works on the backend part of GitLab's Portfolio Management category in the Plan stage.

For more details about the vision for this area of the product, see the Plan stage page.

Team members

This team is currently shared between Plan:Portfolio Management and Plan:Certify.

Person Role
John Hope Engineering Manager, Plan:Portfolio Management & Plan:Certify
Felipe Artur Backend Engineer, Plan:Portfolio Management & Plan:Certify
Jarka Košanová Senior Backend Engineer, Plan:Portfolio Management & Plan:Certify
Jan Provaznik Senior Backend Engineer, Plan:Portfolio Management & Plan:Certify
Charlie Ablett Senior Backend Engineer, Plan:Portfolio Management & Plan:Certify

Stable counterparts

Person Role
Donald Cook Frontend Engineering Manager, Plan
Kushal Pandya Senior Frontend Engineer, Plan:Portfolio Management, Plan:Certify
Justin Farris Group Manager, Product, Plan
Rajat Jain Frontend Engineer, Plan:Portfolio Management & Plan:Certify
Florie Guibert Frontend Engineer, Plan:Portfolio Management & Plan:Certify
Axel García Frontend Engineer, Plan:Portfolio Management & Plan:Certify
Walmyr Lima e Silva Filho Senior Software Engineer in Test, Plan:Project Management (primary) & Plan:Portfolio Management (secondary)
Alexis Ginsberg Senior Product Designer, Plan:Portfolio Management
Keanon O'Keefe Senior Product Manager, Plan:Portfolio Management
Marcin Sędłak-Jakubowski Technical Writer, Plan

Hiring chart

This chart shows the progress we're making on hiring. Check out our jobs page for current openings.

Team metrics dashboard

Since we share a backend team between the Plan:Portfolio Management and Certify groups, we have a combined metrics dashboard. This is intended to track against some of the Development Department KPIs, particularly those around merge request creation and acceptance. From that dashboard, the following charts show MR Rate and Mean time to merge (MTTM) respectively.

The following chart shows a breakdown of MRs by category (omitting Security, for now). Totals may vary slightly from overall throughput as some MRs may have more than one throughput label.

Application performance dashboard

We have an application performance dashboard (internal) that tracks the performance of the parts of GitLab for which we are responsible. This dashboard is shared between the Portfolio Management and Certify groups for now.


Current (FY21-Q1)


See the Plan stage page and the Plan:Project Management backend team page.

Capacity Planning

We use a lightweight system of issue weighting to help with capacity planning, with the knowledge that things take longer than you think. These weights are used for capacity planning and the main focus is on making sure the overall sum of the weights is reasonable.

It's OK if an issue takes longer than the weight indicates. The weights are intended to be used in aggregate, and what takes one person a day might take another person a week, depending on their level of background knowledge about the issue. That's explicitly OK and expected.

These weights we use are:

Weight Meaning
1 Trivial, does not need any testing
2 Small, needs some testing but nothing involved
3 Medium, will take some time and collaboration
4 Substantial, will take significant time and collaboration to finish
5 Large, will take a major portion of the milestone to finish

Anything larger than 5 should be broken down if possible.

We're discussing a possible change to the weight scale we use.

We look at recent releases and upcoming availability to determine the weight available for a release.

Planning rotation

To assign weights to issues in a future milestone, we ask two team members to take the lead each month. They can still ask questions - of each other, of the rest of the team, of the stable counterparts, or anyone else - but they are the initial. This is currently shared across the three Plan backend teams: Project Management, Portfolio Management, and Certify, so people will be asked to weight some issues outside of their immediate team.

We're discussing whether or not we want to scope this down to individual teams in March FY21.

To weight issues, they should:

  1. Look through the issues on the upcoming milestone and those in ~workflow::"planning breakdown", filtered by Weight:None.
  2. For those they understand, they add a weight. If possible, they also add a short comment explaining why they added that weight, what parts of the code they think this would involve, and any risks or edge cases we'll need to consider.
  3. Timebox the issue weighting overall, and for each issue. The process is intended to be lightweight. If something isn't clear what weight it is, they should ask for clarification on the scope of the issue.
  4. If two people disagree on the weight of an issue, even after explaining their perceptions of the scope, we use the higher weight.
  5. Start adding weights around a week before the weights for a milestone are due. Finishing earlier is better than finishing later.

The rotation for upcoming releases is:

Release Weights due Engineer Engineer
12.8 2020-01-13 Felipe Cardozo Mario de la Ossa
12.9 2020-02-13 Charlie Ablett Heinrich Lee Yu
12.10 2020-03-13 Jarka Košanová Alexandru Croitor
12.11 2020-04-13 Jan Provaznik Brett Walker
13.0 2020-05-13 Felipe Cardozo Patrick Derichs
13.1 2020-06-13 Charlie Ablett Eugenia Grieff

Historical Capacity

Points of weight delivered by the team on the last three milestones, including rolling average. This allows for more accurate estimation of what we can deliver in future milestones. Full chart here.