Product Line Team Meetings

  2. /
  3. System of Delivery
  4. /
  5. Structure
  6. /
  7. Product Line Team
  8. /
  9. Product Line Team Meetings
The Product Line Team has four meetings. Each meeting is a working session with specific outcomes. Click on the links below to jump to a particular meeting on this page.​​​

​​Product Refinement & Progression
Product Planning
Metrics & Retrospective
Release Planning

R.A.C.I 

 

Responsible   Accountable   Consulted   Informed

F.A.C.I 

 

Facilitator ​Accountable Consulted Informed

Product Refinement & Progression

This is a set period when the Product Line Team makes decisions and does the work necessary to move Features through the system and prepare them for the Delivery Team. How the time is allocated during the week is up to the Product Line Team. The activities that occur during this time depend on the state of the features on the Kanban board. The Product Line Team always “Walks the Kanban,” discussing Features underway and ensuring a shared understanding of current progress, dependencies, and outstanding risks. The team then conducts several activities based on the Kanban review or from their agreement in the Product Line Team Planning meeting.

Details 

Governance State: N/A

4 hours, twice weekly​​​

F – Product Orchestrator

A – Product Owner

C – SME 

 I – Product Category Team

Post-Meeting Activities: 

  • Initiate / update Features, Risk Stories and Dependencies in Jira
  • Initiate named Stories in Jira
  • Update Feature Briefs as needed​​​​​​​

Prerequisite Work​​​​

Each of the formal activities above has specific prerequisites and outcomes. The team members involved with the activity must be well-prepared so that the Features can successfully progress and the activity is successful (See Feature Refinement Guide under Basecamp 1 Outcome 2: Establish Flow of Work). This might include the Product Owner having the requisite materials, the right attendees being invited to the meeting, each team member being ready to demonstrate their part, etc. The Product Orchestrator can assist initially with ensuring that the agenda for the day is known and each team member is prepared.

Activities can include: 

  • Intake
  • Solution Design
  • Story Mapping
  • Feature Validation/Demo
  • Deployment Readiness​

Product Refinement & Progression Agenda

​Opening

Outcomes:

  • Announcements/updates
  • Establish meeting focus

F – Product Orchestrator    A – Product Orchestrator​​

​Open the meeting​​​ with announcements or updates; share meeting focus (planned discussions and decisions); validate that the appropriate information is available to have those discussions and/or make the anticipated decisions.​​

​Intake/Alignment

Outcomes:

  • Shared understanding is reached about the Epic and the Feature
  • Feature Brief is initiated
  • Order of Magnitude is assigned to feature
  • Initial dependencies, unknowns, risks, assumptions are documented

 

See detail in the Intake Guide under Basecamp 1 Outcome 2: Establish Flow of Work 

F – Product Owner/Product Manager    A – Product Line Team    C – SME, Developer    I – N/A

Once WIP allows, a new Feature can be accepted into the Product tier workflow. The Intake activity aims to gain a shared understanding of the Epic and begin to discuss what detail the Feature will require to be prepared for the Delivery teams.

Prerequisite Work

  • Epic brief is sufficiently refined and has identified candidate features
  • Share Epics/Features to be reviewed in advance of the meeting
  • Ensure the right team members are invited and available

 

Key Discussions and Decisions

  • Open the meeting with a purpose statement for the meeting identifying the Epic (and Features, if available) under consideration
  • Review the content of the Epic Brief and the intended customer impact
  • Review the Epic Brief and potentially the Epic Canvas if needed
  • Review and discuss the User Journey
  • Review and discuss the high-level architecture and related NFRs and constraints
  • Discuss the potential features, identify Persona/acceptance criteria, and draw/refine the user journey and architectural models.
  • Identify and discuss dependencies, risks, and assumptions
  • Identify and discuss unknowns or areas where additional information is needed
  • Assign an Order of Magnitude estimate to the Feature
  • Review decisions and action items and schedule meetings to advance planned work
  • Confirm RACI and timing for action items

Solution Design

Outcomes:

  • Named Features sufficiently elaborated so that intention, scope, and priority is clearly understood
  • Features are ready for release targeting and ready for Delivery Team consumption

F – Product Owner  A – Product Line Team​  C – SME, Product Architect, Delivery Lead  I – Solution Architect, Product Manager 

