Software teams have limited resources. That means that, by definition, we can't build everything we would like to build. That's just a fact of life.
We need to focus the resources we have on the outcomes that matter the most. These trade-offs are necessary but often happen implicitly. That's a big source of frustration.
It starts with someone making a small request. Let's say a designer notices inconsistencies in buttons. Some are bigger than others, and the colors are slightly off. She'd like to create a reusable button component to solve these inconsistencies for good.
From a design perspective, this is a good upgrade of the system. But from a strategic point-of-view, it adds little value. No customer ever complained about the buttons. We never lost sales because of them. Customers complain about many things, but styling isn't one of them.
It's not worth focusing our limited resources on. That's a harsh truth. That doesn't mean design isn't important. It means other things are more important right now.
So, what typically happens is that the designer gets to create a ticket and throw it in a team's backlog. It won't be the top priority, but the team will solve this issue if they ever get around to it.
They never get around to it.
That shouldn't surprise us because we can't build everything we want. Limited resources, remember?
The ticket drowns indefinitely in the ever-growing backlog.
The designer rightfully starts to feel neglected. "This company doesn't care for my input! My ticket never gets taken up."
The team gets frustrated too. "People keep throwing miscellaneous stuff in our backlog. We can't double down on what matters."
The root cause is, of course, the double use of a backlog. For developers, it's their team's to-do list. For the rest of the organization, it's a wish list. That creates conflict.
We want our teams to focus on what matters without feeling they should also be thinking about hundreds of other unrelated topics. At the start of a Focus Block, the backlog should be (as good as) empty. That's the only way to focus.
On the other side, it starts to feel like throwing requests into the void. "I put that improvement on the list over a year ago, and they're still not building it!"
Some pundits claim backlogs are lists of things we can build, but that's not how they are perceived in real life. Backlogs, for all intents and purposes, are considered ticketing systems by most people in the organization. We add a request, get a ticket number, and can follow its progress and state. From the requester's perspective, a ticket comes with the implicit expectation that it will get handled.
That's the dynamic we need to break.
Let's keep the backlog as the team's to-do list. It contains tickets for the solution they are currently focusing on. It also contains the bugs and customer support items that must be handled ASAP. Everything that won't be done in the coming weeks has no place in the backlog.
Those items should get moved to an idea incubator. The idea incubator is a set of articles describing the problems that might appear on the team's radar later. It's typically managed in Confluence or Notion, not Jira.
Instead of thinking in tickets (and thus development tasks), the incubator makes us think in problems. The designer, for example, can write her vision of reusable components in an article that describes the problem it addresses. If the design ever becomes a focal point, a well-thought-out problem description is already available.
The idea incubator allows us to gather our thoughts about problems that we will not be working on right now. That's vital. It allows us to flesh out these ideas that we might or might not implement.
A set of articles and problem descriptions doesn't feel like a request. A problem description is not a ticket. There is no implicit expectation. It's not on the list.
By separating the work-we-will-definitely-do from the work-we-might-do-one-day, we align expectations. What's on the backlog will get built. What’s in the incubator is just an idea.
This system allows us to focus on what matters today while still thinking ahead.
A curious point of view is that we are talking about emotions felt by a person when looks to the backlog and creates some expectation and how this feeling can be quite different when the person looks to the idea incubator knowing that it is a process of recnognizing relevant (or not), of new features for the product.
I really like JIRA's new product features and hope more people use it and push "ideas" into it or tools like it.