Product backlogs are a weird bunch. They contain everything from high-level dreams to year-old ideas over technical tasks and bugs. They carry the stakeholders' expectations and developers' ambitions while also being the team's to-do list. It's a mixed bag.
As I've discussed before, backlogs aren't purely rational. When someone adds an idea to the backlog, they are not just adding a potential feature. They are emotionally invested in their idea.
That's why deleting Jira tickets is so hard: somebody cares about them.
Such a mixed, emotionally-charged bag has painful side effects. The value of a backlog item depends on the target audience. That last push to switch the entire front end to functional React components is meaningless to a Product Owner. That export-to-Excel functionality is "an extra" to developers but might be crucial for the Customer Support people. If you have a team where Design and QA also log tickets in the backlog, it's getting even wilder. In a lot of teams, there are tickets that only one person cares about. Good luck prioritizing those!
When I talk about the ideal plan, I often bring up Focus Blocks. Instead of trying to cram a bunch of Jira tickets in a timebox, we ask the question: "What is the best solution to the problem we can build in 2 weeks?". This is a powerful approach. At the start of the Focus Block, we create the tickets for that timebox. All tickets that aren't finished at the end of the timebox get deleted. That ensures that the backlog only contains bugs, operational work, and the solution we're currently working on.
It's a reliable and rational system. Yet, I often notice the same reluctance to delete tickets. While it's easy to say that we'll throw away all unfinished tickets at the end of the timebox, it's harder to do. Developers, like all other humans, have a hard time killing their darlings. "Sure, we didn't have time to add the e-mail notifications, but it would be a really cool feature. Can't we keep the ticket and plan it some other day?"
I've been experimenting with a new kind of flow that doesn't rely on backlog items. While it's not 100% tried and tested yet, I wanted to share this approach with you.
In my "anatomy of an ideal plan", I propose to keep ideas in an Idea Incubator. I'm convinced problem-solving requires prose rather than a ticketing system. That's why the incubator is a wiki-style platform like Notion or Confluence. It's the place where we can develop our understanding of the problem and collaborate to design solutions. At the start of each Focus Block, the team looks at the article in the Idea Incubator and comes up with solutions that alleviate the pain.
Instead of adding tickets for each solution to the backlog, I've been experimenting with keeping this list of solutions as a table on the relevant Notion page. This has a few benefits.
The page in the Idea Incubator becomes a living document that contains the problem description, the solution conversation, and the status tracker. It's one location with all the relevant information for this Focus Block.
The backlog becomes the territory of bugs, customer support requests, and technical issues. All of these are better suited for a ticket-style approach.
During a Focus Block, developers don't have to look at the backlog. They open the Notion page and can't be distracted by operational work. It's as focused as one can get. Conversely, developers only look at the backlog during a Recovery Block and ignore the Idea Incubator. It creates a natural ebb-and-flow system.
When the timebox expires, and we still have some great ideas to address the problem, these can remain as unfinished solutions on the incubator page. If we decide to dedicate more time to the same problem later down the line, those ideas will be waiting in the right place.
Splitting the tracking systems for feature work and operational work feels like a good approach. Not only does it help the team focus, but it relieves them of the responsibility to kill their darlings. It results in a clean backlog and a dedicated spot for each lifecycle step from idea to delivery.
Living documents for features, tickets for bugs.
That feels like a clean design.
I jumped on this super fast! Dead documents and full backlogs are the bane of every team I work on and with.