Roadmaps + Backlogs: Planning for the unknown

A backlog split into four time buckets—later, soon, next, now—works like a product roadmap and gives teams clearer visibility. Assign each future item a specific horizon like Q1 or Q2, then pull into sprints based on capacity rather than vague floating ideas.
Chapters
Okay, so I found this, this image which I thought was pretty interesting. I'd like to discuss a little bit, or at least think about a little more. But it basically had two different sections of stickies, which are supposed to represent activities or work or user stories or features or things to work on. And it was broken down into backlog and sprint, which is pretty normal, right? What are things you have in your to-do list that you can pull in? And what are you working on right now. And inside the backlog, it was later, soon, next, and now. So obviously now is what are you working on within this sprint, which is— they have a breakdown on that side, which I thought was interesting because, I mean, it's, it's to-do, doing, done. So what have you started, what's in progress— for me, I have to-do, in progress, and and finished. And that's how you know the progress of certain activities within the sprint. So I'm already managing that that way. But what I did think was interesting was how they were managing their backlog into a later, soon, next, and now. So that to me translated to your roadmap, right? What in the future do we have and what do we have, what are we working on right now? But I liked how it had later, soon, next. So your roadmap usually can span for a year, 2 years, 3 years, who knows how long. But it gets a little like stuff gets lost somewhere in the backlog when it doesn't necessarily have a location. It kind of ends up floating in limbo to be scheduled. But I like the idea of instead of just having something floating in limbo, like, oh, we have to schedule it, we have to get to it, putting it somewhere and maybe even refining the later, soon, next, and now into, uh, maybe Q1, Q2, Q3, this year, next year, to be organized, something where it's a little more specific. And that way you can say around this time, you know, we actually had scheduled in 2024 to do this, in 2025 we had scheduled this, and now we can start pulling them in from the backlog sooner than later and not kind of looking at the backlog and saying, hey, we have some space, What can we pull in? But even pulling things in based on sizing and things like that. So it's just a little something I like to talk about in terms of project management and figuring out how to better organize future work and the roadmap, which a lot of times I've seen is a problem because there's never a good enough transparency or planning further enough in the future. You kind of get to a point and say, what are we doing right now? You know, but ideally you want to have a future plan, things to pull in. If you get done sooner, you can pull it in. If it takes later, you can push stuff out. But being agile and able to manage your work is the ideal situation.
More from Ritzie

I started my career doing lots of graphic design and having to create and edit images.

How to Upload a Project to GitHub (Using Claude + Cursor) | Step-by-Step Tutorial








