Issue Refinement and Estimation

Refinement And Estimation

Growth follows the GitLab Product Development Flow, supported by a series of automations that we’ve fine-tuned to improve clarity during refinement, streamline prioritization, and speed up experiment delivery.

The refinement process reduces chaos by creating natural quality gates. Epics must be refined and broken down before issues enter the pipeline. Issues must be estimated and clarified before they’re ready for development. This structured flow prevents half-baked ideas from consuming engineering time and ensures that when someone picks up work, they have everything needed to succeed. For a team running experiments with uncertain outcomes, this upfront investment in clarity pays dividends by allowing engineers to move fast on execution rather than spending cycles figuring out what to build.

The refinement process is driven by triage bot automations and policies to ensure that it’s smooth and consistent.

Note: The Growth team currently operates as a single, unified team following a kanban-style workflow. As a result, any process / automated workflows or nudges are designed to target the broader Growth Engineering stage rather than individual groups.

Refinement Steps

Epic-Level Refinement

1. An epic is created and moved to problem validation using ~"workflow::problem validation" where it is validated that the problem is clearly defined, worth solving, has no obvious blockers (legal, security, architectural), and the team has sufficient context to begin exploring solutions.
2. Once the problem is validated, if the epic requires UX/UI changes, it is labeled with ~"workflow::ready for design" to enter the design phase. Note that not all epics need design (backend, API, and infrastructure work typically skip this). The designs created during this phase are exploratory and expected to evolve based on technical feedback during refinement.
3. After the epic is moved to refinement, a dedicated refinement thread is created by the bot where the team discusses technical risks, dependencies, and implementation complexity, and design can still be adjusted if refinement reveals technical constraints.
4. Once the discussions are concluded, to break down the epic, engineers can self-volunteer in the refinement thread and move the epic to ~"workflow::planning breakdown". If no volunteers emerge after seven business days from the time of refinement, the bot will tag the EM in the epic to manually assign an engineer based on relevant experience and capacity.
5. Once an engineer is assigned for breakdown, they move the epic to ~"workflow::planning breakdown" to indicate decomposition is underway, and begin breaking down the epic into individual issues using the templates - Experiment implementation for experiments, and Implementation for everything else. Issues should use “blocking/blocked by” relationships to document implementation dependencies and required sequencing. If an issue’s scope and weight are well understood at creation time, it can be directly labeled ~"workflow::scheduling" with appropriate weight estimates, bypassing the formal issue refinement process. However, if the issue requires further clarification or has unclear implementation details, it should be labeled ~"workflow::refinement" to go through the standard issue refinement process individually. Once all issues from the epic breakdown are created and appropriately labeled, the engineer moves the epic itself to ~"workflow::scheduling" to indicate the breakdown is complete and the epic is ready for PM/EM to schedule the constituent issues into milestones based on team capacity and strategic priorities. All issues are placed on the team’s kanban board and engineers pick up work based on their capacity.
6. The epic status needs to be moved to ~"workflow:: in dev" once the the issues are getting worked upon.

Issue-Level Refinement

1. Issues are moved from ~"workflow::planning breakdown" to ~"workflow::refinement" automatically by the triage bot in order of priority (from top to bottom). The bot will only move issues to refinement if there is room in refinement column, meaning there is less issues than maximum limit for this column. This is first chance for PMs to prioritize issues by moving them higher in the planning breakdown column. After the issue is moved to refinement, a dedicated refinement thread is created, which acts as a place for discussion and weight estimation.
   • 💡 Hint: In rare case when an issue has to be expedited, it’s possible to move it to refinement manually. This will invoke a reaction from triage bot, which will add refinement thread for such issue instantly so the refinement can proceed the same way as with automated path.
