What makes for good project task/ticket content is often overlooked but this quick read can dramatically improve your project effectiveness.
A well written task:
- is understood by the member that its assigned to, and whoever else encounters it.
- it provides a brief but precise outline on the requirement or issue at hand.
- it provides the criteria required to work on the ticket. Including resources, error logs, how to replicate etc.
- it provides the criteria to sign off the ticket, a checklist of todos and expected results.
- allows for team members to work independently avoiding blockages.
- allows for progress tracking and estimated remaining effort at task & sprint level.
- follows a well structured & familiar pattern, thus allowing for better team discipline and adherence.
All project tasks/tickets tend to share at least the following:
Title : a suitable title to insinuate the tickets purpose
Description : a brief overview of the requirements / issue at hand
Assigned users : fewest users per task & balance workload between users
Status and Progress : To be able to track the tickets and sprints progress
Duration : notwithstanding story points, management still want deadlines
Task Category : categorised tasks make for meaningful effort tracking
Tags : to associate and easily find, & refer back to other tickets.
Priority : for meaningful next task selection when a previous ticket is done
Different types of tickets might best be structured in different ways. For our purposes we will just look at the the Development Ticket and the Bug Fix Ticket. The task template could always be made more complex but the real trick is , “how straight forward can you make it so as not to overwhelm but still remain useful and relevant”?
Below we share an example of each:
Development Ticket
The example ticket is presented in Markdown as this is often used in online project tools and may be conveniently pasted into a new ticket as a working template if required.
### Description
- A brief overview of the development requirements.
- Must be understood by all team members.
### To Do
Clearly stated requirements, preferably in the form of a checklist.
> Checklists always make for clearer progress communication.
- [ ] checklist item 1
- [ ] checklist item 2 ..
### Resources
- [Links](https://github.com), example logs, designs to make use of.
### Expected Results
Clearly stated expected results, preferably in the form of a checklist.
- [ ] expected result item 1
- [ ] expected result item 2 ..
### Testing
- If applicable, clearly state:
— How to test
— Any Prerequisites
— Expected results when testing
---
Attachments: add resources, designs etc as attachments if required.Bug Fix Ticket
> SEVERITY: eg.Hotfix, with branch/environment affected
### Issue
A brief overview of the issue at hand.
### How to replicate
A detailed guide on how to replicate the issue,
is best to provide example images and error logs if any.
### To Do
Clearly stated requirements, preferably in the form of a checklist.
> Checklists always make for clearer progress communication.
- [ ] checklist item 1
- [ ] checklist item 2 ..
### Expected Results
Clearly stated expected results, preferably in the form of a checklist.
- [ ] expected result 1
- [ ] expected result 2 ..
### Testing
If applicable, clearly state:
— How to test, including which data fixtures to use
— Any Prerequisites
— Expected results when testing
— Regression checks
> See also: [related-ticket](link-to-related-ticket)—
