There are many activities that occur during our Sprints. Some of these activities are listed below:
The schedule below is used to keep track of the activities that are performed during the Sprint. Google calendar events are created based on this schedule to ensure all of the activities and expected completion dates are transparent.
|Day||Activity||Product Manager (PM)||Engineering Manager (EM)||Backend Engineer (BE)|
|1-5||Complete Retrospective from the Previous Sprint||Participant||Participant||Participant|
|12||Communicate status of issues from the current release, to the PM||Participant||Owner|
|13||Sprint Planning for the next release begins||Owner|
|14||Capacity Planning - Request Capacity for the next release||Participant||Owner||Participant|
|15||Communicate the team capacity to the PM||Participant||Owner|
|17||Present prioritized list of deliverables to the EM||Owner||Participant|
|18||EM shares list with the team (via google doc)||Owner||Participant|
|18-19||Team assign weights to issues||Owner|
|20||EM consolidates issues in a Shared Google doc and assign final weights, updates weights on the issue board, and assigns issues||Owner|
|20||If an issue is shared between another counterpart (FE / UX), the BE will identify dependencies and coordinate schedules with the counterpart. This communication can occur via a shared Google Doc or in Slack.||Owner|
|20||EM informs PM of any final slippage that will need to occupy capacity in the next release||Participant||Owner|
|20||EM informs PM of weights and give PM the opportunity to add or remove from the current milestone||Participant||Owner|
|22||Product Kickoff Meeting||Owner||Participant||Participant|
|23||Last Day of the Release||Participant||Participant||Participant|
The Engineering Manager (EM) creates a Sprint Planning Google Doc for each Backend Engineer (BE) to collaborate during Sprint Planning. The BE enters their capacity for the Sprint.
We use a lightweight system of issue weighting to help with capacity planning. These weights help us ensure that the amount of scheduled work in a cycle is reasonable, both for the team as a whole and for each individual. The "weight budget" for a given cycle is determined based on the team's recent output, as well as the upcoming availability of each engineer.
Since things take longer than you think, 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. We should strive to be accurate, but understand that they are estimates! Change the weight if it is not accurate or if the issue becomes harder than originally expected. Leave a comment indicating why the weight was changed and tag your EM so that we can better understand weighting and continue to improve.
The weights we use are:
|1: Trivial||The problem is very well understood, no extra investigation is required, the exact solution is already known and just needs to be implemented, no surprises are expected, and no coordination with other teams or people is required.
Examples are documentation updates, simple regressions, and other bugs that have already been investigated and discussed and can be fixed with a few lines of code, or technical debt that we know exactly how to address, but just haven't found time for yet.
|2: Small||The problem is well understood and a solution is outlined, but a little bit of extra investigation will probably still be required to realize the solution. Few surprises are expected, if any, and no coordination with other teams or people is required.
Examples are simple features, like a new API endpoint to expose existing data or functionality, or regular bugs or performance issues where some investigation has already taken place.
|3: Medium||Features that are well understood and relatively straightforward. A solution will be outlined, and most edge cases will be considered, but some extra investigation will be required to realize the solution. Some surprises are expected, and coordination with other teams or people may be required.
Bugs that are relatively poorly understood and may not yet have a suggested solution. Significant investigation will definitely be required, but the expectation is that once the problem is found, a solution should be relatively straightforward.
Examples are regular features, potentially with a backend and frontend component, or most bugs or performance issues.
|5: Large||Features that are well understood, but known to be hard. A solution will be outlined, and major edge cases will be considered, but extra investigation will definitely be required to realize the solution. Many surprises are expected, and coordination with other teams or people is likely required.
Bugs that are very poorly understood, and will not have a suggested solution. Significant investigation will be required, and once the problem is found, a solution may not be straightforward.
Examples are large features with a backend and frontend component, or bugs or performance issues that have seen some initial investigation but have not yet been reproduced or otherwise "figured out".
Anything larger than 5 should be broken down if possible.
Security issues are typically weighted one level higher than they would normally appear from the table above. This is to account for the extra rigor of the security release process. In particular, the fix usually needs more-careful consideration, and must also be backported across several releases.
This is the first activity that occurs for a Sprint. Sprint Planning begins in the previous Sprint. This ensures that the team can start working on Issues that have been weighted and clearly defined by Day 1 of the Sprint.
The Product Manager (PM) begins the process by moving items out of the Backlog and adding them to a Release (Milestone). Labels are created for each Milestone. The output of this process is a Release Issue Board.
Once the PM creates the Release Issue Board, the EM adds the issues to each BE's Sprint Planning Google Doc. The Backend Engineers:
Once all of the Backend Engineers have completed their Sprint Planning, the EM consolidates all of their responses into a shared Team Sprint Planning Google Doc. The EM reviews all of the weights and explanations and determines a final weight for each issue. In some instances, Backend Engineers assign different weights for the same issue. In this scenario, the EM will analyze their explanations and assign the final weight.
The EM assigns issues to Backend Engineers based on their capacity, the priority of the issues, the weight estimates, and their familiarity or unfamiliarity with the functionality.
The primary source for things to work on is the Editor backend issue board for the current iteration cycle (don't forget to filter by milestone!), which lists all of the Deliverable and Stretch issues scheduled for this cycle in priority order.
The lists are compiled by the Product Manager following the product prioritization process, with input from the team, engineering managers, and other stakeholders. The iteration cycle lasts from the 18th of one month until the 17th of the next, and is identified by the GitLab version set to be released on the 22nd.
There is also the Editor backend assignment issue board (again, don't forget to filter by milestone!), which shows the same Deliverable and Stretch issues, now grouped by assignee, with the left-most list listing issues not currently assigned to any backend engineer. On each list, the issues are again ordered by priority.
Deliverables are considered top priority and are expected to be done by the end of the iteration cycle on the 17th, in time for the release on the 22nd.
These top priority issues are assigned to engineers on or ahead of the 18th of the month, when the iteration cycle is kicked off, and it is their responsibility to make a best effort to get them done during that cycle, and to inform their engineering manager if anything is standing in the way of their success. You can find the issues assigned to you on the Editor backend assignment issue board (again, don't forget to filter by milestone!).
Many things can happen during a month that can result in a deliverable not actually being completed by the end of a cycle, and while this usually indicates that the engineering manager was too optimistic in their estimation of the issue's weight, or that an engineer's other responsibilities ended up taking up more time than expected, this should never come as a surprise to the engineering manager.
The sooner this potential outcome is anticipated and communicated, the more time there is to see if anything can be done to prevent it, like reducing the scope of the deliverable, or finding a different engineer who may have more time to finish a deliverable that hasn't been started yet. If this outcome cannot be averted and the deliverable ends up missing the cycle, it will simply be moved to the next cycle to be finished up, and the engineer and engineering manager will have a chance to retrospect and learn from what happened.
Generally, your deliverables are expected to take up about 75% of the time you spend working in a month. The other 25% is set aside for other responsibilities (code review, community merge request coaching, helping people out in Slack, participating in discussions in issues, etc), as well as urgent issues that come up during the month and need someone working on them immediately (regressions, security issues, customer issues, etc).
If you have time to spare after finishing your deliverables and other activities, you can spend the remaining time working on Stretch issues, which can also be found on the Editor backend issue board and Editor backend assignment issue board (again, don't forget to filter by milestone!).
These lower priority issues are not expected to be done by the end of the iteration cycle, but are to be Deliverables in the next cycle, so any progress made on them ahead of time is a bonus.
Stretch issues are usually not directly assigned to people, except in cases where there is clearly a most appropriate person to work on them, like in the case of technical debt, bugs related to work someone did recently, or issues someone started on before but hasn't had a chance to finish yet.
If no Stretch issues are assigned to you yet, you can find new ones to pick up in the left-most list of the Editor backend assignment issue board (again, don't forget to filter by milestone!), which lists all issues not currently assigned to any backend engineer. As the issues are ordered by priority, they should be picked up starting at the top. When you assign an issue to yourself to indicate you're working on it, it will move to your list and out of the left-most unassigned list, and the second issue will rise to the top for other engineers to pick up.
If anything is blocking you from getting started with the top issue immediately, like unanswered questions or unclear requirements, you can skip it and consider a lower priority issue, as long as you put your findings and questions in the issue, so that the next engineer who comes around may find it in a better state.
Instead of picking up Stretch issues, you may also choose to spend any spare time working on anything else that you believe will have a significant positive impact on the product or the company in general. As the general guidelines state, "we recognize that inspiration is perishable, so if you’re enthusiastic about something that generates great results in relatively little time feel free to work on that."
We expect people to be managers of one and prefer responsibility over rigidity, so there's no need to ask for permission if you decide to work on something that's not on the issue board, but please keep your other responsibilities in mind, and make sure that there is an issue, you are assigned to it, and consider sharing it in #g_create_editor.
The Create:Editor group conducts monthly retrospectives in GitLab issues. These include the backend team, plus any people from frontend, UX, and PM who have worked with that team during the release being retrospected.