1. Creating a Release Plan
    1. Weekly velocity defines sprint capacity
    2. How many sprints will give us a release?
    3. Calculating your initial velocity
      1. Get the team to guess how long it would take to deliver a release
      2. Split work into weeks
      3. Assign story points based on relative effort
      4. Run for a week and calculate actual velocity
    4. Internal Releases are PSIs (Potentially Shippable Increment)
    5. External Releases are Releases
    6. Good idea to have at least one hardening iteration leading up to a release
    7. Release cadence
      1. 4-5 iterations followed by a hardening iteration
    8. Releases should not be a big deal - it's something we do all the time
    9. Best/Worst Case Planning
      1. For 3 sprints
        1. Highest number of points
        2. Lowest number of points
      2. Calculate average worst & best capacity
  2. The Agile Release Train
    1. How do you scale agile across multiple teams and get them all pulling in the same direction?
    2. Continuous integration across multiple products and components
    3. Don't integrate the whole system late
    4. Don't let the slowest component drag the train
  3. Initial Backlog
    1. What Goes on the Product Backlog?
      1. User Requirements
      2. Technical Requirements
        1. Infrastructure
        2. Platform
      3. Bugs
        1. Keep to a limit
    2. Creating Your Initial Product Backlog
      1. Single Source of Requirements
      2. Constantly Evolving
      3. Ordered Based on Value
      4. Estimated by the Development Team
  4. Primary Role
    1. Ensure we are building the right thing
    2. Help position the development team for success in the iteration. For if they fail, you fail together.
    3. Deliver business value as economically as possible
  5. Responsibilities
    1. Manage economics
      1. Single release ROI
      2. Multi-release ROI
    2. Participate in planning
    3. Groom the product backlog
    4. Define acceptance criteria and verify that they are met
    5. Collaborate with the development team
    6. Collaborate with the stakeholders
  6. Characteristics
    1. Domain skills
      1. Is a visionary
      2. Knows not everything can be anticipated
      3. Has business and domain expertise
    2. People skills
      1. Has a good relationship with stakeholders
      2. Is a negotiator/consensus builder
      3. Is a good communicator
      4. Is a powerful motivator
    3. Decision making
      1. Is empowered to make decisions
      2. Is willing to make hard decisions
      3. Is decisive
      4. Takes an economic view to balance business/technical issues
    4. Accountability
      1. Accepts responsibility for the product
      2. Is committed and available
      3. Acts like a Scrum team member
  7. Patterns
    1. Do
      1. Say what needs to get done
      2. Challenge the team
      3. Get interested in building a high-performance team
      4. Practice business-value-driven thinking
      5. Protect the team from outside noise
      6. Incorporate change between sprints
      7. Continuously deliver value
      8. Focus on capabilities
      9. Fix broken windows
    2. Don't
      1. Say how to do it or how much it will take
      2. Bully the team
      3. Focus on the short-term deliveries only
      4. Stick to the original scope and approach "no matter what"
      5. Gold plate
      6. Not pay down technical debt
      7. Waterfall the iteration
      8. Worry the team with changes that might happen, until they become real
      9. Allow change to creep into sprints
  8. Prioritising the backlog
    1. Independent User Value
    2. Iteration/(time) value
    3. Risk reduction
    4. Determining Business Value
      1. Saving Money
        1. Retain Existing Customers
        2. Reduce Costs
      2. Making Money
        1. Increase Revenue
        2. Attract New Customers
    5. ROI (Value/Effort)
    6. Feature Grouping
    7. Politics/Customer Demands
    8. Value Estimation
      1. Effort Points
      2. Value Points
      3. Fixed Pool
        1. 1 - 100
        2. Increments of 100 up to 1000
    9. Enterprise Product Backlog
      1. Doing the most valuable work no matter which product it is in
  9. Product Manager vs. Product Owner
    1. Product Manager is market facing
    2. Product Owner is solution facing
  10. Planning Principles
    1. Can't get the plans right up front
    2. Up-front planning should be helpful without being excessive
    3. Keep planning options open until the last responsible moment
    4. Focus more on adapting and replanning than on conforming to a plan
    5. Correctly manage the planning inventory/WIP
    6. Favor smaller and more frequent releases
    7. Plan to learn fast and pivot when necessary
      1. A course correction to test a new hypothesis about the product, strategy, and engine of growth
  11. Planning Levels
    1. Portfolio
      1. Years
      2. Stakeholders & Product Owners
      3. Which products to work on, in what order, and for how long
        1. Portfolio backlog and collection of in-process products
        2. Optimise for lifecycle profits
          1. Calculate the cost of delay
          2. Linear
          3. Large fixed cost
          4. Must do now
          5. Fixed date
          6. Logarithmic
          7. Intangible
          8. Estimate for accuracy, not precision
    2. Product
      1. Halves
      2. Product Owner and Stakeholders
      3. Create a rough vision & plan for the creation of a product
      4. Product vision, roadmap, and high-level features
    3. Release
      1. Quarters
      2. Entire Scrum team and Stakeholders
      3. Making scope, date, and budget trade-offs for incremental deliveries
      4. Release plan
    4. Sprint
      1. Weekly
      2. Entire Scrum team
      3. Next level of just-in-time detailed planning around delivering a feature
      4. Sprint goal and sprint backlog
    5. Daily
      1. Every day
      2. ScrumMaster and Development Team
      3. The most detailed level of planning occurs during the team’s daily scrum meeting
      4. Inspection of current progress and adaption of how best to organise the upcoming day's work
  12. Sprint Zero
    1. Product Vision
    2. Initial Product Backlog
    3. Initial Release Plan
    4. Architecture Approach & Coding Practices
    5. Continuous Integration Environment
    6. Small Product Increment
  13. Envisioning / Product Planning
    1. Product Vision
      1. Creating a Product Vision
        1. Target Market
        2. Business Need / Opportunity
        3. Key Features
        4. Value to the Company
      2. Qualities
        1. Broad and Inspiring
        2. Clear and Stable
        3. Short and Sweet
        4. Highly Visible
        5. Frequently Revisited
      3. Areas of Stakeholder Value
        1. Entry Conditions
          1. Achieve parity with competition
          2. Deliver minimum required features
          3. Get compliant (SOX, FDA, HIPAA)
        2. Enablement
          1. Target a new market
          2. Enable sales of other products or services
        3. Differentiator
          1. Differentiate from competitors
          2. Delight the customer
        4. Spoiler
          1. Eliminate competitors' differentiator
          2. Raise the parity bar
          3. Redefine the game by changing market focus
        5. Cost Reducer
          1. Shorten time to market
          2. Reduce the number of people or their time allocation
          3. Improve margins
          4. Increase expertise
      4. Formats
        1. Elevator Pitch
        2. Product Datasheet
        3. Product Packaging
        4. User Conference Slides
        5. Press Release
        6. Magazine Review
    2. Epic-Level Product Backlog Creation
    3. Knowledge Acquisition
    4. Product Roadmap Definition
      1. Release Schedule
      2. Market Events
      3. Architecture Map
      4. Feature/Benefit Map
      5. Market Map
      6. Minimum Releasable Features
        1. Minimum Marketable Features
        2. Minimum Viable Product
    5. Guidelines for economically sensible envisioning
      1. Target a realistic confidence threshold
        1. Setting the bar too high has economic consequences
          1. More time is spent envisioning - delays product delivery
          2. More money is spent during envisioning
          3. Creates wasteful inventory of not-yet-validated artifacts
          4. Provides only the illusion of increased certainty
          5. Increases risk of making bad decisions using low-value information
      2. Focus on a short horizion
      3. Act quickly
      4. Pay for validated learning
      5. Use incremental/provisional funding
      6. Learn fast and pivot
  14. Estimating
    1. An estimate is not a guarantee of delivery
    2. Smaller things are easier to estimate than larger things
    3. Estimating with Time Boxes
    4. Story Points
      1. High Level Estimate of Size
      2. Based on a Relative Scale
      3. Estimated as a Team
        1. New teams can estimate a medium as a 5, then relatively estimate other stories based on that first story
        2. Planning Poker
          1. Avoids Anchoring
          2. Everyone has an equal voice
      4. Not Based on Duration
      5. Fibonacci Sequence
        1. 1, 2, 3, 5, 8, 13, 20, 40, 100, ?