Tasks
The fundamental unit of work — track, assign, estimate, and resolve.
What Is a Task?
A task is a single, trackable piece of work. Every bug report, feature request, improvement, or sub-task in Work Ops is represented as a task. Each task receives a globally unique key composed of its project's prefix and a sequential number — for example, BOS-42 or MOBILE-117. This key is permanent and never reused, making it easy to reference tasks in conversations, commits, and documentation.
Tasks are the building blocks of everything else in Work Ops. They appear on boards, roll up into sprints, contribute to velocity calculations, and feed into every report. Understanding tasks is the foundation for using the rest of the system effectively.
Task Types
Every task has a type that describes what kind of work it represents. The platform includes several built-in types, and projects can configure which types are available:
| Type | Description |
|---|---|
| Story | A user-facing feature or piece of functionality described from the user's perspective. Stories are the most common task type in agile teams. |
| Bug | A defect or problem that needs to be fixed. Bugs typically reference the expected behavior versus the actual behavior. |
| Epic | A large body of work that can be broken down into smaller tasks. Epics act as parent containers that group related stories and bugs together. |
| Sub-task | A smaller piece of work that must be completed as part of a parent task. Sub-tasks let teams break down complex stories or bugs into manageable steps. |
| Task | General-purpose work that does not fit neatly into a story or bug. Often used for technical work, research, or operational activities. |
Priority
Priority indicates how urgently a task needs attention. Work Ops provides five priority levels:
- Critical — A showstopper that blocks progress or affects production. Must be addressed immediately.
- High — Important work that should be prioritized ahead of most other tasks.
- Medium — Standard priority. The default for most new tasks.
- Low — Desirable but not urgent. Can wait until higher-priority work is complete.
- Lowest — Nice-to-have items. Address when there is available capacity.
Priority can be used to filter boards, sort backlogs, create swimlanes, and drive automation rules. For example, an automation rule might automatically assign all Critical bugs to the team lead.
Status and Workflow
A task's status reflects where it currently sits in the team's process — such as To Do, In Progress, In Review, or Done. Statuses are not free-form text; they are managed through Workflows, which define exactly which status transitions are allowed and what conditions must be met for each transition.
This means a task cannot jump directly from To Do to Done unless the workflow explicitly permits it. Workflows ensure that your team's process is followed consistently, whether tasks are updated through boards, forms, or automation.
Assignee and Reporter
Every task tracks two key people:
- Reporter — The person who created the task. This is set automatically when the task is created and typically does not change.
- Assignee — The person currently responsible for the task. Tasks can be unassigned, and the assignee can change as work moves through different stages. Some components have default assignees, so when a task is tagged with that component the assignee is set automatically.
Dates
Tasks support two date fields for planning and tracking:
- Start date — When work on this task is expected to begin. Useful for roadmap views and capacity planning.
- Due date — The deadline by which the task should be completed. Tasks that pass their due date can trigger notifications and SLA breach actions.
Task Hierarchy
Tasks can be organized hierarchically to represent how work breaks down:
- Epics contain tasks. An epic is a large feature or initiative. Stories, bugs, and other tasks are linked as children of the epic. The epic's progress is derived from the statuses of its children.
- Tasks contain sub-tasks. Any task (including stories and bugs) can have sub-tasks. Sub-tasks represent the specific steps needed to complete the parent. A parent task typically cannot be closed until all its sub-tasks are resolved.
This two-level hierarchy — epics above, sub-tasks below — gives teams the flexibility to plan at a high level while tracking execution at a granular level.
Estimation and Time Tracking
Work Ops provides three fields for tracking effort on each task:
| Field | Description |
|---|---|
| Original estimate | The team's initial prediction of how long the task will take. Set during planning and typically not changed afterward — it serves as a baseline for accuracy tracking. |
| Remaining estimate | How much work is left. This value decreases as work is logged and can be manually adjusted if the scope changes. Burndown charts use this value. |
| Time spent | The total amount of time logged against the task through work logs. This is the sum of all individual time entries. |
Work Logs
Team members record time by adding work log entries to a task. Each entry captures the amount of time spent, when the work was done, and an optional description of what was accomplished. Work logs automatically update the task's time-spent total and can optionally adjust the remaining estimate.
Work log data feeds into workload reports, sprint velocity (when using time-based estimation), and project-level time tracking summaries.
Resolutions
When a task is closed, a resolution records why it was closed. This provides more context than simply marking something as "done." Common resolutions include:
- Done — The work was completed successfully.
- Won't Fix — The issue is acknowledged but the team has decided not to address it.
- Duplicate — Another task already covers this work.
- Cannot Reproduce — A reported bug could not be replicated.
- Incomplete — The task was partially done but is being closed without full completion.
Workflows can require a resolution to be selected as part of certain transitions. For example, the transition to Closed might validate that a resolution has been set, preventing tasks from being closed without an explanation.
Labels and Components
Tasks can be organized and categorized using two complementary mechanisms:
Components
Components represent parts of a product, codebase, or team responsibility. Each component can have a default assignee, so tasks tagged with that component are automatically assigned to the right person. Components are defined at the project level and are useful for routing work to the appropriate team or individual.
Labels
Labels are lightweight tags for cross-cutting categorization. Unlike components, labels carry no assignment logic — they are purely organizational. Labels can be scoped at four levels: global (available everywhere), portfolio, program, or project. Use labels for things like "tech-debt," "customer-reported," or "quick-win" that cut across components.
Task Links
Tasks can be linked to other tasks to express relationships. Each link has a type that describes the nature of the connection:
| Link Type | Meaning |
|---|---|
| Blocks / Is blocked by | One task prevents progress on another. Useful for surfacing dependencies and identifying critical paths. |
| Duplicates / Is duplicated by | Two tasks describe the same work. Typically one is closed with a "Duplicate" resolution. |
| Relates to | A general association between two tasks that are related but not dependent on each other. |
| Causes / Is caused by | One task (typically a bug) was caused by another task's changes. |
Links are bidirectional — creating a "blocks" link on one task automatically creates an "is blocked by" link on the other.
Custom Fields
When the built-in fields do not capture everything your team needs, custom fields extend tasks with additional data. Custom fields can be text, numbers, dates, dropdowns, checkboxes, or user selectors. They are configured at the project level and can be made required or optional through field configurations.
Custom fields appear on task forms, can be used in board filters, and are available in reports. This extensibility means Work Ops adapts to your process rather than forcing you into a fixed structure.
Comments and Attachments
Tasks serve as a collaboration hub. Team members can add comments to discuss approach, ask questions, or provide updates. Comments support mentions to notify specific people and keep conversations focused on the relevant task.
Attachments — screenshots, documents, design files, log excerpts — can be added directly to a task. Keeping these artifacts with the task ensures context is preserved and easily accessible to anyone who picks up the work.
Audit History
Every change to a task is recorded in its audit history: status transitions, assignee changes, priority updates, estimate adjustments, comment additions, and more. Each entry captures who made the change, when it happened, and the before-and-after values.
The audit history is invaluable for understanding how a task evolved, investigating process bottlenecks (such as how long tasks sit in review), and maintaining accountability across the team.