Work Items & Workspaces
Workspaces
A Workspace is a container for work items. Each workspace uses a specific work process that defines what types of work items can be created and what workflows they follow.
Every workspace has:
- Key — A unique 2-20 character uppercase alphanumeric identifier starting with a letter (e.g.,
PLAT,MOBILE) - Name and optional Description
- Work Process — The configuration that defines available work types and workflows
- Ownership — How the workspace is managed:
- Owned — Created and managed within Wayd
- Managed — Synchronized from an external system (e.g., an Azure DevOps project) and read-only in Wayd. See Administration > Integrations.
Workspaces and their work items come from a connection to an external system such as Azure DevOps: Wayd has no screen for creating a workspace or a work item. A workspace can only be active while its work process is active, and work items are added to or removed from a workspace only while it is active.
Workspace List Page
Navigate to Work Management > Workspaces to see all workspaces. The page supports two views:
Card View (default) — Responsive grid of workspace cards showing:
- Workspace name (clickable) and key
- Description (or "No description provided")
- Tags: "Inactive" (if inactive), "Managed" (if externally owned, with tooltip)
List View — Grid with Key, Name, Description, Ownership, and Active columns.
Click a workspace to view its work items.
Workspace Detail Page
The workspace detail page shows the workspace's name and key, with an Inactive tag when it is inactive.
Details panel:
- Ownership and Description
- Relationships — the Work Process (link to process configuration)
Work Items:
- Sortable, filterable grid of all work items in the workspace
- Columns: Key, Title, Type, Status, Status Category, Story Points, Team, Sprint, Parent Key, Parent, Assigned To, Project, Tags
- Effort and Size are available from Choose Columns (see Estimate columns)
- Click a work item to navigate to its detail page
Actions: Set External URLs sets the View Work Item URL template that links each work item to its page in the external system (managed workspaces only; requires permission to update workspaces)
Work Items
A Work Item is the fundamental unit of work in Wayd. It represents any piece of work that needs to be tracked — tasks, bugs, user stories, features, epics, or any other type defined by the work process.
Every work item has:
- Key — Unique identifier in format
\{WorkspaceKey\}-\{Number\}(e.g.,PLAT-1234). See Work Item Keys. - Title — A brief description of the work, kept in step with the external system
- Type — The category of work (defined by the workspace's work process)
- Status — Current position in the workflow
- Status Category — Normalized grouping (Proposed, Active, Done, Removed)
- Priority — Relative importance
- Stack Rank — Ordering value for backlog prioritization
- Story Points — Optional relative estimate, typically set in sprint planning
- Effort — Optional level-of-effort estimate, often set on features and epics for longer-term planning. Scrum also uses it as the sprint-level estimate.
- Size — Optional size estimate, used by the CMMI process for requirements
- Tags — The tags the work item carries in the external system
- Assignee — The person responsible for the work
- Team — The team responsible for delivery
- Parent — Optional hierarchical link to a parent work item. See Hierarchy Rules.
- Sprint/Iteration — Time-boxed period the work is planned for
- Project — Optional association with a PPM project, set on a Portfolio tier item or inherited from its parent
- Activated Timestamp — When work moved to Active status. A work item that went straight to Done or Removed takes its Done Timestamp as its Activated Timestamp, and an Activated Timestamp later than the Done Timestamp is moved back to it.
- Done Timestamp — When work moved to Done or Removed status. It is cleared when the work item moves back to Proposed or Active.
The three estimates are kept separately: an item can carry more than one, and each is synced from its own Azure DevOps field.
Estimate columns
Work item grids — a workspace's work items, a team's backlog, a sprint's backlog, a PI iteration's backlog and a project's work items — offer all three estimates as columns. The one that shows at first is the team's sizing method: a team that sizes in Effort sees Effort, a CMMI team sizing in Size sees Size. The others start hidden and can be added from Choose Columns. A sprint's backlog follows the sizing method in effect on the sprint's planned start. Where there is no single team to follow — a workspace's or project's work items, a PI iteration whose teams size differently — or the team sizes by count, Story Points shows. Once you show or hide an estimate column yourself, your choice is kept; Reset Columns returns to the team's default.
What Work Items Support
Work items support:
- Parent/Child hierarchy — Work items can be nested (e.g., Epic > Feature > User Story > Task). See Hierarchy Rules.
- Dependencies — Predecessor/successor relationships with planning health tracking
- Revisions — The history of each work item's sprint, status, type, team, assignee and estimates, read from the external system
- Links — Cross-entity associations to other objects in Wayd
- References — Tracked references from other domains (e.g., linked to an objective or project)
Note: Work items in Managed workspaces (synced from Azure DevOps) are read-only. They can be viewed and linked to other Wayd objects, but cannot be edited directly. The one exception is the project of a Portfolio tier work item: see Setting a Work Item's Project.
Work Item Detail Page
The page header shows the work item's title (linking to the item in the external system), its key, its type, and its status as a tag. The breadcrumb leads to the workspace and, when the item has one, its parent. The page has Overview, Child Work Items (Portfolio tier only) and Dependencies sections, and a Forecast report under Reports for Requirement and Portfolio tier items when Delivery Forecasting is on.
Details panel:
- Type, Priority, Story Points, Effort, Size and Tags (each shown only when set)
- People — Assigned To (or "Unassigned") and Team (or "No team")
- Relationships — Parent (or "No parent"), Sprint for Requirement tier items ("Backlog" if unassigned), and Project (or "No project")
- History — Created and Updated, each with its date and time and who made it
Overview:
- Progress steps — Proposed → Active → Done (or Removed), with when the item was created, started and completed
- Timing cards, in days:
- Time Proposed (Proposed items) — now − created
- Time to Start (Active and Done items) — activated − created
- Time Active (Active items) — now − activated
- Cycle Time (Done items) — done − activated. See also the Cycle Time Report for team- and employee-level analysis.
- Lead Time (Done items) — done − created
- Child Work Items (Portfolio tier only) — the number of direct children; select it to open the Child Work Items section
- Cross-Team Dependencies — the number of the item's dependencies that cross a team boundary; select it to open the Dependencies section
- Charts, shown when they have something to show:
- Child Work Items by Type (Portfolio tier only) — the direct children by work type
- Progress (Portfolio tier only) — the work beneath the item by status category (Proposed, Active, Done): every descendant below the Portfolio tier, through any child Epics and Features, with Removed items left out
- Cross-Team Dependencies by Health — the cross-team dependencies by health. Intra-team dependencies are left out, since they need no coordination between teams
- Dependency Map (when the item has dependencies) — what the item waits on to its left and what waits on it to its right, grouped in boxes by team, with arrows from predecessor to successor colored by health. All or Open only (dependencies whose predecessor is not done) filters it, + on a work item follows the chain further out, selecting a work item opens it in a drawer, and View all opens the Dependencies section
- Cumulative Flow (Portfolio tier only) — the daily count of the same descendant work items in each status category over time
Child Work Items (Portfolio tier only):
- Grid of the direct child work items of this parent
Dependencies:
- Two-column grouped grid:
- Support for external work item links (icon linking to integrated system)
Where Work Items Appear
Work items are visible in multiple places throughout Wayd:
- Workspace detail page — All work items in the workspace
- Team Backlog section — All work items assigned to a team across all workspaces
- Team Dependencies section — Dependencies involving the team
- Sprint Backlog — Work items assigned to a specific sprint
- PI Iteration Backlog — Work items in a PI iteration
- Project Work Items section — Work items associated with a project
Work Item Dependencies
Work items can have dependency relationships — predecessor/successor links that model "this work must finish before that work can start."
Each dependency tracks:
- Predecessor — The work item that must complete first
- Successor — The work item that depends on the predecessor
- Comment — Optional context about the dependency
- State — Automatically calculated from the predecessor's status category:
- To Do — Predecessor is Proposed
- In Progress — Predecessor is Active
- Done — Predecessor is Done
- Removed — Predecessor is Removed
- Deleted — The link was removed in the source system
- Planning Health — Automatically calculated from each item's status and planned date, which is the last planned day of the sprint it is in. An item in no sprint, or in a sprint whose last planned day (UTC) has passed, counts as unplanned:
| Health | Condition |
|---|---|
| Healthy | Predecessor is Done; or predecessor is planned and successor is unplanned; or predecessor is planned on or before the successor's planned date |
| At Risk | Neither item is planned |
| Unhealthy | Predecessor is Removed; or successor is already Active, Done or Removed while the predecessor is not done; or successor is planned and predecessor is not; or predecessor is planned after the successor |
| Unknown | The link was deleted |
- Scope — Whether the dependency is within a team (Intra-Team) or across teams (Cross-Team)
Dependencies are visible on:
- Team Dependencies section — All dependencies involving a team
- Work Item detail page — The Dependency Map and cross-team counts on the Overview, and the predecessor and successor list in the Dependencies section
Work Item Keys
Every work item has a unique Key in the format \{WorkspaceKey\}-\{Number\} (e.g., PLAT-1234). The workspace key is a 2-20 character uppercase alphanumeric code starting with a letter. The number is the work item's ID in the external system, such as its Azure DevOps work item ID.
Work Item Revisions
Revisions are the work item's history as the external system recorded it, read during sync. Each revision records:
- Revision number — The source system's revision number
- When the source system recorded the change
- The values after the change of the fields Wayd tracks: sprint, status, work type, team, assignee, and the Story Points, Effort and Size estimates
Wayd builds each work item's history from its revisions, which is what Sprint Scope and the sprint burn charts read. Revisions are not shown on the work item page.
Work Item Hierarchy Rules
Work items follow strict hierarchy rules based on their work type tier:
- Only Portfolio tier work items (e.g., Epic, Feature) can be parents
- A Portfolio tier parent of a Portfolio tier child must be a higher level than the child (e.g., Epic > Feature); a Requirement or Task tier item can have a parent at any Portfolio level
- Work items cannot be linked to themselves
- Portfolio-tier work items can be directly associated with PPM Projects. Child work items inherit the project assignment from their parent, except work items in the Other tier, which never take a project.
Setting a Work Item's Project
A Portfolio tier work item's project is set in Wayd, not in the external system. On the work item's page, Edit Project in the actions menu opens a dialog that says where the item's project comes from — its own assignment, or inherited from its parent (shown as Parent Project) — and a Project list to change it:
- Choose a project to assign it to this work item, overriding any project it inherits.
- Clear the field and save to remove the item's own assignment, so it inherits its parent's project again.
Choosing the parent's project is the same as inheriting it, so that project is not offered. The work items beneath it that have no project of their own inherit the change. Edit Project appears only for Portfolio tier work items and requires the Permissions.Projects.ManageProjectWorkItems permission.
Ownership Model
Workspaces, work processes, and workflows all follow the same ownership model:
- Owned — Created and fully managed within Wayd
- Managed — Synchronized from an external system (e.g., Azure DevOps). The external system is the source of truth. Changes in the external system are reflected in Wayd via background synchronization. Managed entities display an external URL template for linking back to the source. See Administration > Integrations for configuration details.