Work items
The unit of work in DevGob: the types it comes in, and how they nest.
Types of work item
Every piece of work is a work item. Its type decides where it sits in the hierarchy, which fields it carries and which states it moves through.
- Epic and Business Case: portfolio-level goals, and the business justification behind them.
- Feature: a deliverable capability, under an Epic or a Business Case.
- Product Backlog Item — or User Story, in the Agile process: the work a team commits to in a sprint.
- Task: the concrete steps that complete an item.
- Support: service work, under a Feature.
- Issue, Impediment and Pre-release Defect: problems raised on the work they affect.
- Bug: a defect found in a Deployment.
- Deployment and Data Change: governed changes to production, each with its own flow.
How work items nest
Parent and child links follow fixed rules, so the hierarchy always reads the same way. A Business Case may belong to an Epic, and a Feature to an Epic or a Business Case. A backlog item or a Support item belongs to a Feature. Tasks, Issues, Impediments and Pre-release Defects belong to the Feature, backlog item or Support item they concern — and so do Deployments and Data Changes. A Bug always hangs from the Deployment where it was found.
States and transitions
Each type moves through the states defined for the workspace. Moving from one state to another is a transition, and a transition can require a permission, a written reason, or fields that must be filled in first.
- Fields can lock once an item reaches a state, so an approved value cannot be quietly changed afterwards.
- Every change is recorded in the item's history, with who made it and when.