Ticket details

Depending on the manager, a team may be accustomed to create tickets that are:

1. Minimal, with a few lines outlining the work to be done, or not even that in blank tickets!
2. Detailed, with a user story, context, acceptance criteria, assumptions, dependencies, what’s in-scope and out-of-scope, and proposed solution based on (a) technical analysis – investigative work done upfront while the ticket is still in the backlog, and (b) discussions in backlog refinement meetings, or
3. Somewhere in between.

My current team has an engineering side and an analyst side, each led by different managers with vastly different working styles. We engineers follow approach #2 above, whereas the analysts follow #1. I expect the sweet spot to be a version of #3.

The sweet spot is a balance of providing sufficient details such that there is clarity and unambiguous understanding of the work to be done, reducing wasted time and effort for whoever picks up the ticket, while at the same time not going overboard with details and prolonged backlog refinement meetings. As the manager on the analyst side mentioned, faster delivery is a competitive advantage.