Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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

  1. Sprint

  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

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

  1. PO refines the backlog and it’s priorities

  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 refines backlog and priorities (Epic level)

  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

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

Issues

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

Proposal

  • PO backlog refining

    • Start of ONAP next release

    • Bi-weekly with stakeholders

  • Backlog grooming top priorities

    • Ensure ‘priority agreed’ epics gets groomed straight away

  • Epic level planning

    • Done by Scrum master/epic owners + epic team?

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

      • use given timeframe to create ‘sprint’

    • Use scrum board by epic to visualise progress

    • Use of ‘due’ on tasks to

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

    • Epic level update

      • update and plan regularly

  • Development

    • Backlog grooming on demand

      • as needed

    • Stand up

      • daily

  • Mini releases

    • as needed

  • Release

    • based on ONAP timeline

  • Retro

  • No labels