Write a work item that someone can understand, act on and check. Keep the purpose, useful context and acceptance criteria together, then choose the people and planning details that fit the work.
Illustrative model · An illustrative model of a clear Definition; the saved work stays the source to check.
Start with the right owner
A place for the work. A result worth naming.
Open the Project or Team responsible for the result and choose New task. A work item belongs directly to that Project or Team. Its owner supplies the identifier prefix and available workflow.
You need access to an active owner to create work. An archived item or owner cannot be edited. Check the workspace’s plan limits if creation is refused.
In What needs to happen?, write what should be different when this work is finished. “Customers can download a receipt” tells the reader more than “Receipt changes.”
Choose an available work type.
A Story can describe a user-facing result, a Task a concrete action and a Bug a defect. The workspace and Project decide which types are available. A type does not automatically choose the workflow stage.
Keep one item understandable.
If the work contains several separate results, give each a clear definition. Use a parent and subtasks for a larger outcome, or a relation when separate work needs to stay connected.
Write the Definition
Explain why. Show what to check.
Expand Context & criteria in the creation form. For saved work, open Definition. Context explains the problem, useful facts, limits and sources. Acceptance criteria describe the observable checks that the result needs to pass.
Context and criteria support Markdown. Keep the text short enough to read, but include the facts someone would otherwise need to ask for.
Explain who needs the result and what problem it solves. Describe the current situation before giving a proposed approach.
02
Set the boundary.
Say what this item covers and what can wait. Name constraints such as a supported format, an agreed design or a decision still needed.
03
Link useful sources.
Add the guidance, decision or example needed to act. Check that the contributor and reviewer can open each source with their own accounts.
04
Write observable criteria.
Use concrete behavior someone can try or evidence they can inspect. Include a relevant failure case instead of ending with a broad phrase such as “works correctly.”
05
Read it with the contributor.
Ask them to explain the result and how they will check it. Add missing facts before treating the work as ready to start.
A definition people can use
Turn a broad request into a checkable result.
“Improve receipts” leaves the scope open. A useful definition says who needs a receipt, where they get it and what happens if the download fails.
The example is a writing pattern, not a product requirement. Adjust the details to the real decision, user and constraints in your own work.
Before you start, agree who checks the output. Put a useful decision in Conversation and update the saved Definition when the scope changes.
Synthetic example · an illustrative work-item DefinitionPORT-1 · Story
Customers can download a receipt.
Context
Customers currently ask Support for a receipt. Add a PDF download for completed orders from the order page. Refund receipts are outside this item.
Acceptance
The PDF shows the correct order number, payment date and paid amount. A customer can download only their own receipt. A failed download shows a clear message and allows another attempt.
Sources
Link the agreed receipt format and order-page design in the real task. Check that both the contributor and reviewer can open them.
Verification
Try a completed order, a different customer’s order and a failed download. Save the results and link the output before completion.
Choose useful planning details
People, scope and dates need different choices.
Expand Planning & assignment before creation. On saved work, use the field’s edit control and Show all details for secondary fields. These choices help planning; they do not replace the Definition.
Assign crew
Choose the contributors.
Select eligible active members who can access the owning Project or Team. You can use several assignees. Agree who will coordinate the next step and who will check the result.
Assignees are the people doing the work. The item’s Project or Team remains its owner.
Complexity or Story points
Use the current scale.
The administrator chooses T-shirt sizes, XS–XL, or story points, 0, 1, 2, 3, 5, 8, 13 and 21. Use the choices shown in your workspace to discuss the work’s size and uncertainty.
An estimate is not a promised duration. Clarify missing context before agreeing a value; Not sized is available when an estimate is not ready.
Due date and Start in
Use a date for a real deadline.
Choose Due date when the work has a meaningful deadline. Explain the reason and any dependencies in Context. Choose an available open stage in Start in that matches the actual state.
A date and an estimate answer different questions. Review both when the agreed scope changes.
Save lasting facts in Definition. Use Conversation for questions, decisions and meaningful progress. Link related work when it explains a dependency or a larger outcome.
Link outcome evidence.
Outcome documents links decisions, findings and delivery evidence held in Knowledge. Use Attach file for supporting files when available. Check access before relying on a source.
A template can supply a useful Definition and planning defaults where enabled. Read the resulting fields and adjust them to this task instead of carrying over an old assumption.
Where enabled, select relevant Procedures and check required reading for agent work. Supported agent changes need pinned reading and a current receipt. An ordinary document link does not make that reading required.
A reading receipt records delivery to the agent. It does not prove understanding or correctness. Review the proposed result against the Definition and its sources.
Check before you complete
A finished action. An outcome with evidence.
Use the owner’s configured workflow stages. Keep the item in the appropriate review stage while a required check remains. Once the acceptance criteria pass, link the output and record what was verified in Completion summary.
Then use the configured completion stage. The stage’s Completion setting controls completion; its visible name alone does not.
Discovery needs an active outcome document before completion. Business Cases need their forecast, benefit period and success criterion. Check the requirements of the chosen type.
Do I have to fill in every field before creating work?
Many details are optional, and you can add them later. Give the contributor enough context and observable criteria to act. Use estimates, labels, assignments and dates when they help the real work.
Does choosing an assignee change who owns the item?
The item remains directly owned by its Project or Team. Assignees identify the contributors. Agree who coordinates the next step and who reviews it. The owning Project or Team stays the same.
What if the estimate choices differ from this example?
The workspace administrator selects T-shirt sizes or story points under Admin → Settings → Work estimation. Use the current choices shown in your workspace. Existing estimates are kept without automatic conversion when the method changes.
Where should a decision from a discussion go?
Keep the discussion in Conversation. Update Definition when an agreed decision changes the goal, scope or acceptance criteria, and link the relevant decision or outcome document.
Does an acceptance checklist complete the work automatically?
You still check the outcome and use the configured completion stage. Acceptance criteria describe what to verify. Add the output and a useful Completion summary so the next reader can see what happened.
Keep the next step possible
Clear work. Clear handoffs.
If progress needs another result first, connect the work and explain what has to happen next.