Cell-Specific Rule Definitions¶
This page lists rule definitions that are specific to individual cells.
Serenity (DevOps cell)¶
The DevOps cell focuses on internal work, so its members usually only log time on accounts that both Tempo and SprintCraft consider non-billable.
We are planning to look into options for adjusting how sustainability ratios of individual cells are calculated: At least some of the internal work that Serenity does to improve OpenCraft's hosting infrastructure is supposed to be covered by monthly maintenance plans from clients who benefit from that infrastructure (i.e., whose instances are hosted on it); and there might be a way to make SprintCraft's sustainability calculations reflect this.
However, at the moment there is no straightforward way to factor in hours provided by monthly maintenance plans when calculating sustainability, and Serenity's sustainability ratio as displayed by SprintCraft is always in the 98%-100% range.
So we currently don't define a specific sustainability ratio for Serenity to target.
Instead, we keep the number of non-billable hours that Serenity can generate each month from growing in an uncontrolled manner by keeping the cell's size limited to 2 members, and capping the total number of non-billable hours that the cell is allowed to spend per month at 208h (cf. Sustainability Management for details).
Due to its small size Serenity does not explicitly designate two firefighters each sprint. Instead, each member of the cell allocates a small amount of time for firefighting each sprint, relative to their weekly commitments (in hours): The number of firefighting hours that each cell member allocates should (roughly) match 7.5% of their committed hours. (This is in line with our general recommendation that cells should allocate about 7.5% of their total capacity to firefighting each week).
For example, if members of the cell are committed to working 40h and 12h per week, respectively, their corresponding firefighting hours would be:
This would result in a total of 8h of firefighting time for each 2-week sprint.
- Serenity is solely responsible for maintaining OpenCraft's internal infrastructure and must handle all fires affecting that infrastructure. (This helps minimize total time logged against non-billable DevOps accounts by other cells, which is important for company-wide sustainability.)
- Firefighting responsibilities for Serenity do not include addressing issues affecting client instances, unless there is an underlying infrastructure problem that is causing these issues and affecting multiple instances at once.
In general, tasks that exceed the cell's capacity for firefighting may not be delegated to firefighters of generalist cells.
- In situations where Serenity’s firefighting hours would not allow the cell to handle all OCIM/DevOps-related fires coming up during a sprint, the cell must prioritize firefighting over other tasks, moving them out of the sprint to free up capacity or postponing them to a later part of the sprint as needed.
- In situations where firefighters from other cells become aware of urgent infrastructure-related issues
while all members of the DevOps cell are out-of-office, they should start working on fixing them immediately.
- This is the only exception to the general rule about FF task delegation mentioned above.
- If a given issue has not been resolved by the time that members of Serenity are back to work, they should take over the remaining work.
- Responsibilities belonging to the Sprint Planning Manager and Sprint Manager roles are reduced to a subset of items that is relevant for Serenity. The two roles are assigned to the same person.
- Responsibilities belonging to the Epic Planning and Sustainability Manager role are reduced to a subset of items that is relevant for Serenity.
Sprint Planning Manager¶
- Task Estimation Session: Default responsibilities apply.
- Prioritization: Being a small cell that focuses exclusively on internal infrastructure-related projects,
the DevOps cell should maintain a list of current and upcoming epics in a dedicated document
(such as Serenity Epics Schedule (v3)),
so that it is easy for other team members to get a high-level overview of what the DevOps cell is currently working on,
as well as future plans.
- The Sprint Planning Manager checks this document once per sprint and updates it to reflect the latest status and priorities.
- On Friday before the start of a new sprint (when all relevant tasks for the upcoming sprint are available), the Sprint Planning Manager arranges the tasks scheduled for the next sprint to match current priorities as laid out in the document.
- Additional tasks related to team-wide conversations and/or activities (such as discussing a process change on the forum or preparing for an upcoming conference) are slotted in as necessary.
- Task Insertion: Default responsibilities apply.
- Sprint Preparation: Default responsibilities apply.
- Sprint Preparation: Every Monday before the start of the new sprint:
- Double-check that each member of the cell has allocated a small amount of time for firefighting, relative to their weekly commitments (in hours).
- Assigning Firefighter Rotations: Not applicable (due to its small size Serenity does not keep a rotation schedule for firefighting).
- Mid-sprint updates: Default responsibilities apply.
- Sprint Wrap-Up: Default responsibilities apply.
- Meetings: Not applicable (Serenity does asynchronous planning).
Epic Planning and Sustainability Manager¶
Default responsibilities apply, with the following modifications:
- Since cell size will not change, it is not necessary to coordinate with the team's recruitment manager on a regular basis. The main scenario where help from the recruitment manager would be needed is if a member of the DevOps cell decides to leave the team: In that case, the epic planning and sustainability manager would work with the remaining cells to see if they could provide a replacement, and notify the team's recruitment manager of the capacity reduction so that they can take necessary steps to replenish the team's capacity (either by recruiting directly for the DevOps cell or by finding newcomers for the cell that donated one of their members to the DevOps cell).
- Since Serenity doesn't own any clients, adjusting client budgets in SprintCraft is not necessary.
- The epic planning and sustainability manager should use the modified checklist included below when compiling bi-weekly epic planning and sustainability updates.
As mentioned above, Serenity (as the DevOps cell) is limited to 2 members and its size will be kept constant for the foreseeable future. This sets an upper bound for the number of non-billable hours that Serenity can generate per month: i.e., the sum of the monthly hour commitments of its members.
As a result, responsibilities for sustainability management are reduced to making sure that the total number of non-billable hours that Serenity accumulates each month does not exceed 208h, i.e., the total monthly commitment of Serenity's current members, calculated as (1 + 0.3) * 40h * 4 weeks.
- This cap does not include an additional buffer for overtime: We assume that reasonable amounts of overtime incurred over the course of some sprints will be offset by periods of less total time worked over the course of other sprints.
- This cap applies to the total number of hours logged against non-billable SE tickets, irrespective of whether they were logged by members of Serenity or members of other cells. For example, if Serenity decides to have a member of another cell provide a review for a given SE ticket, the time spent on the review will be logged on the SE ticket and thus count towards the total number of non-billable hours generated by Serenity over the course of the month where the review happened.
The sustainability manager should check the number of non-billable hours for the current month once per sprint so that any issues can be caught early and necessary adjustments can be made in the following sprint.
Aside from making sure that non-billable hours stay within the monthly limit mentioned above, Serenity's sustainability manager should perform an accounts review once per month (scheduled for the same day as the accounts review for other cells). The main aspect to focus on in the context of the DevOps cell is making sure that tickets dealing with incidents affecting multiple client instances are associated with the clients' Instance Maintenance accounts instead of internal DevOps accounts.
The bi-weekly checklist for compiling epic planning and sustainability updates for Serenity looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
Due to its small size Serenity's limit for the percentage of members that can be away at the same time is increased from 20% to 50%.
Bebop must target a sustainability ratio of 26%.
This target was first set in July 2022, in the context of the first company-wide sustainability review.
It was re-evaluated and confirmed in the context of the latest company-wide sustainability review (completed in Q1 2023).
Bebop follows the general recommendation to allocate about 7.5% of its capacity per sprint to firefighting.
However, the cell designates three firefighters per sprint instead of two.
Falcon must target a sustainability ratio of 18%.
This target was set in February 2023.
It is based on results from the latest company-wide sustainability review (completed in Q1 2023) and takes into account the average volume of billable and non-billable hours logged by the cell in Aug-Dec 2022.