CPS Ways of Working

Owned by Lee Anjella Macabuhay
Last updated: Dec 05, 2024
3 min read

CPS releases follows ONAP’s Release ( see Releases - ONAP Wiki - Confluence )

  • ~ 2 times a year at 6 month interval

 

However, we also do releases to accommodate stakeholders and their priorities.

In terms of priorities, CPS has a release planning page ( CPS R16 Release Planning - ONAP Wiki - Confluence ), wherein priorities are discussed with clients/stakeholders.

Note:

  • For any ‘work’ not done from previous release, it it moved to the next release

 

 

Scrum

Kanban

CPS Way

 

Scrum

Kanban

CPS Way

Roles

Product Owner

Scrum Master

Development team

No fixed roles

Product Owner

Scrum Master ( 2 teams )

Development team (9 CPS Dev team members, community)

Artifacts

Product Backlog

Sprint Backlog (current sprint backlog)

Increment

KanBan board (To do, In progress, Review, Done)

Backlog

Work is pulled into next stage only when there’s capacity

 

Product backlog - Release Planning page ordered by stakeholder priorities

User story Backlog

KanBan board (In Progress, Submitted)

Events

  1. Sprint (i.e. 2-4 weeks)

  2. Sprint Planning

  3. Daily Scrum

  4. Sprint Review

  5. Sprint Retrospective

No sprints

Continuous flow - new tasks added whenever and tasks can be delivered any time

ONAP release ,Mini releases

Backlog Grooming weekly (on-demand)

Daily Scrum

Retrospective (every 6 weeks)

FSA (quarterly)

Knowledge sharing

Rules

Time-boxed

Product increment after each sprint

Work in progress limits (cap on tasks being in progress at a time)

Regular analysis on bottlenecks

 

Members take tasks from backlog when available

Epic owners assigned

How it’s done

  1. PO and team refines the backlog, it’s priorities and cost of user story (S,M,L)

  2. Team takes from backlog to complete in sprint which lasts for a specific period of time (i.e. 2 weeks)

  3. Daily stand up is done to align with team

  4. Delivery at end of sprint

  5. Sprint review and Retro

  1. Add tasks in backlog whenever

  2. Move tasks to “In progress” or “Done”

  3. Regular review process

  4. Adjust to bottlenecks

  1. PO and team refines backlog and priorities

  2. Epics are “Groomed” and added to backlog

  3. Epic owners handle/refine tasks

  4. Members take tasks from backlog

  5. Deliver on demand

  6. Release on ONAP timeline/ on demand

Current CPS WOW Summary

  • CPS do a ‘'Scrumban’' way which is a mix of both scrum and KanBan

    • Kanban way backlog grooming - “pull system” when there’s availability

    • No sprint or timeframe

    • Scrum roles

    • “Epic owners”

  • 2 teams

    • to accommodate daily stand ups , code review and task grooming process

    • agile limit (~8-9 people)

    • focus of epic level , i.e.

      • team 1 members is a mix of developers working on epic #1 and #2

      • team 2 members is a mix of developers working on epic #3 and #4

  • Weekly individual schedule to attend other team stand up to sync

  • Bugs-first policy

Challenges

 

Team notes/discussions

 

Team notes/discussions

Stakeholders changes priorities based on their own timeline

 

Epic not tested as client priority drops**

 

Client testing not done straight away

 

Different epics varies duration

 

Multiple epics in progress simultaneously

 

 

 

Problems we don’t have …

  • Motivation

  • User stories that are too big

  • Meeting deadlines

  • Predicting when something is ready

 

 

Proposal

  • PO backlog refining

    • Start of ONAP next release

    • Bi-weekly with stakeholders

  • Backlog grooming top priorities

    • Ensure ‘priority agreed’ epics gets groomed as soon as possible

  • Epic level planning

    • facilitated by scrum masters+epic owners, agreed with PO

      • WIP limits?

        • to give allowance for bugs if ever comes

    • PO to agree on time-frame based on stakeholder expectation?

      • use given time frame to create ‘sprint’

      • each tasks on epic is planned to be completed on certain ‘'sprints’', i.e.

        • all on epic 1 is to be done on Sprint 1

        • 2/3 tasks from epic 3 is on sprint 1 and rest is place on sprint 2 …

    • Use of scrum board

      • Dedicated sprint backlog grouped by epic

      • allows to visualise progress

        • how much work need done on planned time-frame

        • what has been done

        • what is in progress

    • Plan for '2 weeks' goal on agreed tasks for a particular epic

    • Epic level update

      • update and plan meeting

        • stakeholder meeting every wednesday **

        • individual epic teams/members ad hoc meetings to keep in plan

      • Priority change

        • Members reassigned

  • Development

    • 2 teams

      • each team has equal level of priorities

        • team 1 works on epic 1, 5 and 11 …. team 2 works on epic 2, 4, 10

          • each team works on 1 or 2 high priorities AND 1 or 2 low priorities

            • allows members in team to help in case of change priority

        • allows for easy epic shifting when priorities change (bugs, stakeholder change etc..)

    • 1 team

      • no huge disadvantage except on code reviews/ stand up

    • Backlog grooming on demand

      • as needed

    • Stand up

      • daily

  • Mini releases

    • as needed

  • Release

    • based on ONAP timeline

  • Retro