Task management · Practical guide
How to Write a Task Description: Template and Examples
By My First Task editorial team
Updated
The short answer
How to approach the work
A title such as 'Fix checkout' hides several decisions: which checkout, what fails and what counts as fixed? Start the title with an action and an observable result. Keep the description proportionate to the risk. A small copy edit may need a sentence and a screenshot; a payment change needs affected cases, exclusions and review evidence. Separate the requested outcome from a suggested implementation so the owner can identify a better solution. If a detail is unknown, name the person who can resolve it rather than inventing a requirement.
A practical sequence
- Write an action-led title describing one finishable outcome.
- Explain the problem and link the source request or supporting evidence.
- Name one accountable owner and any required reviewer.
- List the deliverable and testable acceptance conditions.
- Record dependencies, constraints and work explicitly outside scope.
- Agree the due date with the owner and update the description when the decision changes.
Illustrative scenario · not customer research
Worked example
Weak: 'Update help page.' Better: 'Explain how to reset a forgotten password on the help page.' The owner is the documentation editor; the reviewer is the support lead. Inputs are the current reset flow and approved screenshots. Completion means the steps match the current product, links work, and the page can be read on a phone. Changing authentication behavior is outside scope. If the flow differs from the screenshots, the editor asks support before publishing. This makes review concrete without prescribing every sentence.
Task description template
Adapt this starting point to your own project. Examples describe a planning practice, not an automated app workflow.
| Field | What to write |
|---|---|
| Outcome | Change [thing] so [observable result]. |
| Context | This matters because [problem]; evidence: [link]. |
| Owner and review | Owner: [name]. Reviewer: [name]. |
| Acceptance | Complete when [checks and evidence]. |
| Constraints | Depends on [input]. Excludes [scope]. |
| Timing | Agreed date: [date]; review if [assumption changes]. |
Common mistakes to avoid
- Writing a title that names a topic rather than an action.
- Assigning several owners without identifying who coordinates completion.
- Treating a suggested approach as an approved requirement.
Try the method with your own inputs
Questions answered
How long should a task description be?
Does every task need acceptance criteria?
Where should decisions made in chat go?
Apply it in a shared workspace
Keep the agreed owner, completion criteria and important decisions with the work. Explore the relevant My First Task feature.
Research context is available in our source library. The worked example above is an editorial illustration.
Continue learning
Acceptance Criteria Examples: A Practical Writing Guide
Acceptance criteria are observable conditions a particular work item must satisfy before it is accepted. Write them around behavior and evidence, including important failure cases. A definition of done sets broader quality expectations across work items.
ExploreHow to Assign Tasks: Ownership, Deadlines and Follow-Up
Assign a task by agreeing the outcome, accountable owner, required inputs, finish condition and realistic timing. Check the person's capacity and authority before treating the assignment as an accepted commitment.
ExploreDefinition of Done vs. Acceptance Criteria
A definition of done is the shared quality standard applied to completed work. Acceptance criteria describe the specific behavior or deliverables required for a particular task. Together they make completion more consistent and reviewable.
ExploreTurn the plan into shared work
Give each next action an owner, a completion condition and a realistic date. My First Task brings tasks, boards, project workflows and issue tracking into one workspace.