Ticket Driven Development: Why Devs & Product Owners should work together to improve ticket specs.

Generally teams working within an agile methodology work in two weeks sprints and complete a series of tickets that correspond to bug fixes & new features.

Sounds like a good system right? Allow me to provide a fake example of how it can go wrong:

Product Owner: I want a grid of images.

Ticket: Get a set of images from this * database of images * and display them in a grid.

Developer: * finishes feature*

Product Owner: Potential queries or things that could potentially come up:

1. Some of the images are cut off partially by the box.
2. Why have you only got the first 5 images instead of all 100?
3. Some of those images look amazing why do the others look pixelated?
4. Why don’t the images load quickly, it’s only a few images?
5. Hmm none of the images have appropriate caption text, why not?
6. This page now takes ages to load what did you do ?

On the surface this seems like a simple enough ticket and a good chunk of devs may be tempted to pick it up and run with it, heres what I see straight away:

1. Do you want the images to be interactive? — Should they do anything onHover / onClick?
2. Do the images have alt text or captions?
3. How many images do you want to load at a time?
4. Do you want it to simply get the first * x * amount of images from the database?
5. Are the images already processed to ensure they're all a certain size or do you want that to occur on the frontend ?
6. Are the images optimised ? Do they need to be optimised if not?

On the surface you can see how a seemingly simple ticket has a bucket load of potential options. This is neither the product owners or the developers fault but it is a problem you two could solve together by simply querying a ticket and going back and fourth to improve the spec.

This seems it would incur a time penalty on ticket writing but it actually saves time over the long term whilst highlighting unknowns and hardening the feature and its functionality, which will improve your code base as well as the relationship between devs & PO’s.

Never be afraid to bat tickets back into the bush for discussion it’s actually healthy and frankly improves process.

All of a sudden the product owner is happy as they are getting what they really want and the developer is happy because they have a more robust plan to build from.

Note: This is an extremely basic example there are a whole host of other things that could and should be included on tickets that have been purposefully avoided.

If you liked this article give it a clap and follow me :).