To better ensure we are ready to start work on issues in each 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.
There's a diagram that (hopefully) helps understand the process.
Top priority issues from upcoming release milestones will go through Planning Breakdown with Product Managers (PMs), Engineering Managers (EMs) & Engineers from the respective groups. Weekly group-level synchronous meetings will facilitate this discussion. The list of issues to be discussed will be provided by the PM at least 1 day prior to the meeting. The expectation is that all attendees have reviewed the issues prior to the start of the meeting. Attendees should add the carrot 🥕 emoji to signify that an issue has been reviewed in advance.
Questions to be answered:
If the answer is “No” to any of the above questions enumerate questions and assign back to PM.
If the answer is "Yes" to all of the above questions then team estimates whether or not the issue can be delivered in a single iteration (ignoring any other work that may be in that same iteration). If it's determined that the issue under discussion cannot be delivered within a single iteration the team works with PM to break it down into multiple MVC Issues that can each be delivered in an iteration, are independent "slices" of value that can be used by a customer (so no mocked UIs or backend-only work that is inaccessible), and when all delivered will completely fulfill the original issue's requirements.
workflow::refinementstate and assign the issue to an engineer for refinement.
If release X.0 ships on April 22, then Week 1 for planning release X.1 begins on or before the week of March 2-6
Engineers refine1 issues assigned to them in the current+1 release. They are encouraged to ask questions and are authorized to push back on PM if issues lack the information and/or designs required for successful refinement and execution.
workflow::ready for devstate and unassign themselves if they have completed refinement. Leave issue in
workflow::refinementand assign the issue to their EM if for any reason refinement could not be completed.
If release X.0 ships on April 22, then Week 2 for planning release X.1 is March 9-13
EMs and PMs complete a first pass of current+1 release. Rough scope of the release is defined based on the PMs priorities and EMs capacity estimations.
If release X.0 ships on April 22, then week 3 for planning release X.1 is March 16-20. Execution of release X.1 begins on March 18!
Scope of the next release is finalized by EMs and PMs.
Deliverablelabels applied to issues we are committing to deliver.
Deliverablelabels in the
workflow::ready for devstate have been confirmed to be in the correct priority order.
Backlog refinement 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 refinement 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".
Anyone should be able to read a refined issue's description and understand what is being solved, 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.
Note the following differences when refining bugs:
The Security Release Process for Developers can be daunting for first-timers. As part of refinement, ask for a volunteer to act as a "Security Issue Release Buddy".
An issue should fail refinement 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 refinement process, not the purpose of the refinement 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 do not add weights to bugs as this would be double-counting points. When our delivery contains bugs, the velocity should go down so we have time to address any systemic quality problems.
We are using the Fibonacci sequence for issue weights. Definitions of each numeric value are associated with the frontend-weight & backend-weight labels. Anything larger than 5 should be broken down whenever possible.
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. Example.
The goal of the implementation plan is to spur critical analysis of the issue and have the engineer refining the issue 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.
The issue verification should be done by someone else other than the MR author4.
~workflow:verificationlabel and wait until they receive notification that their work has been deployed on staging via the release issue email.
~workflow:productionlabel, unassign themselves from the issue.
~workflow:productionstatus and verify other engineer's work.
Q: Should discovery issues be refined?
A: Yes. Discovery issues should be refined but some of the steps above may not be relevant. Use good judgement to apply the process above. The purpose of refining 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 refinement 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 weigh it?
A: Issues that require both frontend and backend work should be broken into multiple implementation issues as outlined in the planning diagrams.
Q: What's the meaning of the emojis in issues?
A: we use them to communicate certain steps in our process.
we assign issues for refinement 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. ↩
we do not use
Stretch labels; anything that isn't labelled as a
a stretch goal by definition and should be kept in scope as such. ↩
a spike doesn't directly add value to users so it shouldn't contribute to our velocity. The information delivered by a spike is what will be useful to deliver direct value to users. ↩
When the engineer who writes the code is the only one verifying it, it increases the chance of defects getting into production because when that engineer tests in a new environment, they are likely to try all the same attempts to break it as they did during writing the code, which does not bring any value. If a person who did not write the code verifies the resolution in a deployed environment, they will come in with a different perspective and is more likely to cover more test cases. ↩