[captain_crabs]

And final thought, "correct" or not, a guiding principle that's proven useful over time: individual tickets should deliver true pieces of "value" which is to say, once deployed, the software does more of what people need than before. So when a ticket is "done," it means something was improved however it was needed across all levels of the stack.

None of this "button here" "wire it up later" "now add the db table" etc.

[bloomca]

I think it is possible only in simple software (when you are developing an MVP, or just early stages).

Complex tasks are incredibly hard to finish as a single ticket – with such granularity you might have opaque progress for couple days, and you hide a lot of details from everyone.

Unless you mean "tickets" as "user stories", they can be (although not always) treated like that.

[captain_crabs]

God I can't stay away from this thread.

Yeah - entirely depends on your subdivision vernacular. Some people make subtasks in a ticket, some people make tickets linked to other tickets, some people do both and link those to "features" which are themselves tickets (like the environment I work in).

Just depends!

[captain_crabs]

Sounds like we agree, but use different names for the same things and some of the same names for some different things! :)