Well-written tickets are mana from heaven. Programmers love them because it means that most of the work is already done. The hard part is over. They get to ride through the gates of Rome in triumph (aka. coding-up well written specs).
Here is a non-exhaustive bestiary of ticket types
The new feature ticket
You want your product to do something new. You need:
- a good summary title
- a user story
- acceptance criteria
Let's go through these.
A good title will help everyone refer to the ticket more easily. Don't go beyond 10 words and aim for 5 words.
A user story is an informal description of the software feature. It's crucial to have a user story in a feature ticket. An example of a user story format:
- Template: As a <role> I can <capability>, so that <receive benefit>
- Example: As a store owner, I want to add items back to inventory when they are returned or exchanged, so that I can track inventory.
The acceptance criteria list all the conditions the software needs to satisfy before it's considered implemented. An acceptance criterion should follow the given-when-then format. See 2 acceptance criteria of the user story example given previously:
Scenario 1: Items returned for refund should be added to inventory.
- Given that a customer previously bought a black sweater from me and I have three black sweaters in inventory,
- when they return the black sweater for a refund,
- then I should have four black sweaters in inventory.
Scenario 2: Exchanged items should be returned to inventory.
- Given that a customer previously bought a blue garment from me
- and I have two blue garments in inventory
- and three black garments in inventory,
- when they exchange the blue garment for a black garment,
- then I should have three blue garments in inventory
- and two black garments in inventory.
The bug ticket
The – regrettably – all too common bug ticket. The gold standard is simple:
- Actual behaviour
- Expected behaviour
Use the given-when-then format when describing the actual and expected behaviour.
The algorithm ticket
An exotic specimen. When you have existing business logic that needs to change. If you're working in a clean codebase you should be able to point out to a piece of code that implements the behaviour that needs to change. This is very helpful because the developer doesn't need to spend any time looking for the piece of code he/she needs to change.
Sources: