Why? Why have two places for the same thing? It's just an awkward tagging system. When would you search this but not search tickets?
Alternatively, just don't write them down. If you don't get a benefit from keeping the idea, don't write it down.
Mid-option, I think linear does this by default, cancel backlog items older than X. Not been touched or moved? Probably not relevant. Plus you can always search through cancelled tickets.
> Why? Why have two places for the same thing? It's just an awkward tagging system. When would you search this but not search tickets?
A ticket is a different level of detail. Takes more time, thought and effort to put together a good ticket. If it's for something that's not going to happen for 12 months, then there will have been enough change in the product/org/etc. that the original ticket won't work as written anyway.
A doc with a bunch of categorized feature ideas has enough info that you don't lose any good ideas, and then when it's actually time to attack one of those categories, then you can do the work of building out actual, ready-for-implementation tickets.
> Alternatively, just don't write them down. If you don't get a benefit from keeping the idea, don't write it down.
Totally agree with this. A lot of stuff isn't worth writing down. If it's way out in the future and really important, it'll come up again anyway.
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).
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.
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.
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.
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
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?
A ticket is something where there is an understanding that we want to do it if time and resources permit, something where it would be okay for someone to grab it and do it.
On the other hand, an idea or suggestion may easily be something that should not ever be done, that drives the product in an inappropriate direction or adds an ability that we don't really want to exist for various reasons; and that is conceptually fundamentally different and should be kept in a separate place from the "big todo list".
> A ticket is something where there is an understanding that we want to do it if time and resources permit, something where it would be okay for someone to grab it and do it
If you want it to be that, sure. They're really just notes with IDs and tags. What you're describing is a curated backlog / upcoming work.
> On the other hand, an idea or suggestion may easily be something that should not ever be done
Ok? So either say why and cancel the ticket or delete it if you don't want a record of it. I don't get the value of writing it down in a different place so that you have to search in two places.
How's is "cancel after X days" any better? Are there not enough decades-old bugs around to illustrate how it's not a good proxy? Why search through cancelled tickets which are resolved to find and unresolved issue? That's just a category error
The vast majority of tickets that haven't had any interaction for some length of time are irrelevant, it's an excellent proxy.
But it's worth reading the comment in context. If your problem is that old tickets are a nuisance because they're almost always irrelevant, just have them auto cancel and when you get that notification rescue the 2 per year that you truly want to keep.
If you don't have that problem, keep them.
> Why search through cancelled tickets which are resolved to find and unresolved issue?
It's just an excellent proxy of insufficient resources, nothing more. A missing feature doesn't automagically appear with time to make the ticket irrelevant. If it's not relevant, it shouldn't be in the system in the first place
> when you get that notification rescue the 2 per year that you truly want to keep.
That makes even less sense. Looking at notifications and making a decision on closing/reopening is a form of review. If you have time to review, do it properly on your own schedule and in batches rather than be beholden to some arbitrary autoclose timeline with yet another focus-destroying trickle of notifictions
> If it's not relevant, it shouldn't be in the system in the first place
It was when it was created, it's not now. And it is then practically removed.
Again you can build whatever workflow you want, tag stuff or move things if they're super important to you. Subscribe to them if they're vital. Or don't auto close if that doesn't work for you.
I don't think that having a tiny number of issues that are
* Never looked at
* Never prioritised
* Never searched for
* Not subscribed to by anyone that cares about them
* Somehow super important to not have a "cancelled" status on them
Should define your workflow to this degree that you start keeping multiple lists of work. I'm not sure I've ever come across an issue worth leaving like this. Can you tell me about an issue that fits this description?
> When would you search this but not search tickets?
The trick is to have each "ticket" be basically a bullet point in a list (where lists are grouped by headings/subheading in a single document). Maybe some are 3-4 lines, but most will be a single line bullet point. That way you don't have to search it (which doesn't tend to work very well as you won't know what you're looking for), you can actually browse the entire document.
Why? Why have two places for the same thing? It's just an awkward tagging system. When would you search this but not search tickets?
Alternatively, just don't write them down. If you don't get a benefit from keeping the idea, don't write it down.
Mid-option, I think linear does this by default, cancel backlog items older than X. Not been touched or moved? Probably not relevant. Plus you can always search through cancelled tickets.