My personal heuristic: if it is worth doing, and it takes less than an hour -- just do it now. Organize your team so engineers feel free to knock off quick tasks at their discretion.

If you try for an hour and it's still not done -- make a ticket.

There's nothing more annoying than seeing the same trivial task get shuffled around 4 sprint planning meetings, taking mental overhead from 8 people.

And nothing comes out of sprint planning with less than a quarter day allocated. You've turned a 20-minute task into a whole day of wasted effort.

> My personal heuristic: if it is worth doing, and it takes less than an hour -- just do it now.

Sure, but that doesn't mean you can't create a ticket for it. It just means that you have tickets which fall outside your sprint planning flow.

Some of us are lucky enough to not have a sprint planning flow, and we can have a lot of leeway how we plan our time, which doesn't require tickets.

You can create tickets for every small thing, but it might not be very efficient.

You can also just create 1 ticket with a bunch of small things.

The devs on my team are encouraged to move tickets around and plan their time however they want, but JIRA allows our product, design, dev, and qa teams to coordinate without being in the same room every day. It's just another form of async communication that helps us make sure we're shipping everything we promised, and fixing all critical bugs before the end of the week.

Yes, it's basically the same for us as well. And we do group together smaller things into one ticket often.

For us tickets are most important to track what gets included in releases and patches, and to tell QA to test our branches (and we almost always require QA to test our branches before they're merged).

My point is that the overhead of writing up a ticket description becomes a significant fraction of the total work involved. Write a commit message if you want it documented.

There's no need for a ticket for small tasks, unless you are being evaluated on number of tickets closed (which is a separate problem)

Like all things in life it depends on the team and workflow. I have my PM’s make tickets because many times I am in the middle of a different feature or bug and don’t want to have to have the mental load of remembering what the issue was. Secondly I work with very solid PM’s who document the ticket very well and it saves me time having to reproducing the issue. My team does have a lot of tickets but we make it work for us and our process flow.

On the other hand, being forced to write something up gives you extra time to think about what you're about to do. I've had many experiences when I was about to commit what I thought was a trivial change to the code, but then suddenly realized that it was going to break something.

> if it is worth doing, and it takes less than an hour -- just do it now

Huh... you've never had 10 things that are worth doing that take less than an hour? Or did you just line them up and work 10 hours that day?

Just do it now maybe works on small projects, but large projects that span multiple teams and stakeholders typically have enough little tasks to complete that “just do it” might be referring to 1 of 50 different things.

You need some way to prioritize and work against those priorities, typically measuring impact or some variation of ROI.

I totally agree with this, providing your team is strong and motivated enough. As a contractor, this is usually the case for me, but definitely not always.

I use tickets to offload my memory and ideas for later thought.

And as bonus points it can effectively prevent people from gobbling up only the work they want to do and leaving the shit for everyone else.

I have my own todo list independent of the bug tracker.

I think having a ticket also helps coordinate things if your working between global offices. Also, having a ticket helps others pickup if your out of the office. This has saved my team many times.