If there's a single thing that's important in order to get good performance from the engineering function it's momentum. Nothing kills momentum for a developer like having to wait on the business to provide the details of their tickets.
Writing Good Tickets takes time. A rule of thumb on our teams is that for every single-developer-project, we need 10 man hours per week on the product side dedicated to writing tickets and testing.
Bug Ticket
Bug tickets should include sufficient information so as to allow the developer to fully understand, replicate, and fix the issue. Generally 3 or more of the following should suffice:
- A screenshot or recording of the incorrect behaviour
- One or two sentences on why the behaviour is incorrect (unless it's blatantly obvious from the screenshot). Assume the developer assigned to fix might not be familiar with the product/area.
- The full url the bug was experienced at (can be included in a screenshot).
- The email address of the user/users who experienced it (and user id if known).
- A list of steps to take to replicate it.
Example: Bug Ticket Example
Improvement Ticket
An improvement is a small modification to an existing screen or feature. Some Examples:
- Add a new field to this form.
- Improve this copy.
- Remove this step from the form.
- Add a tooltip here
On the UI/UX side, unless the changes introduced are text only, it's generally advised to draft up a low-fidelity wireframe (e.g excalidraw). If the improvement uses an existing UI element or component, that should be explicitly mentioned ("We're going to use the progress stepper from the onboarding flow").
If the change is likely to affect the layout, direction should be given on how to handle this. For example, we're updating a piece of help text from being 3 words to a full paragraph - this increased text is likely to move some of the other UI elements further down on the page. Maybe we want to use a "read more" button to expand/collapse it.
Things that need to be covered
- All copy text, including language translations where applicable.
- If the improvement contains form fields with validations, the validations should be described.
- If the improvement has business logic, it should be described. Here's an example of business logic from Slack.
- If the improvement triggers email or sms notifications, the ticket should describe when exactly to trigger them, what they should look like (if there is any email design required), and the copy.
Example: Improvement Ticket Example
Feature Ticket
Example: Feature Ticket Example