Solution Design is a key collaborative activity to explore further solution options for the goals expressed in the Epics, define Features to clarify the work, and identify and manage risks and dependencies.  

Prerequisite Work​​​​

  • High-Level Design: Model features to promote a shared understanding.
  • Identify the risks and dependencies 

 

Key Discussions and Decisions

  • ​​​​​​Open the meeting with purpose statement of the meeting identifying the Epic, if available, and Features under consideration
  • Review the Feature Brief. Review the Feature Level model
  • Write Story Titles initially. May start building the Story Map. Stories will be refined later.
  • Identify and discuss potential risks and dependencies. Identify and document key assumptions and unknowns in the Feature Brief.

  • Estimate the Features (SWAG)

    Note: The estimate can be estimated in terms of weeks or X number of sprints (based on the known capacity of the Development teams)

  • Confirm RACI and timing for action item
  • After the meeting:
    • Initiate/update Features, Risk Stories, and Dependencies in the ALM tool
    • Initiate named Stories in the ALM tool
    • Update Feature Briefs as needed

Story Mapping

Outcomes:

  • Shared understanding of Epic
  • Shared understanding of Feature(s)
  • Candidate stories across journey
  • Stories estimated using Affinity Estimation. Features estimated through roll up of the story points​
  • Dependencies identified
  • Feature targeted to release
  • Target deployments identified
  • Updated Feature Validation Plan, Risks and dependencies

 

See detail in the Intake Guide under Basecamp 1 Outcome 2: Establish Flow of Work 

F – Product Owner   A – Product Line Team    C – SME, Delivery Lead    I – N/A
Each Feature goes through a story-mapping session where stories are identified (as stubs) and estimated (affinity estimation), MMF is determined, dependencies are identified, and the release and possible deployments are determined.

Prerequisite Work

  • Feature Brief is advanced enough to perform estimation
  • Preparation for the estimation exercise has been performed using the above guides

 

Key Discussions and Decisions

  • Discuss epic that relates to the Feature(s) that will be estimated
  • Review any risks or unknowns at this time

Map Feature

  • Discuss Feature (s) that will be discussed
  • Agree on Feature purpose, business reason, Persona, system context
  • Discuss Risks, Dependencies, assumptions, key gaps in information, acceptance criteria
  • Identify Persona and User Journey(s)
  • Identify journey steps at the top of the Story Map
  • Create and add stories under journey steps on the Story Map. Story stubs should have a readily understandable title. Add initial acceptance criteria if known

Estimate stories

  • Using the guides above, perform rapid estimation to get a rough value of the candidate stories

Determine Minimal Marketable Feature (MMF)

  • Determine the MMF by removing Stories that are not critical to realizing the goal of this Feature

Story Slicing / Sprint Sizing

  • Rearrange the user story stickies to fit into sprint timeframes. Discuss inter- and intrateam dependencies, priority, technical needs, and spikes.
  • Illustrate dependency lines on the map to help reinforce the dependencies are all identified
  • Slice stories as needed to fit in a sprint timeframe. This is not a commitment and not about precision. This is to identify dependencies

Release and Deployment targeting

  • Add individual story maps to the Program board. Progressively build separate features by target release
  • Separate features by target release
  • Identify target deployments

Update documentation

  • Update Feature Validation Plan
  • Update Risk Register
  • Update Dependency List

Feature Validation

Outcomes:

  • Agreement that the Feature meets the acceptance criteria
  • Details on mitigation if additional work needs to be done

 

See detail in the Intake Guide under Basecamp 1 Outcome 2: Establish Flow of Work 

F – Product Owner    A – Product Owner/Product Architect​    C – SME    Delivery Lead    I – N/A​​​ 

The purpose of Feature Validation is to establish a shared understanding that expected Features have passed testing successfully and fully meet the Definition of Done. 

Prerequisite Work​​​​

Product Owner

  • Identify Feature(s) to be discussed at upcoming meeting
  • Clearly articulate the Feature/Capability Acceptance Criteria (aka Definition of Done)
  • Socialize agenda so those who want to contribute can attend and have a voice: “opt-in” 

Product Architect 

  • Understand the environmental requisites necessary to completely demonstrate the Feature/Capability fully in a “prod-like” environment

  • Ensure that requisites/dependencies have been mitigated/addressed before the meeting demonstration

