7 ms·

In my experience, this depends a lot on how you organize possible features/improvements/etc. I hate the strategy of just taking every idea you hear and throwin

In my experience, this depends a lot on how you organize possible features/improvements/etc. I hate the strategy of just taking every idea you hear and throwing it into a ticket. You just end up with this giant icebox of stuff you'll never do. If a big new prospect demands one of the ideas that's in the icebox be implemented immediately in order to close a deal, you're probably still not going to pull it out of the icebox, because you don't remember that it's there. Instead, you'll just create a new ticket for it, and eventually when going through the icebox, someone will go "hey, I think we built this already" and close as dupe. Instead, I strongly prefer to have tickets that at least have some possibility of getting done in the short to medium term, and store other ideas elsewhere. Engineering keeps a list of tech debt that they'd like to address. PMs keep one list per project of possible improvements. For potential new features/products, they write PRDs but don't immediately turn them into a bunch of tickets. Ultimately I think the giant backlog of stuff that mostly won't get addressed is a sign of weak PMs who are afraid to say no and like to fall back to the comfortable answer that is, "sounds interesting, I'll write a ticket for it."

stag91 3y ago
Totally agree re: everything's a ticket. I consider the backlog to be only prioritized work - things we determined need to happen they're just not happening right now. Features we've agreed on, tech debt, etc. I do think it's important to organize all feature requests, pain points, feedback etc. though but it needs to be separate of delivery management and it should be thematic (assuming there's a lot of feedback). That's the point of CustomerIQ (I'm a founder), to give that a home but also quantify themes over time. These would inform the backlog/possible make it in, but keeps delivery tools cleans.
alexanderchr 3y ago
Very similar to what's recommended in Basecamp's Shapeup book: https://basecamp.com/shapeup/2.1-chapter-07 https://basecamp.com/shapeup/2.1-chapter-07
hakunin 3y ago
Agree with all of this, and recommend this process for engineering tech debt: https://max.engineer/long-term-refactors https://max.engineer/long-term-refactors In short: maintain a list of long term refactors that everyone's gradually working on, without necessarily showing it in the ticket tracking system.
roenxi 3y ago
Although the approach seems fine, I don't think it creates an advantage. The situation is there are tickets in progress that have engineering consequences and then there is the backlog. How the backlog then gets used is 100% a question of convenience and any approach that works for the decision makers is fine. If they want to use the backlog as a way to plan upcoming work (as you seem to do) that is fine. If they want to use the backlog as a diplomatic tool to say no gently, also cool. JIRA + a tree of tickets is so bad for project planning I recommend using the backlog as a diplomatic tool and a polite way of letting things get lost. It is is better to use advanced scheduling tools, like a spiral-bound notebook or sticky notes, rather than a backlog. The backlog is for management and politics.
- idopmstuff 3y ago
  > I recommend using the backlog as a diplomatic tool and a polite way of letting things get lost. I hate this approach. I totally get it, to be clear. I've done it. But I hate it. It's a sign of a really bad culture if you have to placate people in this way. If your senior leadership is clearly communicating priorities, you should be able to say, "Look, this is an interesting idea, but as you know this quarter we're very focused on X, and this just doesn't align with that. The best route to get this done is to give your feedback in the next planning process and see if you can push Y to be a priority, then we can definitely talk about getting this on the roadmap." A huge part of the job of a PM is to say no. If people aren't able to take a no on feature requests, there's a problem somewhere. Maybe it's with the way you're delivering it, maybe it's with the overall culture or maybe it's with the person making the request. Whatever the issue is, though, it's better to deal with it and create an environment where people understand that sometimes their requests will get declined for valid reasons.
  - danielmarkbruce 3y ago
    So nothing goes in the backlog? How do you keep track of ideas that might make sense but aren't high priority right now? If you have an idea to do X, and then over 2 years you find lots of customers asking for it and it's a few weeks work, how does that get captured somewhere?
IanCal 3y ago
> and store other ideas elsewhere. 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.
- idopmstuff 3y ago
  > 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.
  - peebeebee 3y ago
    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.
    - idopmstuff 3y ago
      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).
doix 3y ago
I totally agree. The worst thing is going directly from feedback -> ticket. Not only because of what you describe, but also because you end up with a product that is just a list of features without a coherent "idea". Especially when you've got eager developers that will see some slack in the schedule and just pick up a random ticket because it's "easy". Usually when customers give feedback it's to address an immediate need they have, so they'll suggest adding a button/option/toggle/whatever. And that's fine, but if you do that for every piece of feedback, you'll end up with an unusable mess. Especially because it's usually very easy to add that one extra button/option/toggle. You usually require someone to go through all the feedback and try to address the root cause of what they're asking for. Sometimes the extra option is unavoidable, sometimes it leads to redesigning some system to be more generic to support what the customer wants + more. I do think the feedback needs to be linked to the work somehow, not hidden away in a separate PM tool or whatever. Ideally retaining the raw feedback, because sometimes when summarizing it, things get lost.
- 9dev 3y ago
  Feedback is a good use case for custom issue types, though. We create feedback issues that are not actionable of themselves, but can be linked to tickets, so engineers get a feeling of what customers think.
  - halgir 3y ago
    Where do you keep those to avoid cluttering the "real" backlog? Separate Jira (if applicable) project?
    - stag91 3y ago
      Tossing https://www.getcustomeriq.com/ https://www.getcustomeriq.com/ in the mix - pretty much dedicated to this
    - cocoflunchy 3y ago
      There are products for those like https://www.productboard.com/ https://www.productboard.com/ or https://harvestr.io/ https://harvestr.io/
atoav 3y ago
The way you need to model it is to mentally add friction/cost for retrieving tickets after some time. Doing things right now, without making them tickets is often easier, because the problems context is still fresh, both to you and your customer. So potentially needed clarifications are easier to get while things are fresh than if you made them a few weeks down the line. This is especially true if the customer asks about minor things and these are a blocker or a huge annoyance to them. Fixing them right away will make you shine more than just putting it on a stash. But if you find yourself constantly fixing things that were specified and should actually work you got a problam with code quality. And if you constantly have to add small new things there is a problem with your customers clarity and a bigger meeting might be in order.
kqr 3y ago
This is what David Marquet suggests too: the team backlog should contain whatever's going to happen in the next short iteration. The rest is dropped. If someone wants to save an idea for a later iteration, they can do that however they want, but they don't get to clutter the team backlog with it. It also mirrors my best experiences with well-managed backlogs.
hurril 3y ago
You and I seem to completely agree on this. I really dislike a backlog of bad conscious with things we "mustn't forget". My reasoning is more (akin to yours): if it's a necessary and actually requested or useful feature, then we'll rediscover it. (This doesn't apply to bugs!)
- MrGilbert 3y ago
  I really like that. It also helps reassuring the importance of items. Like, if you want to create the same story three times in a year, it might actually be important.
  - bertil 3y ago
    Wouldn’t a curated version of the icebox help notice that pattern early? Especially if the team changes quite fast.
    - hurril 3y ago
      It's that for a team of a given size, we can only collectively produce so much. So as long as we're always picking tickets of a priority that stakeholders and we deem of the highest priority, then we're doing the right things. This necessarily means that the backlog probably grows.
RHSman2 3y ago
To use an analogy of back pain and a massage. You may get relief but you run up a cost and with no real solution to the problem.
frereubu 3y ago
This is perhaps implicit in your comment, but "no" is also an acceptable answer if you explain why. We have a product that we have a relatively clear idea about, where we spend a lot of time making sure we're keeping things simple and focused. I reckon we say "no" to at least one third of ideas and "not for quite a while" for at least another third, explaining why each time in terms of our roadmap for the product. We'd found that customers tend to respond quite well, and for those where it's a deal breaker, they're probably better served by a different product anyway.
- Lutger 3y ago
  > ...they're probably better served by a different product anyway. And you are doing both them and yourself a favor by making this clear. You might lose a couple of customers. But you would have lost them anyway and unhappy customers can also be annoying for everybody and slow you down, give you less than favorable reviews, etc.
- bertil 3y ago
  The problem is that not saying no, dismissing it without details, or ignoring it in an icebox removes a key feature and the way we should organize that idea: why not. Suppose the idea is likely impactful but complicated to implement. In that case, you might want to think about putting those ideas together to argue for refactoring that would enable more impactful ideas. If the idea would change the kind of service being offered, then it should inform strategic product thinking. If the idea is relevant but unlikely to have an impact because it's too low level and about code quality, maybe you want to think of automating or including it in the linting process. I think the problem here is that the tool, Jira tickets, isn’t suited for the use that you make of it: communicating with clients and defining product strategy. The problem is that there isn’t a good tool for that.
Perepiska 3y ago
I've seen this approach in 100- startup and 10K+ enterprise: managers collect and store ideas in their private places. This quickly turns into job security and spoils the work process.
kevincox 3y ago
I get where you are coming at and find some value in it but I do often like to create these "maybe someday" tickets for a few reasons. - It provides an obvious place to put some ideas about then that can be collected over time. Often thoughts from significantly different points in time can provide valuable perspective. Even if most of the time they are just out of date. - It allows tracking value over time. For example adding a quick note that this would have been helpful to customer 123. If you only file tickets when you are ready to implement them it is easy to miss the common friction problems. So basically it is a way to log interest over time. But they are also easy to filter out so low cost to keep them around. But I'm sure that you could also manage these "feature requests" in a separate system. But that often adds friction.
anonyfox 3y ago
we use Atlassian. My engineering team works on a Jira Kanban that only contains tickets that are soon to be worked on (read: within the next days, tops), there is no backlog at all, and engineers are encouraged to put technical findings there and pull them if the team considers it important enough to act on it. In addition, our product team works with the "Product Discovery" tool from atlassian, where they collect Ideas/Features/..., determines the RICE score for each, and does the back-and-forth with people, until they are reasonably sure what to put into the engineering kanban next, always having the "WIP limit" in mind. Therefore the giant "icebox" is out-of-sight but the social factor of "there is a ticket for my idea" across the company is also fulfilled. works pretty well so far!
- skydhash 3y ago
  Nice! Having the same ticket going for months because it's always low priority, but always coming back during grooming is not a good feeling. I don't mind having a huge list of tasks, but only if I know they're going to be done eventually.
- MetaWhirledPeas 3y ago
  This is the answer. You can solve this problem with tools; you don't have to change your philosophy. When your company has 5 projects, do you count Project Z's backlog against Project X's backlog? No you don't, even though they are both in the same database. The reason you're OK with this is because your teams' views have been adjusted so that they only see their own project. So they each see what they consider to be their own backlog. Use the same approach for low-priority requests: put them in the same database, but don't elevate them to the team's backlog view. If someone has an idea or a request you should not suppress it entirely. That will only encourage people to add yet another system of logging to your organization. Just because a request is not urgent or can't be put on the roadmap yet does not mean it's not important. And why throw away what can be logged for later archeology? "Oh hey the answer to this new problem is right here in this old request we never got around to."
mooreds 3y ago
We have a lot of issues (nearing 1000) in a public repo[0] that anyone can view and vote on. This gives us a natural filtering mechanism for community input. We regularly sort this by number of upvotes. It also lets our users submit some off the wall ideas, and gives a way for low friction community feedback to be captured. Finally, it lets community members easily be notified when a feature is delivered by subscribing to the issue. We also have a separate, private list of commits to customers. (The commit is public and is added to a milestone, but the customer is private.) We also group issues by theme[1]. It's not perfect but it's an attempt to make sure we don't run into the duplicates issue you mention. It allows the eng team to address multiple issues in the same area of the code at once. I understand what you are saying about clutter, but the low cost public feedback and tight loop between issue and code is worth some issue creep, IMO. 0: https://github.com/FusionAuth/fusionauth-issues/issues https://github.com/FusionAuth/fusionauth-issues/issues 1: https://github.com/FusionAuth/fusionauth-issues/issues?q=is%3Aissue+is%3Aopen+category+ https://github.com/FusionAuth/fusionauth-issues/issues?q=is%...
- idopmstuff 3y ago
  I see your product is for devs, so totally get this. I work in enterprise software and can't imagine this would work well.
  - mooreds 3y ago
    That makes sense. I think you should tune your product management strategy for your audience. Still think there's value in having an open roadmap and feature list that customers and users can submit too, regardless of industry. I wouldn't recommend you use GitHub, though :).
  - goodlinks 3y ago
    Vote = vote * employee.grade (/S this isnt actually a good idea but may be practical depending on the org)
    - SkyBelow 3y ago
sparrowInHand 3y ago
I actually like it. Unfinnished Ideas are .. the waves the buisness problems make when bumping into the software. These ideas are usually collection points for notes on how something is impossible (due to reality, buisness or architecture) or otherwise constrained. They are not actual features, they are a information collection on how a idea might be not possible or a placeholder for a better solution not yet in the making. Not all tickets have to become a feature in software- some can become wikipedia pages on requirements/conditions of the project.
bcoughlan 3y ago
On the flip side, putting a ticket on the backlog knowing it will never be high enough priority to be done is an effective way to manage people's feelings without outright nopeing their idea.
- rogerkirkness 3y ago
  The best products tend to have PMs willing to say No the most, though.
nradov 3y ago
If Product Managers or Product Owners are creating new duplicate tickets instead of searching and updating existing tickets then they're simply not doing their job. Keeping the backlog groomed and being familiar with its contents is a core job responsibility. No process change can overcome that level of laziness and incompetence.
rbetts 3y ago
This proposal moves the list to other systems. I dislike unbounded backlogs too - but a single searchable database is better, IMO. (Though Github issues et. al. have such bespoke, bad, limited, bad, half-baked, bad search.. Gah.)
User23 3y ago
> I hate the strategy of just taking every idea you hear and throwing it into a ticket. You just end up with this giant icebox of stuff you'll never do. If a big new prospect demands one of the ideas that's in the icebox be implemented immediately in order to close a deal, you're probably still not going to pull it out of the icebox, because you don't remember that it's there. Instead, you'll just create a new ticket for it, and eventually when going through the icebox, someone will go "hey, I think we built this already" and close as dupe. This was part of the wisdom of the ancient agile way: a box of index cards for your backlog. The physicality of it gave clear indication when it was getting silly. Furthermore, regular backlog pruning was a necessary activity because the box would get full!

stag91 3y ago

Totally agree re: everything's a ticket. I consider the backlog to be only prioritized work - things we determined need to happen they're just not happening right now. Features we've agreed on, tech debt, etc. I do think it's important to organize all feature requests, pain points, feedback etc. though but it needs to be separate of delivery management and it should be thematic (assuming there's a lot of feedback). That's the point of CustomerIQ (I'm a founder), to give that a home but also quantify themes over time. These would inform the backlog/possible make it in, but keeps delivery tools cleans.

alexanderchr 3y ago

Very similar to what's recommended in Basecamp's Shapeup book: https://basecamp.com/shapeup/2.1-chapter-07 https://basecamp.com/shapeup/2.1-chapter-07

hakunin 3y ago

Agree with all of this, and recommend this process for engineering tech debt: https://max.engineer/long-term-refactors https://max.engineer/long-term-refactors In short: maintain a list of long term refactors that everyone's gradually working on, without necessarily showing it in the ticket tracking system.

roenxi 3y ago

Although the approach seems fine, I don't think it creates an advantage. The situation is there are tickets in progress that have engineering consequences and then there is the backlog. How the backlog then gets used is 100% a question of convenience and any approach that works for the decision makers is fine. If they want to use the backlog as a way to plan upcoming work (as you seem to do) that is fine. If they want to use the backlog as a diplomatic tool to say no gently, also cool. JIRA + a tree of tickets is so bad for project planning I recommend using the backlog as a diplomatic tool and a polite way of letting things get lost. It is is better to use advanced scheduling tools, like a spiral-bound notebook or sticky notes, rather than a backlog. The backlog is for management and politics.

idopmstuff 3y ago
> I recommend using the backlog as a diplomatic tool and a polite way of letting things get lost. I hate this approach. I totally get it, to be clear. I've done it. But I hate it. It's a sign of a really bad culture if you have to placate people in this way. If your senior leadership is clearly communicating priorities, you should be able to say, "Look, this is an interesting idea, but as you know this quarter we're very focused on X, and this just doesn't align with that. The best route to get this done is to give your feedback in the next planning process and see if you can push Y to be a priority, then we can definitely talk about getting this on the roadmap." A huge part of the job of a PM is to say no. If people aren't able to take a no on feature requests, there's a problem somewhere. Maybe it's with the way you're delivering it, maybe it's with the overall culture or maybe it's with the person making the request. Whatever the issue is, though, it's better to deal with it and create an environment where people understand that sometimes their requests will get declined for valid reasons.
- danielmarkbruce 3y ago
  So nothing goes in the backlog? How do you keep track of ideas that might make sense but aren't high priority right now? If you have an idea to do X, and then over 2 years you find lots of customers asking for it and it's a few weeks work, how does that get captured somewhere?

IanCal 3y ago

> and store other ideas elsewhere. 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.

idopmstuff 3y ago
> 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.
- peebeebee 3y ago
  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.
  - idopmstuff 3y ago
    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).

doix 3y ago

I totally agree. The worst thing is going directly from feedback -> ticket. Not only because of what you describe, but also because you end up with a product that is just a list of features without a coherent "idea". Especially when you've got eager developers that will see some slack in the schedule and just pick up a random ticket because it's "easy". Usually when customers give feedback it's to address an immediate need they have, so they'll suggest adding a button/option/toggle/whatever. And that's fine, but if you do that for every piece of feedback, you'll end up with an unusable mess. Especially because it's usually very easy to add that one extra button/option/toggle. You usually require someone to go through all the feedback and try to address the root cause of what they're asking for. Sometimes the extra option is unavoidable, sometimes it leads to redesigning some system to be more generic to support what the customer wants + more. I do think the feedback needs to be linked to the work somehow, not hidden away in a separate PM tool or whatever. Ideally retaining the raw feedback, because sometimes when summarizing it, things get lost.

9dev 3y ago
Feedback is a good use case for custom issue types, though. We create feedback issues that are not actionable of themselves, but can be linked to tickets, so engineers get a feeling of what customers think.
- halgir 3y ago
  Where do you keep those to avoid cluttering the "real" backlog? Separate Jira (if applicable) project?
  - stag91 3y ago
    Tossing https://www.getcustomeriq.com/ https://www.getcustomeriq.com/ in the mix - pretty much dedicated to this
  - cocoflunchy 3y ago
    There are products for those like https://www.productboard.com/ https://www.productboard.com/ or https://harvestr.io/ https://harvestr.io/

atoav 3y ago

The way you need to model it is to mentally add friction/cost for retrieving tickets after some time. Doing things right now, without making them tickets is often easier, because the problems context is still fresh, both to you and your customer. So potentially needed clarifications are easier to get while things are fresh than if you made them a few weeks down the line. This is especially true if the customer asks about minor things and these are a blocker or a huge annoyance to them. Fixing them right away will make you shine more than just putting it on a stash. But if you find yourself constantly fixing things that were specified and should actually work you got a problam with code quality. And if you constantly have to add small new things there is a problem with your customers clarity and a bigger meeting might be in order.

kqr 3y ago

This is what David Marquet suggests too: the team backlog should contain whatever's going to happen in the next short iteration. The rest is dropped. If someone wants to save an idea for a later iteration, they can do that however they want, but they don't get to clutter the team backlog with it. It also mirrors my best experiences with well-managed backlogs.

hurril 3y ago

You and I seem to completely agree on this. I really dislike a backlog of bad conscious with things we "mustn't forget". My reasoning is more (akin to yours): if it's a necessary and actually requested or useful feature, then we'll rediscover it. (This doesn't apply to bugs!)

MrGilbert 3y ago
I really like that. It also helps reassuring the importance of items. Like, if you want to create the same story three times in a year, it might actually be important.
- bertil 3y ago
  Wouldn’t a curated version of the icebox help notice that pattern early? Especially if the team changes quite fast.
  - hurril 3y ago
    It's that for a team of a given size, we can only collectively produce so much. So as long as we're always picking tickets of a priority that stakeholders and we deem of the highest priority, then we're doing the right things. This necessarily means that the backlog probably grows.

RHSman2 3y ago

To use an analogy of back pain and a massage. You may get relief but you run up a cost and with no real solution to the problem.

frereubu 3y ago

This is perhaps implicit in your comment, but "no" is also an acceptable answer if you explain why. We have a product that we have a relatively clear idea about, where we spend a lot of time making sure we're keeping things simple and focused. I reckon we say "no" to at least one third of ideas and "not for quite a while" for at least another third, explaining why each time in terms of our roadmap for the product. We'd found that customers tend to respond quite well, and for those where it's a deal breaker, they're probably better served by a different product anyway.

Lutger 3y ago
> ...they're probably better served by a different product anyway. And you are doing both them and yourself a favor by making this clear. You might lose a couple of customers. But you would have lost them anyway and unhappy customers can also be annoying for everybody and slow you down, give you less than favorable reviews, etc.
bertil 3y ago
The problem is that not saying no, dismissing it without details, or ignoring it in an icebox removes a key feature and the way we should organize that idea: why not. Suppose the idea is likely impactful but complicated to implement. In that case, you might want to think about putting those ideas together to argue for refactoring that would enable more impactful ideas. If the idea would change the kind of service being offered, then it should inform strategic product thinking. If the idea is relevant but unlikely to have an impact because it's too low level and about code quality, maybe you want to think of automating or including it in the linting process. I think the problem here is that the tool, Jira tickets, isn’t suited for the use that you make of it: communicating with clients and defining product strategy. The problem is that there isn’t a good tool for that.

Perepiska 3y ago

I've seen this approach in 100- startup and 10K+ enterprise: managers collect and store ideas in their private places. This quickly turns into job security and spoils the work process.

kevincox 3y ago

I get where you are coming at and find some value in it but I do often like to create these "maybe someday" tickets for a few reasons. - It provides an obvious place to put some ideas about then that can be collected over time. Often thoughts from significantly different points in time can provide valuable perspective. Even if most of the time they are just out of date. - It allows tracking value over time. For example adding a quick note that this would have been helpful to customer 123. If you only file tickets when you are ready to implement them it is easy to miss the common friction problems. So basically it is a way to log interest over time. But they are also easy to filter out so low cost to keep them around. But I'm sure that you could also manage these "feature requests" in a separate system. But that often adds friction.

anonyfox 3y ago

we use Atlassian. My engineering team works on a Jira Kanban that only contains tickets that are soon to be worked on (read: within the next days, tops), there is no backlog at all, and engineers are encouraged to put technical findings there and pull them if the team considers it important enough to act on it. In addition, our product team works with the "Product Discovery" tool from atlassian, where they collect Ideas/Features/..., determines the RICE score for each, and does the back-and-forth with people, until they are reasonably sure what to put into the engineering kanban next, always having the "WIP limit" in mind. Therefore the giant "icebox" is out-of-sight but the social factor of "there is a ticket for my idea" across the company is also fulfilled. works pretty well so far!

skydhash 3y ago
Nice! Having the same ticket going for months because it's always low priority, but always coming back during grooming is not a good feeling. I don't mind having a huge list of tasks, but only if I know they're going to be done eventually.
MetaWhirledPeas 3y ago
This is the answer. You can solve this problem with tools; you don't have to change your philosophy. When your company has 5 projects, do you count Project Z's backlog against Project X's backlog? No you don't, even though they are both in the same database. The reason you're OK with this is because your teams' views have been adjusted so that they only see their own project. So they each see what they consider to be their own backlog. Use the same approach for low-priority requests: put them in the same database, but don't elevate them to the team's backlog view. If someone has an idea or a request you should not suppress it entirely. That will only encourage people to add yet another system of logging to your organization. Just because a request is not urgent or can't be put on the roadmap yet does not mean it's not important. And why throw away what can be logged for later archeology? "Oh hey the answer to this new problem is right here in this old request we never got around to."

mooreds 3y ago

We have a lot of issues (nearing 1000) in a public repo[0] that anyone can view and vote on. This gives us a natural filtering mechanism for community input. We regularly sort this by number of upvotes. It also lets our users submit some off the wall ideas, and gives a way for low friction community feedback to be captured. Finally, it lets community members easily be notified when a feature is delivered by subscribing to the issue. We also have a separate, private list of commits to customers. (The commit is public and is added to a milestone, but the customer is private.) We also group issues by theme[1]. It's not perfect but it's an attempt to make sure we don't run into the duplicates issue you mention. It allows the eng team to address multiple issues in the same area of the code at once. I understand what you are saying about clutter, but the low cost public feedback and tight loop between issue and code is worth some issue creep, IMO. 0: https://github.com/FusionAuth/fusionauth-issues/issues https://github.com/FusionAuth/fusionauth-issues/issues 1: https://github.com/FusionAuth/fusionauth-issues/issues?q=is%3Aissue+is%3Aopen+category+ https://github.com/FusionAuth/fusionauth-issues/issues?q=is%...

idopmstuff 3y ago
I see your product is for devs, so totally get this. I work in enterprise software and can't imagine this would work well.
- mooreds 3y ago
  That makes sense. I think you should tune your product management strategy for your audience. Still think there's value in having an open roadmap and feature list that customers and users can submit too, regardless of industry. I wouldn't recommend you use GitHub, though :).
- goodlinks 3y ago
  Vote = vote * employee.grade (/S this isnt actually a good idea but may be practical depending on the org)
  - SkyBelow 3y ago

sparrowInHand 3y ago

I actually like it. Unfinnished Ideas are .. the waves the buisness problems make when bumping into the software. These ideas are usually collection points for notes on how something is impossible (due to reality, buisness or architecture) or otherwise constrained. They are not actual features, they are a information collection on how a idea might be not possible or a placeholder for a better solution not yet in the making. Not all tickets have to become a feature in software- some can become wikipedia pages on requirements/conditions of the project.

bcoughlan 3y ago

On the flip side, putting a ticket on the backlog knowing it will never be high enough priority to be done is an effective way to manage people's feelings without outright nopeing their idea.

rogerkirkness 3y ago
The best products tend to have PMs willing to say No the most, though.

nradov 3y ago

If Product Managers or Product Owners are creating new duplicate tickets instead of searching and updating existing tickets then they're simply not doing their job. Keeping the backlog groomed and being familiar with its contents is a core job responsibility. No process change can overcome that level of laziness and incompetence.

rbetts 3y ago

This proposal moves the list to other systems. I dislike unbounded backlogs too - but a single searchable database is better, IMO. (Though Github issues et. al. have such bespoke, bad, limited, bad, half-baked, bad search.. Gah.)

User23 3y ago

> I hate the strategy of just taking every idea you hear and throwing it into a ticket. You just end up with this giant icebox of stuff you'll never do. If a big new prospect demands one of the ideas that's in the icebox be implemented immediately in order to close a deal, you're probably still not going to pull it out of the icebox, because you don't remember that it's there. Instead, you'll just create a new ticket for it, and eventually when going through the icebox, someone will go "hey, I think we built this already" and close as dupe. This was part of the wisdom of the ancient agile way: a box of index cards for your backlog. The physicality of it gave clear indication when it was getting silly. Furthermore, regular backlog pruning was a necessary activity because the box would get full!