Backlog items can start as rough ideas though. Refining of a ticket can be done later when you need to. But it can only be started to be worked on when the team thinks it is refined enough.

In my experience, if you go this route what you end up with is a thousand tickets with a title and little to no description text that eventually get deleted because you can't figure out what it was about six months later (even if you're the one who wrote it).

And that problem somehow goes away if you store that same information in a separate system?

No, but it's about keeping the ticket box signal to noise ratio in check. One box for actionable, high signal items. One box for all the ~junk~ ideas.

Junk ideas are useful to document too. When the idea resurfaces, one can read why it did not get through the first time.

A ticket-system like JIRA is the same as an e-mailclient to me. You sort by activity, having the most active tickets on top. You can flag/mark them, you can put them in different boxes or just use tags,... All are just means to create order in chaos.

But I would never think to move my old e-mail to a different 'system' than my normal e-mail(client). I never think of old e-mails or drafts as something I need to clean up.

Yes, because you just don't look at the list at all.

Which is fine, you can then save even more effort by never writing them down at all.

Those don't need to be separate systems, and keeping them in one system is often beneficial to see the evolution of the concept.

I'll frequently have an idea and toss it into a backlog ticket. Maybe just as a title to start. When a customer mentions that problem/feature, I can add that info in the backlog even if it doesn't immediately become a priority.

When the issue does become something worth working on, I'll usually add more details but the various evidence accumulated over 6 months of letting the item "bake" is invaluable.

They don't need to be in principal. But in practice I've yet to find a tool that does both things well.

Why does your second system get to have information written in it that the first doesn't, or get to be more vague? You can write tickets at any level of detail.

You can then just tag them.

This means that a search can ignore them, or it can bring them up while you're looking at features/etc.

> You can then "just" tag them.

All that administration overhead is why the ticket based system doesn't get this information. If it takes 30 seconds to create (and properly organise/categorise) a ticket then that's too slow. I want to be able to write tickets as fast as someone can say them, and move/reorder them with my usual copy paste / text editing tools.

This seems like a very niche and uncommon request. The vast, vast majority of tickets I've worked on (90%+ for sure, maybe 95%+) have had multiple people putting in context, additional information, related/blocking/blocked links, reproduction steps, accessibility requirements, security requirements, etc. Not all tickets require all this info, but most of them require at least a couple of these categories. I obviously don't have the hard data but I would hazard a guess that the median ticket I deliver has been at least 15-20 minutes of total work from at least 2 or 3 people. Much higher when you're talking about greenfield development of something that is getting any level of scoping ahead of time.

This is across 8-10 jobs in multiple industries over close to 20 years. Some places have been better or worse than others but I can't think of any place where people routinely were creating, organizing, and categorizing tickets this quickly, at least not tickets that had any value to anyone other than them as a reminder to do one very specific thing.

> I would hazard a guess that the median ticket I deliver has been at least 15-20 minutes of total work from at least 2 or 3 people

Sure, for tickets that you deliver. But when we're talking about managing a backlog there might be 50 potential tickets that never get implemented (or even scoped) for every one that does. And you don't really want those to ever become a ticket at all because that ends up being far too much product work, precisely because it takes ~20 minutes for each ticket.

Put another way: you need a way to track high-level work for prioritisation before putting too much into scoping and detailing what implementing it would involve.

There are feature requests and there are what I would think of as design decisions / genuine defects depending on how you see it.

For example, ctrl shift v is how you paste unformatted in ms teams. You’d think by that logic, ctrl shift c would be copy but no it starts a call. There is no built in way to eliminate that and when I ask ms people they say “oh use powertoys and blah blah I had to do the same”.

There are multiple times this has been raised on the forums

https://answers.microsoft.com/en-us/msteams/forum/all/turn-o...

Do you want to put things like this on a different list, basically a “won’t fix” list? Why even write them down? Just to make people think you are listening?