​Key Discussions and Decisions​ 

  • Open the meeting with a purpose statement, identifying the Epic (as required) and Features under consideration
  • Review the Feature’s Desired Capabilities and Feature Acceptance Criteria
  • Demonstrate the Feature in a Prod-Like Environment and validate that it meets the Definition of Done
  • Validate that the Feature meets the Definition of Ready for delivery teams 
  • Update Feature status in the ALM tool​

Deploy Readiness

Outcomes:

  • Go/No Go decision
  • Release Notes
  • Post-Release Monitoring Plan
  • Back-out Plan
  • Communications Plan

 

See detail in the Intake Guide under Basecamp 1 Outcome 2: Establish Flow of Work 

F – Product Owner    A – Product Line Team    C – SME    Delivery Lead    I – N/A​​ 

 Prerequisite Work​​​​

  • Set agenda including features and attendees​
  • Review the preproduction checklist to ensure there are no outstanding items​
  • Appropriate Product Line Team member reviews Release Notes, Monitoring Plan, Back-out Plan, and Communications Plan 

 

Key Discussions and Decisions 

  • ​Note any exceptions or actions that must be completed before moving forward​
  • Open the floor for questions about the release.  The Q&A session brings the team closer to the Go/No-Go decision​
  • Decide to go forward with the deployment or delay until corrective action can be taken​
  • Review decisions and action items
  • Perform a brief retrospective on the session and decide what to do differently (if any) next time​

Wrap Up/Close

Outcomes:

  • Align on decisions and action items

F – Product Owner    A – Product Line Team    C – SME    Delivery Lead​    I – N/A​​ 

Key Discussions and Decisions 

  • ​​​​​​Plan for meetings to advance planned work
  • Review decisions and action items 
  • Confirm RACI and timing for action items 
  • Confirm RACI and timing for follow-on communications 
  • Perform brief retrospective on the session and decide what to do differently (if any) next time

Product Planning

The Product Line Teams comes together to review the state of work in progress and create an agreement on what will be done that week. In addition to the actual planning activity itself, this block of time is used to coordinate with other Product Line Teams and the Product Category Team. Each Product Line Team member is responsible for tracking and executing the activities that week that come out of planning discussions. This includes arranging for joint meetings and attendees, meeting deliverable agreements, and any staff work needed for the Product Refinement and Progression meeting. 

Preview features ready to move on the Kanban board to ensure policies are met; identify actions needed to meet the policies; prepare to discuss needs or deliverables to other teams in tiers or other Product Line Teams.

Details 

Governance State: N/A

2 hours weekly

 

F – Product Orchestrator

A – Product Owner

C – SME 

 I – Product Category Team

Prerequisite Work​​​​

Each Product Line Team member is responsible for taking an active role in advancing feature refinement. There is no passive role on the Product Line Team. Among other things, Team members should be prepared to speak to actions that took place last week and what work will be done this week, if known. The Product Owner should be prepared to review any new Epics and any changes in feature priority. The Delivery Lead should be prepared to speak to any feature validations that can take place this week. The Product Orchestrator should be prepared to speak to any risk or dependency management actions that were in progress last week.

Activities can include: 

  • Feature Progression Review 
  • Product Line Team Planning

Product Planning Agenda

​Opening

 

Outcomes:

  • Announcements/updates
  • Establish Meeting Focus

F – Product Orchestrator    A- Product Line Team​
​​​
Open meeting with announcements or updates; share meeting focus (planned discussions and decisions); validate that the appropriate information is available to have those discussions and/or make the anticipated decisions

Feature Progression Review

Outcomes:

  • Walk the Kanban” discussing Features and related Epics
  • Ensuring a shared understanding of current progress, dependencies, and outstanding risks

F – Product Orchestrator    A- Product Line Team​
 

Key Discussions and Decisions
 

  • Working “right to left” on Kanban board, discuss features to be moved or blocked based on exit policies
  • Move Features that are authorized or blocked
  • Note work that needs to be done for each Feature reviewed
  • Note all blockers and actions needed to remove the blocker

Product Line Team Planning

Outcomes:

  • Decide on features and attendees for upcoming workshops
  • Create action plans for escalation/mitigation steps that are necessary
  • Make Continue/Change/Stop decisions  
  • Document decisions  
  • Create communication plan

 

