CPS releases follows ONAP’s Release ( see Releases - ONAP Wiki - Confluence )
...
In terms of priorities, CPS has a release planning page ( CPS R16 Release Planning - ONAP Wiki - Confluence ), wherein priorities are discussed with clients/stakeholders.
NotesNote:
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 , ) Development team (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 | Product backlog - Release Planning page ordered by stakeholder priorities User story Backlog Individual KanBan board (In Progress, Submitted) |
Events |
| 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 |
|
|
|
...
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
...
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 | 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
| Gliffy | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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
...