Development Stream
The Development Stream process manages the planning, prioritization, and visualization of all activities related to product and component releases of different sizes, such as new versions, rollups, and temporary corrections. The main development streams are Operations, Engineering, Control & IO, and IIoT Platform & Applications.
Each development stream has its own release cycle but follows a common development pacing through the SPI cadence. The development streams collaborate with the system streams to break down system requirements (system epics) into epics and features, and assign them to the right sub-streams and teams.
Note: Epics, features (and stories) have two purposes - the first is to break down the requirements into smaller deliverable pieces of functionality, the second is for planning and execution.
Process overview
Principles
- Ensure the stream backlog is continuously updated and ranked based on the value.
- Apply common cadence, and synchronize development stream and teams.
- Plan and commit the increment (PI) with key stakeholders.
- Apply analysis of working product in quality decisions.
- Remove impediments and 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 (A): Stream Owner (C): Team (I): - | Product Owner | - |
| Feature | A feature/enabler is estimated and ranked in this process. For details about contents, see the requirements process. | (R): Product Owner (A): Product Owner (C): Team (I): - | Team | - |
| PI Objectives | PI objectives describe the specific business and technical goals the stream intends to achieve in the upcoming PI. Aggregate Team PI Objectives to Stream PI Objectives. | (R): Product Owner, Scrum Master (I): Stream Owner (C): Team (I): - | R&D | - |
| Dev Stream Backlog | This is a holding area for upcoming features to address user needs and deliver business benefits for a single Stream. It also contains the enabler features necessary to build the Architectural Runway. | (R): Product Owner(s) (A): Stream Owner (C): Team (I): - | R&D | - |
| 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): - | Team | Physical board (for co-located stream members) or digital board in Azure DevOps. |
| 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): - | Dev Stream | - |
| Risk | Can cause future problems, loss, or threaten progress - but has not happened yet | (R): Release Owner, Product Owner, Architect, Scrum Master (A): Stream Owner (C): - (I): - | Dev Stream | - |
Dependencies
Details
The development 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 development stream belongs to the "master processes" responsible for continuous planning and execution. It takes the activities defined in the functional processes (e.g., requirements, architecture, and test) and adds them to the iterations and increments. Since the system stream doesn't have any development activities, "SW Development" and "HW Development" are excluded, and corresponding activities are not planned in the system stream.
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 are on the same cadence, 4 increments per year and 4-6 iterations per increment (2-3 weeks each). A common calendar across all streams defines the yearly cadence with start and end dates.
Flow view
The flow view shows the process activities in a logical sequence with decision points. It makes it possible to understand the relationship between the activities.
Details about the activities can be found in the functional processes.