§1: RICP development is done by teams, each with their own PO (Product owner). Each team has its own scrum (not kanban) backlog which is generated based on filter that is based on a mapping of components to that team. This mapping of component-to-team is visible in the RICP repository list page. For this to work - by convention - we mark each JIRA item only exactly belonging to one component; the primary component. We do not have teams as "JIRA components" - even if that might come in handy for items that are not mapped to a component yet (the PTL can create components in JIRA quite quickly). Two exceptions: the component ricp-integration for team T6 and the component ricp-e2e for team T7.
- T1 (Antti): board #16
- T2 (Juha): ...
§2: Backlog sprint planning is done for JIRA (user) stories. Stories are linked to higher-level JIRA Epics (which from team planning perspective are not particularly interesting) via the "Epic link" property of a story. Epics can be either project specific, e.g., a RICP epic, or RSAC-defined (O-RAN-SC's Requirement steering and architecture committee) epics that touch many subprojects. Epics are primarily for very high level release planning and not that relevant in sprint planning.
§3: To access JIRA or to be assigned JIRA items you must have a free LF (Linux Foundation) account and you must have logged in at least once into LF's JIRA. Please ask your team mates to do so.
§4: The workflow is generally (a) TO DO → (b) selected for development → (c) in progress → (d) done. For now we do not have a state "ready for acceptance". If really needed, we can use "in review" as a state that describes the situatio that a development team considers the item as done, but the PO (product owner or similar representative/delegate) has not formally accepted it yet (originally suggested by TelA).
§5: JIRA has a concept of releases (aka versions). We use this naming convention: Bronze-R3, Bronze-R4, Cherry-R5, Cherry-R6. R3 and R4 are the first and second half of Bronze.
§6: Each team creates their own 3 week sprints (and names) as per the naming scheme below which is aligned with the Bronze (B) and Cherry (C) timeline. P1-P3 are mapped to "release planning sprints". D1-D6 to "release development (and integration) sprints".
- RICP_T1 Sprint B.P1 (last week of previous release plus week 1 - this is exceptionally only 2 weeks),
- RICP_T1 Sprint B.P2 (week 2-4),
- RICP_T1 Sprint B.P3 (week 5-7),
- RICP_T1 Sprint B.D1 (week 8-10),
- RICP_T1 Sprint B.D2 (week 11-13),
- RICP_T1 Sprint B.D3 (week 14-16),
- RICP_T1 Sprint B.D4 (week 17-19),
- RICP_T1 Sprint B.D5 (week 20-22),
- RICP_T1 Sprint B.D6 (week 23-25)