Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

§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.

§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.

...

  • All items mapped to sprint "Sprint B.P1" : filter10308 (adapt filter string (13,14,...) to point to sprint names for the sprint your are interested in. Note you need to list seven sprints, one for each team RICP_T1..7).
  • All items mapped to release Bronze: use filters from §1 and add this to the search filter: "AND fixVersion in (Bronze-R3,Bronze-R4)" before the "ORDER" part of the filter.

§8: Use RICP test epic RIC-42 and the linked test user story RIC-43 to experiment with JIRA. Right now these are mapped to team/board for team T1: board #16 .

...