See detail in Product Line Team Planning Activity Guide and Product Line Team Planning Activity Guide Supplement​ under Basecamp 1 Outcome 4 Improve the System.

F – Product Orchestrator    A- Product Line Team​​​ 

Key Discussions and Decisions 

Review new items

  • Review any new Epics received to schedule for intake
  • Review any new features and schedule for input
  • Create a rolling two-week game plan for executing new work

Plan workshops

  • Determine Key discussions and decisions that need to be made
  • Identify which governance teams and/or stakeholders from which you need input
  • Schedule them on the team calendar for execution

Prepare Communications

  • ​​​​​​​Schedule meetings to advance planned work
  • Inform stakeholders on progress, plans, risks, issues, dependencies, and decisions
  • Write and send invites for meetings that need to occur
  • Product level meetings planned, features and attendees shared ahead of the meetings

Wrap Up/Close

 

Outcomes:

  • Align on decisions and action items

F – Product Orchestrator    A- Product Line Team​​​​
 

Key Discussions and Decisions
 

  • Review decisions and action items 
  • Confirm RACI and timing for action items 
  • Confirm RACI and timing for follow-up communications 
  • Perform brief retrospective on the session and decide what to do differently (if any) next time

Metrics & Retrospective

 

The entire Product Line Team participates to review how the delivery system is working and plan improvements. The team reviews performance data and analysis, evaluates different options to address issues, decides on a course of action, and creates an action plan.

Details 

G​overnance State: N/A​

1 -2 hours bi-weekly
 

F – Product Orchestrator

A – Product Owner  

C – SME 

 I – Product Category Team

Prerequisite Work​​​​

The Product Owner will need to have the most current Feature flow metrics to review with the team. See the Playbook Artifacts for more information on metrics. Metrics such as Cycle Time, Throughput, and Lead Time help illustrate opportunities for improvement. Time in each Kanban state can illustrate constraints or process issues. The Product Owner should be prepared with trend reports to show performance change. 

The Product Orchestrator should have the results from the last Retrospective and the actions agreed upon. The Product Line Team members can rotate who conducts the Retrospective so the team doesn’t become dependent on any single person.

Activities can include: 

  • Operations review
  • Retrospective

Metrics & Retrospective Agenda

​Opening

 

Outcomes:

  • Ensure team is prepared to have a successful meeting 
  • Establish meeting focus

F – Product Orchestrator    R – Product Line Team    A – Product Orchestrator

Open the meeting with announcements or updates; share meeting focus (planned discussions and decisions); validate that the appropriate information is available to have those discussions and/or make the anticipated decisions

State the Prime Directive and do a safety check 

​Operation Review

Outcomes:

  • Team is aligned on operational progress 

 

See detail in Operations Review Activity Guide under Basecamp 1 Outcome 3: Make & Meet Commitments

​​​F – Product Orchestrator    R – Product Line Team    A – Product Orchestrator

Review the previous retrospective issues, topics, and the set of changes and actions agreed to in the last retrospective.

Key Discussions and Decisions

  • ​​Review key metrics and compare trends over time
  • Discuss any conditions that may have affected a positive trend

Retrospective

Outcomes:

  • Team held accountable for actions/experiments from the last Retro
  • New ideas are surfaced from all team members
  • Actions/Experiments are agreed upon and acted upon

 

See detail in Product Line Team Retrospective Activity Guide​ under Basecamp 1: Outcome 4: Improve the System

F – Product Orchestrator    R – Product Line Team    A – Product Orchestrator

The purpose of the Retrospective is to review how the governance of the delivery process is working for the team and plan improvements. The t​eam will choose one or two specific improvements targeted to implement for the next retrospective.​​

Key Discussions and Decisions​

  • State the Prime Directive and do a safety check
  • Determine action on any previous issue that​ still needs attention​
  • Elicit new issues and topics from the team utilizing SAMLO or another supporting facilitation technique
  • Prioritize and organize the issues and topics based on team interest utilizing dot voting or another supporting facilitation technique
  • Discuss issues and topics
  • Agree to a small set of changes and actions meant to improve team performance to be carried out before the next retrospective.

Wrap Up/Close

Outcomes:

  • Align on decisions and action items

​​​​​​F – Product Orchestrator    R – Product Line Team    A – Product​ Orchestrator

