docs(developer-clients): Fibonacci weights and slimmer planning calls

| Ritual | Cadence | What happens |

|---|---|---|

| Planning call — one per functional team | Monthly | Commit the scope, assign `Deliverable` / `Stretch` [labels](#issues-labels) and [weights](#issues-weight), plan capacity |

| Planning call — one per functional team | Monthly | Commit issues based on team capacity, assign [weights](#issues-weight); assignees and `Deliverable` / `Stretch` [labels](#issues-labels) are set in 1:1s instead, to save call time |

| [Async updates](#weekly-async-updates) | Weekly (by Tuesday EOD) | Everyone posts progress on their issues; automation aggregates them into one group-wide issue |

{{% details summary="The flow in detail (chronological)" %}}

1. **Throughout the milestone — prepare for the next one.** Flag issues you want prioritized next milestone with the [`workflow::scheduling`](https://gitlab.com/groups/gitlab-org/-/issues?sort=updated_asc&state=opened&label_name%5B%5D=workflow%3A%3Ascheduling&label_name%5B%5D=group%3A%3Adeveloper+clients) label. For an uncertain effort with no issue yet, create a placeholder (an empty description is fine) with a timeboxed [weight](#issues-weight). Keep statuses and labels current — the [planning boards](#planning-boards) double as our live view of milestone progress.

1. **Before the planning call.** EM + PM do an async backlog pre-pass, focusing on flagged issues. Everyone: have a rough idea of your availability (for example, planned vacation days). Plans can change — that's fine, we adapt.

1. **Monthly planning call — one per functional team.** Agree on the scope committed to the milestone, assign the `Deliverable` and `Stretch` [labels](#issues-labels) and [weights](#issues-weight), and plan team capacity using the planning board's capacity feature.

1. **Before the planning call.** EM + PM do an async backlog pre-pass, focusing on flagged issues, then send a Slack message a few days in advance with the agenda: the list of priorities and the updated [backlog page](#team-backlogs) — check it before the call. Everyone: have a rough idea of your availability (for example, planned vacation days). Plans can change — that's fine, we adapt.

1. **Monthly planning call — one per functional team.** Agree on the issues committed to the milestone based on team capacity, assign [weights](#issues-weight), and plan capacity using the planning board's capacity feature. To save call time, assignees and the `Deliverable` / `Stretch` [labels](#issues-labels) are set in 1:1s afterwards.

1. **During the milestone.** The planning board shows the milestone state and in-progress work. Post your [weekly async updates](#weekly-async-updates).

{{% /details %}}

### Issues' Weight

Weights are assigned during [milestone planning](#milestone-planning) as a rough estimate of complexity:

Weights are assigned during [milestone planning](#milestone-planning) as a rough estimate of complexity, using the [Fibonacci sequence](https://www.mountaingoatsoftware.com/blog/why-the-fibonacci-sequence-works-well-for-estimating) (`1, 2, 3, 5`):

| Weight | Rough effort |

|---|---|

| `1` | A day or two |

| `2` | About a week |

| `3` | About a week and a half |

- Anything estimated above `3` should first be a spike, which results in one or more issues with estimated weights.

- Estimates assume familiarity with the codebase/system — add `1`–`2` to the base weight if you're new to it.

| `1` | About half a day — including coffee-sized fixes (typo, small config tweak) |

| `2` | 1–2 days |

| `3` | About three days |

| `5` | About a week |

| `8` | A week and a half to two weeks — break it down |

- The scale is proportional: a weight is roughly that many working days (a `5` is a week). Weights can therefore be summed and compared, e.g., any issues totalling `8` are roughly a similar commitment to one `8`.

- This should serve as a rough sizing exercise, to give us a sense of the milestone capacity, so avoid spending too much effort trying to get an exact estimate — it's likely to change once we dive into implementation details.

- An `8` shouldn't be worked on as-is: we should break it down to smaller issues, or spike & time-box it first.

### Cross-Group Ownership and Boundaries