| IO ANALYSIS | PART 0 | PLANNING STRATEGIES - bdemirjian/apbr2 GitHub Wiki
| Product Visioning | ||
|---|---|---|
|
Purpose: To define the vision, purpose, context, guiding principles, goals and Key Performance Indicators (KPIs) for the product or platform.
Who Participates: Product Manager, Technical Lead, UX Design Lead, Engineering Managers, APDP Coach/Program Manager, Business Stakeholders |
||
| Inputs | Activites | Outputs |
|
Strategic themes and goals Marketing or Product Requirements Document Architecture Diagrams |
Define the Vision for the product as far out into the future as possible (9 months - 2 years). Define the Purpose or Mission for the product. Define the Product Context (users, customers, products/services, channels, key features and capabilities, internal and external suppliers) Link the product to strategic themes and goals Define Current state/future state architecture Define Marketing Strategy (competitive analysis, demographics, etc.) Define Goals (customer, financial, product/process, people) Define Key Performance Indicators (KPIs) Compile components of the above items. Socialize with team or teams, leaders, stakeholders, etc. and incorporate feedback Update at least yearly |
Product Strategy |
| Tools & Templates | Success Tips | Learn More |
|
Jira Product Vision Board |
For new products, don't try and nail down all the components of the Product Strategy up front. Focus on the most important (Vision, Purpose, and Guiding Principles) then evolve as discovery unfolds. Solicit help from an Agile Coach to help facilitate and guide development of the strategy. This is an invaluable practice for any product, regardless of where the product is in its' lifecycle |
|
| Roadmap Planning | ||
|---|---|---|
|
Purpose:
To provide a high-level visual summary that maps out the vision and direction of the product over time. The roadmap communicates the why and the what behind what you are building. It is the guiding strategic document as well as a plan for executing the strategy. Who Participates: Product Manager, Product Designer, Technical Lead, Engineering Manager, Subject Matter Experts, Marketing, IT Lead, Other Product Managers, Agile Coach |
||
| Inputs | Activites | Outputs |
|
Product Vision Board Press Release Product Strategy Test Strategy Security and other Stds |
Pre Workshop Activities: Develop agendas for workshop, invitations, meeting rooms, etc. Prepare artifacts to be leveraged during the Roadmap workshop. Examples: Product Vision Board Press Release Interviews/results Goals Key Performance Indicators Hypothesis Statements Experiment results Current/Future State Architecture & Infrastructure (NFRs, etc.) Product Backlog Workshop Activities: Share product vision, mission, goals, KPIs, etc. to bring audience up to speed with the product Discuss proposed Initiatives and/or Features. Collaboratively develop model(s) to break down initiatives to features. Diagram current and future state architecture and infrastructure diagrams. Conduct Reach, Impact, Confidence, Effort (RICE) prioritization for all initiatives or features within an initiative Plot them across notional timeline (produce a Roadmap) Post Workshop Activities: Update Jira/Confluence with results Update at least quarterly |
Roadmap Product Backlog (updated) |
| Tools & Templates | Success Tips | Learn More |
|
|
Primary purpose of a roadmap is as a communications tool Ensure your roadmaps contain not only features, but technology enablers and tech debt items Leverage workshops to develop the roadmap Start with your product vision (tip: use Roman's Product Vision board) Describe and validate your product strategy Focus on goals and benefits, by creating a goal oriented product roadmap Tell a coherent story about the likely growth of your product and don't oversell it Keep it simple! Resist the temptation to add too much details to your roadmap Actively collaborate with stakeholders to ensure buy-in Have the courage to say no, to prevent an overload of features in your roadmap Think twice about adding timelines, dates or deadlines to your roadmap Make sure your roadmap is measurable, by adding measurable goals and KPI's Create a rough estimate for each feature (#people + required skills) to determine the viability of a feature Review and adapt your product roadmap on a regular basis |
see product roadmap examples |
| MTG | ||
|---|---|---|
|
Purpose:
To develop an intermediate plan for the next 3-12 sprints, foster collaboration, and identify key dependencies or milestones. Who Participates: Whole Team |
||
| Inputs | Activites | Outputs |
|
Product Roadmap Product Backlog Product Vision Architecture Diagrams Test Strategy Mockups, Prototypes, Maps Velocity Conditions of Satisfaction |
Topic 1 Pre Workshop Develop agenda for workshop, invitations, meeting rooms, etc. Prepare artifacts to be leveraged during the workshop Product Vision Product Roadmap Architecture Vision & Development Practices Customer or User Experience Designs, mockups Prioritized list of features and outcomes Business Context Key Themes For Release Release Planning Workshop Set the stage. Update team(s) with any information that is pertinent to next release Map out a high level timeline for next 3-12 sprints Identify key milestones or events Discuss, prioritize, size, split and map features to high level timeline Add enabler work to the high level timeline (CI/CD pipeline, equipment, tools, infrastructure, environments, etc.) Identify dependencies R.O.A.M. the risks Confidence Vote (fist of five) Post Workshop Update Backlog with results Update the Release Plan after every Sprint |
Release Plan Product Backlog (updated) |
| Tools & Templates | Success Tips | Learn More |
|
Jira |
Have the Development Team select and pull features and enablers from the backlog and plot them across time. They will have a general understanding of their capacity and technical dependencies. Then have the development team explain to the Product Owner the logic behind the plan (the whys). Make any adjustments. Do as little planning as is necessary Start release planning when you realize you need it, even if it’s near the end of the release effort Plan using stickies on the walls. If you must transcribe them into an online tool, do that later, after the meeting. Don’t forget that each scrum team only commits to results for the next sprint. Everything else is merely an attempt to understand what could or should happen. Release planning is not about committing to a list of features to be released on a certain date. Include internal suppliers (other product team leads, IT, etc.), vendors and other third parties who are relevant and involved in your release planning meeting Revisit the release plan after each sprint and update it Don’t give in to the urge to publish a release plan as a separate document There’s no prescribed time box for release planning because it will vary with the size of the team and the expected length of the release effort Ensure your Release Plans include not only Epics/Stories, but technology enablers and tech debt items Keep it simple! Resist the temptation to add too many details to your release plan Actively collaborate with stakeholders to ensure buy-in Have the courage to say no, to prevent an overload of epics/stories Focus on dependencies Tackle the complex or high risk stories in early sprints Do not plan any stories for the last sprint or two |
Planning a release in scrum Release Planning SAFe PI Planning |