To better ensure we are ready to start work on issues in the next iteration, the planning process works as part of a monthly cadence. Since GitLab releases ship on the 22nd of each month, this schedule for the current+1 release begins on the first week of the month when the current release is being executed.
if release X.0 ships on March 22, then planning for release X.1 starts by the week of Jan 27-31
Issues at the top of our backlog (&/or upcoming release milestones) will go through Planning Breakdown with Project Managers & the respective Engineering teams at least ONE week prior to Week 1. Weekly group level syncronous meetings will facilitate this discussion.
As we improve, this planning breakdown activity should become an ongoing discussion around new issues as they are created.
Weekly syncronous group meetings will:
if release X.0 ships on March 22, then week 1 for planning breakdown for release X.1 begins on or before the week of Feb 3-7
Engineering Managers and Product Managers complete a first pass of current+1 release. Initial questions, calling out known availability/vacation, rough scope identified.
workflow::schedulingstate and are assigned for grooming.
if release X.0 ships on March 22, then week 2 for planning release X.1 is Feb 10-14
Identify volunteers to provide a high-level implementation plan and weight. Assign if necessary. Kick back to PM if the issue covers more than one work boundary.
workflow::ready for developmentstate.
Issues are assigned to engineers to ensure we have focus on the highest-priority items, as determined by Product Management. This is not an assignment to work on the issue, though there will be an effort made to make sure the engineer(s) who groom an issue will be the one(s) working upon it.
If release X.0 ships on March 22, then week 3 for planning release X.1 is Feb 17-21. Execution of release X.1 begins on Feb 18!
Scope of the next release is finalized by Engineering Managers and Product Managers.
Stretchlabels applied to issues for which we have capacity to achieve.
Backlog grooming is the most important step to ensure an issue is ready to move into development and that the issue will match everyone's expectations when the work is delivered.
The goal of the grooming process is to
backendlabel. Otherwise, remove any backend label, assign any relevant labels and you are done.
frontendlabel. Otherwise, remove any frontend label, assign any relevant labels and you are done.
workflow::ready for development.
When you are done grooming, anyone should be able to read the issue description and should know what the issue is solving, how it is solving the problem, and the technical plan for implementing the issue.
In order for someone to understand the issue and its implementation, they should not have to read through all the comments. The important bits should be captured in the description as the single source of truth.
An issue should fail grooming if it can not be worked on without additional information or decisions to be made. To fail an issue:
Weights are used as a rough order of magnitude to help signal to the rest of the team how much work is involved. Weights should be considered an artifact of the grooming process, not the purpose of the grooming process.
It is perfectly acceptable if items take longer than the initial weight. We do not want to inflate weights, as velocity is more important than predictability and weight inflation over-emphasizes predictability.
We are using the Fibonacci sequence for issue weights.
The weighting system roughly aligns with other teams within GitLab. We deviate from the scales used by other teams to provide enough granularity in our planning process.
A list of the steps and the parts of the code that will need to get updated to implement this feature. The implementation plan should also call out any responsibilities for other team members or teams. An example: https://gitlab.com/gitlab-org/gitlab/issues/5656#execution
The goal of the implementation plan is to spur critical analysis of the issue and have the groomer think through what parts of the application will get touched. The implementation plan will also permit other engineers to review the issue and call out any areas of the application that might have dependencies or been overlooked.
Q: Should discovery issues be groomed?
A: Yes. Discovery issues should be groomed but some of the steps above may not be relevant. Use good judgement to apply the process above. The purpose of grooming a discovery issue is to make sure the scope of the discovery is clear, what the output will be and that the prerequisites for the discovery are known and completed. Discovery issues can have a habit of dragging out or not creating actionable steps, the grooming process should lock down what needs to be answered in the discovery process.
Q: If an issue has both frontend and backend work how should I weight it?
A: Issues that require both frontend and backend work can be broken into sub-issues as outlined in this document.