Content
View differences
Updated by Rosanna Sibora 4 days ago
**Expected Outcome**
Planning participants leave a session with work packages already correctly assigned - to the right team, iteration, sprint, or any other dimension the organisation cares about - without a separate data-entry step. The board is not a presentation layer on top of OpenProject; it is OpenProject, just experienced spatially.
**Why This Matters**
Today, teams often plan visually on external whiteboards or sticky-note tools, then manually transcribe the outcomes back into OpenProject. This creates duplication, lag, and errors. Decisions made in the room don't reliably make it into the system, and the system doesn't reflect what was actually agreed. Manual transfer of information is very time consuming.
When this epic is complete, a programme increment planning session, a sprint planning meeting, or a cross-team dependency review can happen directly in OpenProject. Moving a card is the action - not a signal that someone should go update a field somewhere else.
**Example Use Cases**
A facilitator sets up a board before a PI planning event. Y-axis is set to team (Crazy Bears, Dolphins, A-Team, etc.), X-axis is set to iteration (PI 1, PI 2). Work packages from the relevant epics appear as cards, pre-positioned where their current values place them. Cards not yet assigned to a team or iteration appear in the unassigned space at the bottom or side. During the session, teams drag cards into their lane and iteration column or adds new cards. When the session ends, all work packages carry the correct team and iteration values in OpenProject - ready for tracking, reporting, and dependency management.
A portfolio manager set ups a whiteboard for risk management showing only work package types "risk". On the X-axis there is probability, on Y-axis impact.
Planning participants leave a session with work packages already correctly assigned - to the right team, iteration, sprint, or any other dimension the organisation cares about - without a separate data-entry step. The board is not a presentation layer on top of OpenProject; it is OpenProject, just experienced spatially.
**Why This Matters**
Today, teams often plan visually on external whiteboards or sticky-note tools, then manually transcribe the outcomes back into OpenProject. This creates duplication, lag, and errors. Decisions made in the room don't reliably make it into the system, and the system doesn't reflect what was actually agreed. Manual transfer of information is very time consuming.
When this epic is complete, a programme increment planning session, a sprint planning meeting, or a cross-team dependency review can happen directly in OpenProject. Moving a card is the action - not a signal that someone should go update a field somewhere else.
**Example Use Cases**
A facilitator sets up a board before a PI planning event. Y-axis is set to team (Crazy Bears, Dolphins, A-Team, etc.), X-axis is set to iteration (PI 1, PI 2). Work packages from the relevant epics appear as cards, pre-positioned where their current values place them. Cards not yet assigned to a team or iteration appear in the unassigned space at the bottom or side. During the session, teams drag cards into their lane and iteration column or adds new cards. When the session ends, all work packages carry the correct team and iteration values in OpenProject - ready for tracking, reporting, and dependency management.
A portfolio manager set ups a whiteboard for risk management showing only work package types "risk". On the X-axis there is probability, on Y-axis impact.