Ticketing (really, work tracking) needs to be adapted to each organisation. This is of course not a complete list, but some patterns I've seen: - In a three-de

Ticketing (really, work tracking) needs to be adapted to each organisation. This is of course not a complete list, but some patterns I've seen: - In a three-developer startup a ticketing system might very well be just needless busywork. You probably have plenty of urgent things to disprove so that you can iterate as fast as possible. Put them on a whiteboard, and make sure everyone is on the same page about what you're building every day. - In an organisation where the tickets may live longer than someone's tenure a formal ticketing system may be necessary, if only to make sure long-term ideas are not lost or forgotten. - In an organisation with more than four developers working on the same thing long term you probably need tickets just - A lot of managers unfortunately don't realise how time-consuming and soul-crushingly boring it is to fill in every single field in an "advanced" ticketing system, like priority (just order things in the backlog!), severity (should be part of priority, not its own field), cost (ditto), deadline (ditto), sprint # (ditto dammit!), reported by (should be recorded automatically), and tags (who actually thinks those are accurate across the board and have the same meaning to everyone?). These orgs don't need an advanced ticketing system, but use them because they are more enterprise-y and that feels good to middle managers who care about visibility rather than productivity. - Huge orgs which have lots of geographically distributed developers working on the same thing definitely need an advanced ticketing system, if only so different people aren't doing the same work in parallel.