Workstreams vs. Boards

Understand the Core Distinction: Workstreams vs. Boards

We've covered what workstreams are in DevStride's Map Value module: they represent the value of what should be delivered over time in an organization.

Identifying who and when these units of value should be delivered is the next step.

Why This Matters

DevStride solves what can otherwise be a significant project and portfolio management challenge: the idea of value delivery (what’s being accomplished or delivered) vs. team execution (who’s working on what and when), which may just be moving parts of the overall value delivery.

Mistaking one for the other leads to misaligned boards, poor reporting, and eventually rework.

DevStride provides dual lenses through Worktreams and Boards:

Value Delivery View (Workstreams): What are we trying to accomplish as a business?

Execution View (Boards): What are our teams doing to accomplish it and when?

Real-World Use Cases:

Here are a couple of real-world examples:

A QA Team has one Kanban board for test execution, but they may be testing features from 10 different workstreams on the portfolio (Map Value) map.

A Sales Enablement Team might have a board of tasks and deliverables (playbooks, campaigns, onboarding docs) that belong to different strategic initiatives in Map Value.

Step 1: Define Your Value Streams (Workstreams) in Map Value
As a review, here is how this works:

Go to the Map Value section in DevStride.

Click New Workstream.

Name it based on business value (e.g., “Customer Portal”, “Q3 Product Launch”, “Sales Acceleration”).

Create items (e,g., Intiative, Objectives, Tasks or Epics, Features, Stories) that represent outcomes you plan to deliver.

Structure these hierarchically using DevStride’s item types.

Goal: This is your delivery view, like a product owner or business leader would view it - a delivery of value.

Step 2: Avoid Structuring Workstreams by Team

Don’t create workstreams like “Frontend Team” or “QA Team.”

Instead, capture what the teams are building, not who is building it.

You will assign work to teams later in boards.

Step 3: Define Team Execution via Boards

Navigate to Boards in Plan Delivery.

Create folders named for how teams operate in executing work being performed (e.g., “QA Team”, “Web Product x Engineering Team”, “Customer Ops”).

Inside each folder, create either:

Perpetual Boards (for ongoing work)

Cycle Boards (for sprints or deadlines)

Assign the correct cadence if timeboxing applies.

Goal: This is your execution view. This view is one that a project manager, delivery manager, or scrum master might operate in, one that executes the work to support the value delivery.

Step 4: Assign Workstream Items to Boards

Open a board and assign items from the board.

OR

Navigate to items in your porfolio under Map Value (e.g., “Feature: Customer Login”).

Assign those items into the appropriate board where execution happens.

Step 5: Align Items, Don’t Duplicate Them

A parent item exists once in the Plan Value workstream hierarchy, but can appear on multiple boards via its child items.

Example: “Feature: Enhanced Login” parent item (a feature) belongs to the “Customer Portal” workstream, but may be worked on by:

Design Team board (for UX/UI): design-related child items

Backend Team board (for API): backend-related child items

QA Team board (for testing): testing-related child items

DevStride tracks all this automatically — by relating child items to their parent and reflecting percentage complete.

Step 6: Confirm Status through Multiple Lenses

• Use the Workstreams view in Map Value to see the hierarchy of deliverables as it relates to your objectives and the value your organization is delivering.

• Use the Boards View in Plan Delivery to see what teams are actively executing.

• Use Reports to pull metrics across both dimensions.