Key Discussions and Decisions​​​​​​​

  • Review decisions and action-items.
  • Confirm RACI and timing for the action items.
  • Confirm RACI and timing for follow-on communications.
  • Perform brief retrospective on session and decide what to do differently (if any) next time. ​

Release Planning

Establish a shared understanding of what prioritized Features are anticipated to be included in the release. The Features that comprise the release will be refined over time.

Details 

Governance State: N/A

Governance State: Release Planning

4 hours; Release Cycle ahead of Release 

F – Product Orchestrator     

A – Product Line Team, Delivery Team         

C – Product Category Team   

 I – Various Stakeholders​

 

Related material and tools: 

  • Release Planning Activity Guide, Release Planning Activity Guide Supplement, ​Release / Quarterly Planning Workshop, and Release Plan Template under Basecamp 1 Outcome 7: Release Plan

Prerequisite Work​​​​

Product Owner 

  • List of business outcomes/objectives to be accomplished by release
  • List of prioritized Feature(s) to ​​potentially be in next release
  • High-level Feature/Capability Acceptance Criteria (aka Definition of Done)
  • Feature Testing/Validation Approach & Plan (updated)
  • Socialize agenda/Epic Roadmap so those that want to contribute can attend and have a voice: “opt-in”

Delivery Lead

  • Infrastructure & Operations Backlog / Physical Network Diagrams, etc.
  • Technical Impact Assessment (As required)
  • List of Functional Release Dates

Activities can include: 

  • Review Data
  • General Insights
  • Decide What to Do

Release Planning Agenda

​Opening

Outcomes:

  • Provide an outline of the meeting activities
  • Instructions and timing for Release Planning

​F – Product Orchestrator    A – Product Line Team, Delivery Team    C – Product Category Team    I – Various Stakeholders​

Open the meeting with announcements or updates; share meeting focus (planned discussions and decisions); validate that the appropriate information is available to have those discussions and/or make the anticipated decisions

  • Provide instructions for Release Planning
  • Highlight artifacts to be produced

Forecasting

Outcomes:

  • Forecast Features and Stories for the release; identify ​dependencies

F – Product Orchestrator    A – Product Line Team, Delivery Team    C – Product Category Team    I – Various Stakeholders​

Key Discussions and Decisions

Forecast stories for prioritized features into sprints. Identify key assumptions/dependencies, etc.

  • Prioritized List of Features with Acceptance Criteria
  • Release Plan defined with dependencies, assumptions, risks, and issues articulated and listed on their respective boards within Jira
  • Prioritized list of spikes/other orchestration needed to reduce risk and/or mitigate issues
  • Validate that stories align with technical feedback/testing approach/risk reduction​

Planning

Outcomes:

  • Plan deployment schedule, procurement and enablement
  • Plan technical approach, including testing
  • Identify and plan for issues, risks, and dependencies

​​F – Product Orchestrator    A – Product Line Team, Delivery Team    C – Product Category Team    I – Various Stakeholders​

Key Discussions and Decisions

Commit forecasted features and stories to the release period

  • Prioritize Features within the appropriate sprint during the release periods
  • Align stories to sprints for at least the first 2-3 sprints
  • Align Features on the Product Release Board with dependencies’ timing highlighted​

Vote of Confidence

Outcomes:

  • Teams return with a vote of confidence (1-5) for the Release Plan​
  • Completed Release Plan

F – Product Orchestrator    A – Product Line Team, Delivery Team    C – Product Category Team    I – Various Stakeholders​

Key Discussions and Decisions

Review Delivery Team Release Plan and Product Release Plan with Product Line Team for feedback and questions

  • Vote on the team’s confidence in its ability to deliver the Features and Stories committed to in the Release Plan
  • If necessary, make adjustments to the Release Plan and vote on the team’s confidence to deliver again

Wrap Up/Close

Outcomes:

  • Align on decisions and action items

F – Product Orchestrator    A – Product Line Team, Delivery Team    C – Product Category Team    I – Various Stakeholders​

Key Discussions and Decisions​​​​​​​

  • Review decisions and action items
  • Confirm RACI and timing for action items
  • Confirm RACI and timing for follow-on communications
  • Perform brief retrospective on session and decide what to do differently (if any) next time. ​