System Stream
The System Stream process manages the planning, prioritization, and visualization of all activities related to system releases of different sizes, such as new versions, rollups, and temporary corrections. The main systems are 800xA, Symphony Plus, Freelance, and Heritage.
Each system has its own release cycle but follows a common development pacing through the SPI cadence. Whenever possible, the systems share components and applications. The system streams collaborate with the development streams to break down system requirements (system epics) into epics and assign them to the right stream.
Note: Epics, features (and stories) have two purposes - the first is to break down the requirements into smaller deliverable pieces, and the second for planning and execution.
Process overview
Principles
- Ensure the stream backlog is ranked based on the value.
- Apply common cadence, and synchronize across system and development streams.
- Plan and commit the increment (PI) with key stakeholders.
- Base milestones on an objective evaluation of working systems.
- Ensure an incremental approach with fast, integrated learning cycles.
- Remove impediments, and manage risks and issues.
- Continuously improve the way of working.
- Visualize and limit WIP, reduce batch sizes, and manage queue lengths.
- Decentralize decision making.
- Agree on definitions of DoR and DoD with key stakeholders and ensure adherence.
Activities
Artifacts
| Artifact | Description | RACI | Receiver | Comments |
|---|---|---|---|---|
| Epic | An epic/enabler is estimated and ranked in this process. For details about contents, see the requirements process. | (R): Product Owner, Architect (A): Stream Owner (C): Team (I): - | Team | - |
| Feature | A feature/enabler is estimated and ranked in this process. For details about contents, see the requirements process. | (R): Product Owner, Architect (A): Product Owner (C): Team (I): - | Team | - |
| PI Objectives | The PI objectives are defined in the PI Planning and describe the specific business and technical goals the system stream intends to achieve in the upcoming PI. Team PI Objectives are aggregated to Stream PI Objectives. | (R): Team (A): Release Owner, Scrum Master (C): Product Owner, Architect (I): - | Team | - |
| System Stream Backlog | This is a holding area for epics and features for the system stream intended to address customer needs and deliver business benefits. It also contains enabler epics and features. | (R): Product Owner, Architect, Team (A): Product Owner (C): - (I): - | Team | - |
| PI Planning Board | Highlighting the feature delivery dates, feature dependencies among teams, and relevant milestones. It is also called "program board". | (R): Release Owner, Scrum Master (A): Stream Owner (C): Product Owner, Architect, Team (I): - | Stream Owner | - |
| Impediment | Anything that keeps the stream from getting work done or stops a release. Identified in sync meetings | (R): Release Owner, Scrum Master (A): Stream Owner (C): Product Owner, Architect (I): - | Stream Owner | - |
| Risk | Can cause future problems, loss, or threaten progress - but has not happened yet | (R): Release Owner, Scrum Master (A): Stream Owner (C): Product Owner, Architect (I): - | Stream Owner | - |
Dependencies
Details
The system stream process focuses on lean-agile planning and execution. The process ensures the stream and teams plan, execute and release according to expectations. The development stream is aligned to a common (SPI) cadence for the R&D organization. The increments (PIs) have a set of recurring planning and execution activities.
Master Processes
The system stream is part of the "master processes," responsible for continuous planning and execution. The stream is synchronized with the increments on a common cadence (SPIs). Each increment starts with a PI planning, followed by synchronization events and demos, and ends with a retrospective (inspect & adapt).
Cadence view
The cadence view shows how master and functional activities in the processes are related to the increments. Many of the activities are executed in parallel and not always in a sequence. The cadence becomes natural points in time where the streams can consolidate plans, manage dependencies, address capacity issues, make (strategic) decisions, and take action.
All streams share the same cadence, 4 increments per year (~13 weeks) with 4-6 iterations (2-3 weeks) per increment. A common calendar defines the yearly cadence with start and end dates.
Flow view
The flow view shows how activities in the processes are laid out in a logical sequence with decision points. It makes it easier to understand the relationship between the activities. The activities are executed in parallel, as shown in the picture, and not in sequence.
