Create a Product Plan

Create a Product Plan2017-10-12T22:05:27+00:00

Product Planning Workflow

Context

Summary

Provide a summary of this practice.
Product planning translates the Product Vision into a sequence of product releases.

For Agile’s general principles of planning, click here.

Purpose

What is the overall goal or intention of this practice?

Product Planning is used:

  • To translate the Product Vision and Strategy into a sequence of releases that will implement that product.
  • To capture the elements of a Product Strategy that affect the development team(s).
  • To set for each release:
    • Goals and scope.
    • Features, epics and (where known) stories.
    • Target schedule.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

  • Product Planning cannot normally be completed in a single session.
  • Product Planning is a recurring process.
    • It should be repeated at least once per quarter.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

  • The Product Backlog has been populated with product ideas, epics, features and (where available) high-level stories.
  • A committed Product Plan is in place.

Entry conditions

What pre-conditions must be met before this practice is used?

  • A Product Vision has been agreed.

 

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1Refine Product Vision
  1. The participants review a Product Vision, to confirm that it includes the details the Agile team needs to deliver the product as expected.
    • If the necessary details are not included, the team should work with the relevant stakeholders, authorities & subject-matter experts to refine the Product Vision appropriately.
2Prepare Product Backlog
  1. Analyse the Product Vision into distinct deliverable components.
    • This is strictly preliminary: the structure of the product should be expected to evolve throughout its lifetime.
  2. If this is not the first version of the Product Vision:
    1. Identify any changes and additions to the previous version.
    2. Review the existing roadmap for impacts.
    3. Identify key events & scheduled outcomes.
    4. Review known product issues.
  3. Translate all the above into features, epics, themes and (where appropriate) stories.
  4. Classify items.
  5. The results are then used to populate the Product Backlog.
3Prepare Product Plan
  1. Prioritise Product Backlog items.
  2. For each High priority item:
    • Estimate the item.
    • Prioritise against other ‘High’ items.
    • Identify dependencies.
    • Identify exceptional costs and/or risks.
    • Estimated number & types of users, etc. who will benefit from each item.
  3. Divide the Product Backlog into releases, based on:
    • The team’s proven velocity.
    • Backlog item priority.
  4. If the resulting Product Plan does not extend for more than 4 releases or 9-12 months ahead, repeat for each Medium priority item.
4Validate Product Plan
  1. The Product Plan is validated against the Product Vision.
    • I.e., are all items in the Product Plan justified by the Product Vision?
  2. The Product Vision is validated against the Product Plan.
    • I.e., are all aspects of the Product Vision accounted for by the Product Plan?

Detailed process

#StepByOutputInstructionsNotes
1Refine Product VisionProduct Owner.

Business stakeholders.

Subject-matter experts.

Iteration Leads.

Expanded Product Vision.
  1. The participants review a Product Vision, to confirm that it includes the details the Agile team needs to deliver the product as expected.
    • If the necessary details are not included, the team should work with the relevant stakeholders, authorities & subject-matter experts to refine the Product Vision appropriately.
  • This procedure for completing this task can’t be defined in any detail, as it will be specific to individual organisations.
  • The Product Vision is described in detail here.
  • Issues that need to be established in advance of this task include:
    • What are the relevant organizational vision and goals?
    • Is the overall status of the product clear?
    • Where is the product in its overall lifecycle?
    • Events & deadlines that will impact the product?
2Prepare Product BacklogProduct Owner.

Business stakeholders.

Subject-matter experts.

Iteration Leads.

Product Backlog.
  1. Analyse the Product Vision into distinct deliverable components.
    • This is strictly preliminary: the structure of the product should be expected to evolve throughout its lifetime.
  2. If this is not the first version of the Product Vision:
    1. Identify any changes and additions to the previous version.
    2. Review the existing roadmap for impacts.
    3. Identify key events & scheduled outcomes.
    4. Review known product issues.
  3. Translate all the above into features, epics, themes and (where appropriate) stories.
  4. Classify items.
  5. The results are then used to populate the Product Backlog.
  • At this level, there is no need to translate features, epics and other high-level ideas into stories.
  • Each deliverable should be:
    • Value-adding in its own right.
    • Independently deliverable.
  • Building the Product backlog is a constantly on-going process.
    • There is no point at which the Product Backlog is complete.
    • The team should be constantly looking for new ideas & improvements.
3Prepare Product PlanProduct Owner.

Business stakeholders.

Subject-matter experts.

Iteration Leads.

Product Plan.
  1. Prioritise Product Backlog items.
  2. For each High priority item:
    • Estimate the item.
    • Prioritise against other ‘High’ items.
    • Identify dependencies.
    • Identify exceptional costs and/or risks.
    • Estimated number & types of users, etc. who will benefit from each item.
  3. Divide the Product Backlog into releases, based on:
    • The team’s proven velocity.
    • Backlog item priority.
  4. If the resulting Product Plan does not extend for more than 4 releases or 9-12 months ahead, repeat for each Medium priority item.
  • Each release should be defined in terms of:
    • Title.
    • Target date.
      • By month or quarter, not precise calendar date.
    • Aim.
    • Scope.
    • Stakeholders.
  • Product Plan formats are flexible.
  • By default, prioritise by business value.
    • Alternative prioritisation methods should be identified by the business or other stakeholders.
  • A High/Medium/Low prioritisation is enough at this stage.
    • Exact numbers not required or realistic.
    • Only estimate precisely enough to prioritise.
  • Assignment to releases should be:
    • Based initially on their current prioritisation.
    • But also adjusted for any other relevant factors, as agreed by the relevant stakeholders.
4Validate Product PlanProduct Owner.

Business stakeholders.

Subject-matter experts.

Iteration Leads.

Product Plan.
  1. The Product Plan is validated against the Product Vision.
    • I.e., are all items in the Product Plan justified by the Product Vision?
  2. The Product Vision is validated against the Product Plan.
    • I.e., are all aspects of the Product Vision implemented by the Product Plan?
  3. The team display the agreed Product Plan.
  • Without full traceability in both directions, there’s a serious risk that the team’s work will become divorced from the organisation’s goals.
  • In that situation, no matter how good a product the team builds, from the organisation’s point of view it will have failed.

 

Issues & risks

What are the key concerns in making a success of this practice?

  1. For an overview of Product Management as a whole, see here.
  2. A Product Plan should aim to look 9-12 months ahead.
  3. Additional participants might include:
    • Program and PMO representatives.
    • Senior user representatives.
  4. Product Planning is not the last word.
    • Release and Iteration Planning are closer to delivery.
    • They are likely to raise issues that require the Product Plan to be amended.
    • This may require managing with senior stakeholders.
  5. Product Plans generally need several cycles to mature.
    • As a result:
      • A one-off plan is usually worthless …
      • … and often misleading or even actively counter-productive.
    • So product planning should be repeated in a regular cycle.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?