Meeting structure

To make sure the most important changes are made regularly and with the right set of participants, there are several meetings. All these meetings refer to the steps in the framework outlined above. Of course the initial creation of the artifacts, like vision, user journey takes more time and has to take place in a workshop-like format. After the initial version is available, the following meeting structure should be followed to ensure all is regularly updated as new information is available.

Vision Meeting

The vision meeting takes place at least every 3 months. During this meeting, the product canvas is updated with the most current information and necessary actions are agreed upon.

The participants should include the product manager and/or product owners, the requirements engineers, and a representative from each development team as well as key stakeholders.

The meeting has two goals:

  • If major cornerstones of the product-canvas have to be changed (i.e. a competitor has made a major move that requires a shift in product strategy) the product’s vision/goals have to be adjusted.
  • In the second part of the meeting the team checks if the current state of the product and the planned roadmap reflects the product’s vision and goals. If goals and/or vision are not met, or are endangered, necessary steps are discussed and agreed upon.

The product vision is the highest abstraction level of the product that all following steps are based upon. Thus the vision meeting should always be the starting point in the meeting cycle.

Prioritization Meeting

The prioritization meeting should happen at regular intervals of at least every 3 months. The participants should include the product manager and/or product owners, the requirements engineers, and a representative from each development team as well as key stakeholders.

Usually this is aligned with the delivery rhythm (often also called “cadence”) of the teams. I.e. if the agile teams use sprints of 4 weeks the frequency of the meeting should not be every 3 weeks, but every 4, 8 or 12 weeks, to run in the same rhythm as the delivery teams. Also the experienced change frequency should be considered – if major changes happen quite often – which often happens at the beginning of a product’s lifecycle –  a shorter interval is recommended.

The inputs are the identified opportunities/improvements which will be prioritized during the meeting. As estimation and prioritization at this stage is relative, adding one new item, may impact the whole prioritization queue, so having that prioritization discussion at regular intervals is crucial. We recommend to make a meaningful preselection of the items brought to this meeting, as there are many people involved and time is valuable.

Making this meeting fast and efficient is key to get the commitment to have that meaningful discussion at regular intervals – thus an experienced agile moderator is highly recommended.

Roadmapping meeting

The roapmapping meeting should be held at least once a month, as the resulting roadmap is the major baseline that always has to be up to date. Similar to the prioritization meeting, the roadmapping meeting should be aligned with the delivery rhythm of the delivery teams. If you are using Scrum for example, the roadmapping meeting should always take place shortly before the sprint planning, so all product-information is up to date for the development teams to base their plans upon.

As the roadmapping meeting is more of an internal meeting, the participants should the product manager and/or product owners, the requirements engineers, and a representative from each development team.

The needed inputs for the roadmapping meeting are

  • Key agile metrics that is used in the roadmap (i.e. velocity of teams – see also Blocks of work)
  • Up to date prioritization of opportunities/improvements
  • Development-Team(s) capacity for the next 6 months
  • The updated product vision canvas
  • Key milestones (and their most current dates)
  • External dependencies that need to be managed

It is the responsibility of the product manager/product owners to make sure that the required inputs are available before the meeting starts.

As the roadmapping meeting depends on the up to date prioritization of opportunities/improvements, it is strongly recommended to do a roadmapping meeting shortly after the prioritization meeting has taken place.

The output of the roadmapping meeting is an up to date roadmap for at least the next 6 months. Usually the roadmap spans even 12 months. Remember, that a longer outlook in the roadmap does not mean, that it all has to have the same level of detail. The further the point in time is from now, the rougher the outline of the product can be.

Product Retrospective Meeting

The goal of the product-retrospective is to improve the product management process (not the product itself). Product manager, product owner(s), requirements engineers and team representatives meet at least once a month and conduct a retrospective meeting.

No matter what format the retrospective takes, it always follows these three key steps:

  1. Gathering of input
  2. Prioritization (usually “dot voting”)
  3. Discussing the highest priority items and deriving action items

Over time, numerous retrospective formats have emerged. For starters, we recommend something like a starfish retrospective. Over time, product teams can (and should) evolve their retrospective formats (See “Retromat” for various examples and inspirations)

It is highly recommended to have this meeting facilitated by an experienced agile coach/scrum master.

Story mapping & estimation meeting

For story mapping and estimation, there is no fixed schedule as this usually happens on a “do when needed basis”. Several development frameworks also have events set for this, like the “refinement meeting” in Scrum.

It usually makes sense to plan a user story mapping workshop at least after the prioritization meeting, as the newly prioritized opportunities and improvements have to be broken down further. But story mapping & estimation is not limited to a specific meeting or event, and can be done when needed during daily routine.

Keep in mind that we don’t have to break down all available opportunities and improvements down to the same level of detail. Precise requirements analysis and estimation takes time and in the need of deterministic project plans, teams can easily get lost in estimating and planning. Managing and estimating requirements the agile way means that the near future should be precisely planned and estimated, but the far future can be less clear as it most likely will change. Spending too much time in detailing and estimating something that may or may not be developed in a year is often a waste of time, when after some time the requirements are skipped due to changes in product development, or market shifts.

So keeping the balance between precision in planning for the near term and less precise but more rough and visionary planning for the mid/long term is key here.