2. During refinement the team ensures that the issue is well described and requirements are clear. They can use the refinement thread to discuss but they should make sure that any changes and decisions made there are also reflected in issue’s description. Once each engineer is comfortable with the way the issue is described, they can vote their estimation of weight based on our guidelines. The voting happens by reacting to the thread with one of few possible weight estimates: 1️⃣ 2️⃣ 3️⃣ 5️⃣ or 🚀.
3. Each day the triage bot checks all issues in ~"workflow::refinement" column and if an issue has required minimum number of estimation votes (see MIN_REACTIONS constant here for the current setting) it will be moved to ~"workflow::scheduling".
   • 💡 Hint: If there is some problem with the issue and it shouldn’t be moved forward even if enough engineers estimate it, ❌ reaction can be added to the thread which will stop the bot from transitioning the issue to ~"workflow::scheduling" as long as this reaction sticks to the thread. This means that whoever put it is also responsible for removing it once the problem is gone.
4. Once the issue is in ~"workflow::scheduling", it is awaiting final prioritization by PMs - it has to be manually moved to ~"workflow::ready for dev" depending on the current priorities. This part of the process is PMs responsibility. This allows for additional fine-tuning of priorities and acts as a buffer for our ready for development column.

Estimation Guidelines

[The development estimation is the time during ~"workflow::in dev" until moved to ~"workflow::in review"]

• LoE => Level of Effort represents the total number of business days spent across both workflow::in dev and workflow::review phases.

In planning and estimation, we value velocity over predictability. The main goal of our planning and estimation is to focus on the MVC, uncover blind spots, and help us achieve a baseline level of predictability without over optimizing. We aim for 70% predictability instead of 90%. We believe that optimizing for velocity (merge request rate) enables our Growth teams to achieve a weekly experimentation cadence.

• If an issue has many unknowns where it’s unclear if it’s a 1 or a 5, we will be cautious and estimate high (5).
• If an issue has many unknowns, we can break it into two issues. The first issue is for research, also referred to as a Spike, where we de-risk the unknowns and explore potential solutions. The second issue is for the implementation.
• If an initial estimate is incorrect and needs to be adjusted, we revise the estimate immediately and inform the Product Manager. The Product Manager and team will decide if a milestone commitment needs to be adjusted.

Team Participation in Refinement

Operating asynchronously means refinement can’t rely on scheduled meetings where everyone shows up at the same time. Instead, the team should adopt a continuous refinement mindset where engineers regularly check the growth epic board and issue kanban board for items in refinement status. When an epic appears in ~“workflow::refinement”, engineers should review the refinement thread, ask clarifying questions, evaluate technical feasibility, and provide feedback on the proposed direction. This isn’t a passive activity - the goal is to surface concerns, suggest alternatives, and ensure the epic is well-understood before someone volunteers to break it down.

Similarly, the issue kanban board should be monitored for issues in ~“workflow::refinement”, ~“workflow::scheduling”, and ~“workflow::ready for development”. Issues in refinement need estimation votes and technical feedback. Issues in scheduling are waiting for final prioritization but are already well-defined and could be moved to ready for development if priorities shift. Issues in ready for development are immediately available for pickup. By regularly scanning these columns, engineers maintain awareness of upcoming work, can identify issues that align with their expertise or interests, and keep the pipeline moving.

Currently, the team should prioritize any work labeled with ~“Growth::Driving First Orders”. These represent high-priority items that need immediate attention.

Issue sequencing

In order to convey Issue implementation order and blocking concepts, we leverage the blocking issue linking feature.

More on the discussion can be seen in https://gitlab.com/gitlab-org/growth/team-tasks/-/issues/752.

Labelling Issues & Epics

We use workflow boards to track issue progress throughout a milestone. Workflow boards should be viewed at the highest group level for visibility into all nested projects in a group.

The Growth stage uses the ~"devops::growth" label and the following groups for tracking merge request rate and ownership of issues and merge requests.

Growth teams work across the GitLab codebase on multiple groups and projects including:

• The gitlab.com/gitlab-org group
• gitlab
• GLEX
• customers-gitlab-com
• The gitlab.com/gitlab-com group
• about.gitlab.com

View page source - Edit this page - please contribute.