CPS Ways of Working

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.

Notes:

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

	Scrum	Kanban	CPS Way
Roles	Product Owner Scrum Master Development team	No fixed roles	Product Owner Scrum Master ( 2 teams, 9 CPS Dev team members, community ) Development team
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	Release Planning page ordered by stakeholder priorities Backlog Individual KanBan board (In Progress, Submitted)
Events	Sprint Sprint Planning Daily Scrum Sprint Review 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
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
How it’s done	PO refines the backlog and it’s priorities Team takes from backlog to complete in sprint which lasts for a specific period of time (i.e. 2 weeks) Daily stand up is done to align with team Delivery at end of sprint Sprint review and Retro	Add tasks in backlog whenever Move tasks to “In progress” or “Done” Regular review process Adjust to bottlenecks	PO refines backlog and priorities (Epic level) Epics are “Groomed” and added to backlog Epic owners handle/refine tasks Members take tasks from backlog Deliver on demand Release on ONAP timeline/ on demand

Conclusion

CPS do a ‘'Scrumban’' way which is a mix of both scrum and KanBan
2 teams
- to accommodate daily stand ups , code review and task grooming process
- 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

Challenges

	Team notes/discussions
Stakeholders changes priorities based on their own timeline
Wasting time on epics that changes priority after
Bugs take over priority over any tasks
Client testing not done straight away
Different epics varies duration
Multiple epics in progress simultaneously

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
- Done by scrum master/epic owners + PO/epic team?
  - WIP limits
- 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 scrum board by epic to visualise progress
  - Dedicated sprint backlog for each epic
- Plan for '2 weeks' goal on agreed tasks for a particular epic
- Epic level update
  - update and plan meeting (weekly? monthly? …)
Development
- Backlog grooming on demand
  - as needed
- Stand up
  - daily
Mini releases
- as needed
Release
- based on ONAP timeline
Retro