It’s important that anyone can raise a ticket of any standard; sometimes time is tight and it’s important to just get something in writing and into the process.
However, when a developer accepts a ticket, they should immediately go back to the ticket requester if they don’t get:
- Situation: Briefly, where we are
- Why: The overall intent; the purpose
- What: An extrapolation of the more specific requirements
- Boundaries: what not to do
This is not onerous. It’s really what the best tickets already do.
Ideally all tickets will turn up this well constructed. The next step is crucial.
Instead of starting work, when a developer accepts a ticket they will carry out a ‘back brief’:
- Complete their analysis
- Add a handful of bullets to the ticket as to how they’re going to complete it, i.e., a handful of precise, discrete steps
- Call whoever raised the ticket & run them through the steps
Completing tickets in this way will:
- Make sure the developer correctly understands the task at hand.
- Allow the developer(s) to provide a solution which delivers as per the ticket but is also built in a way which has a bit of foresight with what might come next.
- Make everyone think about the detail of the tickets they’re raising which means there won’t be lots of back and forth between the raiser and the assigned.