Foundations of Agile Ticket Writing: Independent and Negotiable

This is a multipart series covering the importance of ticket writing with explanations and examples using INVEST principles. Part 3 of 4.

Next in INVEST is I = Independent and N=Negotiable.

Keeping tickets small makes them more manageable. Manageable tickets are also independent, meaning they can be worked and shipped independently of any other ticket.

Why? If tickets are small in scope but they have multiple dependencies, then they’ll suffer from the same downsides as big tickets: blocked engineers, increased back and forth, and decreased visibility to what is completed and can be shipped.

Always creating tickets that are both small and independent may seem unrealistic. But when engineers are challenged to break out the work into small, independent tasks, they tend to find implementation solutions that work for everyone. Once everyone on the team is aware that all tickets need to be independent, a joint effort can help flag if there are dependencies and the team can work to uncouple where possible.

I decided to group I=Independent and N=Negotiable together because both rely on getting signoff and feedback from your engineers.

Because they allow for input from team members with different perspectives, tickets that are negotiable tend to lead to better outcomes. That said, there are some best practices to follow in collaborating with engineers.

It is important to remember that engineering can be both subjective and creative. There can be multiple ways to approach a problem and some engineers default to either how they have done it in the past or challenging themselves with something completely new. In both cases, it can be valuable to facilitate a ”pros and cons” conversation about different implementations.

For example, implementing signups with one framework may lead to a speedier delivery, but the maintenance of that code may be more time-consuming in the long term.

Encouraging engineers to get a second opinion will help surface tradeoffs that may not be clear from the outset. However, a Product Manager should be pragmatic with his or her time. Trying to spark a conversation for every single ticket is not feasible for most; it’s best to focus extra attention on features that use new technology, are time-sensitive, or are high-priority for the client.

Takeaway

Product Managers should be fluent in enough tech to spark relevant conversations with their engineers so they can maintain independent and negotiable ticket structures.

VALUE Part 1 of 4

SMALL Part 2 of 4

ESTIMABLE & TESTABLE 4 of 4