Do you always have 6 months of backlog to work from?

Do you always have 6 months of backlog to work from? If you don’t, what are some of the things preventing you from having that?

9 Likes

I don’t think any agile shop should have 6 months of backlog. Anything farther than 3 months out is ripe to be displaced by higher priorities as you hopefully learn more about what you’re releasing. The company might have a roadmap of priorities and maybe the product team has initiates/projects they are researching as part of that, but actually grooming or creating tickets for the backlog that far out is throwaway work imo.

8 Likes

For me it’s six weeks max in what people typically think of as a backlog. Roadmap/strategy/vision beyond that.

7 Likes

Yeah same for me, I’d like to know what the hell kind of places people are working at where they have a 6 month backlog.

6 Likes

I’ve got a long range set of epics in my head that should span 12-18 months, but there’s zero chance I’m going to keep a refined backlog more than 2-3 full sprints into the future. Our environment and customer needs are too dynamic for that to be useful.

5 Likes

Exactly. Six months of a backlog sounds to me like a problem. Especially if refined. Max 3 sprints currently. Between measuring and adjusting there is NO WAY value added can be done with a 6 months backlog.

But long term vision definitely can go past 6 months.

4 Likes

Your backlog sounds like that of a feature factory. You identify a need, you make stuff you release, measure and iterate. What on earth are you making that has six months of a backlog?

Are you talking about a roadmap?

4 Likes

We never have 6 months of backlog. It’s closer to 2-3 months, at most, and even then month 3 is generally pretty tentative. This is done purposefully, since we need to be able to pivot to address new business opportunities and sinking the time into defining anything past 2-3 months is asking for trouble.

2 Likes

No way in hell. Our project management team asks that we have around 3 months of backlog and even that I find too much.

Generally I have around 3-4 sprints (2 months) of fairly detailed Jira tickets/work linked to wikis and with Figma designs. Beyond that it’s more placeholder Jira tickets / planned work that we still need to flesh out a bit.

1 Like

I keep both 18-24 months runway of features, plus tons of smaller items, so i can always feed the pipeline for engineering when they need something / feel bored.

you can prevent that list from drying up by constantly conducting feature requests sessions with customers, pot and current, and also by doing a lot of CI and market analysis.

1 Like

24 months of features? lol how? I imagine none of that has detailed requirements, UX, etc.?

1 Like

@Yuri, The key is to maintain them in a “detail enough” state - Enough to evaluate, justify and align with the long term strategy, but not get too deep into the details before closer to implementation.

Remember, you want to be able to keep a discussion going, your job is to manage a product life cycle, not just “create work” for the developers.