§1: RICP development is done by teams, each with their own PO (Product owner). Each team has its own scrum (TODO-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. TODO-to we also We do not have teams as "JIRA components" - even if that might come in handy for items that are do not have a primary component?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§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. TODO-proposal Epics can be either project specific, e.g., a RICP EPICepic, or RSAC-defined (oO-ranRAN-scSC's Requirement steering and architecture committee) Epics epics that touch many subprojects. TODO any further discussion needed on the use of EpicsEpics 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 §3: TODO how to make sure that everyone has access. Proposal: likely this requires that someone has logged in at least once to into LF's JIRA. Suggest to ask everyone Please ask your team mates to do so.
§5§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 representative7delegaterepresentative/delegate) has not formally accepted it yet (originally suggested by TelA).
§6: TODO Do we introduce a field called "real component" and continue the versatile JIRA field "component" to be used as team.
§7§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.
§8: TODO-discuss§6: Each team creates their own 3 week sprints (and names) as per this 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".
...