Quarterly Delivery Planning
The roadmap is full of dates with unknown origins. Engineering is complaining about shifting priorities. PMs are surprised by and complaining about dependencies. PMs are barely keeping up with sprint planning and not providing their teams with a mid- or long-term view.
You already know a version of this play already by another name - release planning, big-room planning, PI planning, quarter planning, and others. In this issue I want to talk about how this is useful for those leading product, regardless of your methodology, and how I approach it from the product side (vs, say, from the CTO side).
The photo shows my first experience with multi-team mid-range planning back in 2006. Jean Tabaka was lead facilitator, and Dean Leffingwell was in the room as an observer. He would later popularize the activity as a core part of his Scaled Agile Framework.
But you don't have to adopt any particular framework to benefit from this play.
Context
Use this play when the roadmap is full of dates with unknown origins. Engineering is complaining about shifting priorities. PMs are surprised by and complaining about dependencies. PMs are barely keeping up with sprint planning and not providing their teams with a mid- or long-term view.
When we are planning continuously, ad-hoc, there is simultaneously a lot of pressure (because everyone is nervous and lacks confidence) and no pressure (because everything can always be dragged out a little longer). Most companies keep people busy with a large amount of work in process, and deliver very slowly.