Let me summarize what I've been talking about in these posts. The problem I'm seeing is that too many teams and organizations plan too much in too much detail too soon. Instead of architectural BDUF (Big Design Up Front), it's project planning as BDUF. They expect one single person (a product manager or a product owner) to do all that planning. That's a legacy of Waterfall thinking.

If you want to take advantage of agile approaches for maximum innovation and speed, consider these ideas:

Consider using the term, feature sets, related features that produce value, instead of epics or themes. That will help other people realize the largeness of what you are discussing. When they think about the largeness, they might see more options for MVPs, MVEs, and releasing, especially for small and early value.

The more you want to incorporate feedback into your planning (either the small planning or the larger planning), the more you can consider rolling wave planning, especially if you are trying to plan for a quarter at a time. To be honest, if you are using agile approaches to manage change to the product and to incorporate feedback, I'm not sure how you can plan for a quarter. Roadmap? Absolutely. Plan? Not so much. (I have a slideshare called Think Big, Plan Small: How to Use Continual Planning.)

I suggested that if you need more change than a time-based roadmap might provide you, consider a scope-based roadmap, using principles of flow.

I wrote about the problems I've seen with big planning and the fact that the larger the effort, the more teams need resilience and feedback in their planning.

Then I said the PO can't do all the roadmap and backlog planning/refinement alone. I suggested you consider the Product Value Team. The Product Value Team has the customer and internal contacts to gather the knowledge, distill it, and plan and replan at a reasonable (for you) cadence.

I had some suggestions for what to do when managers want commitments. Remember that if you work in rank order and release often, you might deliver what they need, not necessarily what they know they want now. That goes to the evolving nature of the actual product in development.

I've been grappling with the whole "scaling agile" idea. I wrote a scaling series about it earlier this year. This roadmap series is about scaling the product development capabilities.

You might not like these ideas. I'm not offended. Here are the questions I suggest you answer:

• What would have to be true for you to be able to create useful plans?
• What assurances can you provide your managers?
• How can you deliver small value every day and maintain a sustainable pace?

Agile approaches change our entire notion of planning in the large and small. They change what we can deliver because we can deliver much more than we might have thought we could. The difference is we deliver small chunks of value all the time.