Scrum Release Planning

Moving to smaller, predictable, release schedules

  • Problem Statement: Challenges with current release process (5 min)
  • Proposed Approach: Scrum Release Plan (10 min)
  • Prerequisites: Challenges to address before moving to a release plan, changes required  (10 min)
  • Next Steps and action items (5 min)

Agenda

Iron Triangle

5 Levels of Planning

Vision, Roadmap, Release plan, Sprint plan, Daily plan

Concerns

Large Releases, hard to nail down, lots of testing resources allocated

  • Lots of tickets in a release
  • Scrum Teams are not cross-functional - testers allocated to other projects, devs not testing
  • Resource-efficiency is valued over flow-efficiency
  • Indefinite time to complete a project (lack of release plan)
  • Many tickets queued up from many sprints un-tested
  • Waterfall approach to projects where testing happens at the end, results in reduced quality.
  • Longer regression cycles 
  • Un-testable tickets are brought in with the understanding, any problems will be caught in regression.

KPI's Aligned to Scrum

  • Developers:
    • 5 MR's per sprint (encourages smaller bite-size tickets,  which allows the sprint goal to be achievable)
    • Obtain the Certified Scrum Developer
    • Meet Scrum Team KPI's
  • Testers:
    • Obtain Certified Scrum Developer (yes, "developer" as testers are considered developers)
    • Meet Scrum Team KPI's
  • Product Owners:
    • Create (or revise) their team's "Vision" and "Roadmap" for their team
    • Have a transparent, ordered backlog capable of filling a 6 sprint release plan
    • Obtain a certification i.e. Certified Scrum Product Owner
    • Meet Scrum Team KPI's
  • Scrum Teams:
    • Average of 95% acceptance rate for sprint commitments (encourages teamwork, agility, swarming on tickets)
    • Create a 6-sprint release plan and execute it.
    • Implement 1 improvement from retro every sprint
    • Conduct a mini-regression every sprint covering the key system areas
  • Dev Leads, Testing Leads
    • Obtain a certification i.e. Certified Agile Leadership Essentials

Agile Lunch & Learns

  • Backlog Refinement - 3 C's of a User Story, INVEST, bad habits, good habits
  • Effective Retrospectives - Fostering psychological safety to surface issues, focus on actionable outcomes
  • Sprint Planning - what makes a good sprint goal?, capacity planning, determining velocity, good/bad habits
  • Sprint Review - do's and don'ts
  • Constant Ticket demos - why they are invaluable for feedback loop
  • Creating Self-Managing Teams - Team Name, Team Norms, DOR, DOD

Foster an agile environment thru Monthly L&L's on scrum theory:


    Improvements

    Smaller, time-boxed releases

    Definite time frame (release plans)

    Testing to occur in-sprint

    Flow-efficiency is valued over resource-efficiency

    Cross-functional scrum teams (devs and testers swarm on tickets)

    Mini-regressions to happen every sprint

    PO Acceptance to happen in every sprint

    UAT to happen every sprint

    Testable tickets only

    Team must have a clear vision, roadmap, and ordered backlog from their product owner.

    "Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made." - The Scrum Guide

    "Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless." - The Scrum Guide

    Scrum Values

    • Commitment
    • Focus
    • Openness
    • Respect
    • Courage

    Benefits of Scrum

    • Quicker release of useable product to users and customers.
    • Higher quality.
    • Higher productivity.
    • Lower costs.
    • Focus on generating value
    • Greater ability to incorporate changes as they occur.
    • Happier teams, higher morale
    • Better user satisfaction.
    • Being able to complete complex projects faster and predictably.

    Issues Releasing Software

    • Issues with Releases
      • Large scope of work
      • Organically defined scope of work
      • Massive testing effort
      • Longer regression testing
      • Pulls testers away from pods
      • Less collaboration between testing and dev
      • Tickets are tested at the end of a project (waterfall)
      • Testing Suffers
    • Long stretches between releases
    • Resource-efficiency is prioritized over process-efficiency
    • Customers are not receiving high-value features often

    How do we contribute to the Company KPI's?

    • 40M Revenue (Make sales)
    • Net Retention 96% (Keep & upsell customers)
    • Gross Margin 70% (Productivity, Efficiency, Quality)

    Deliver high-value features frequently

    How do we deliver high-value features frequently?

    • Scrum and Agile
    • Scrum Release Plan

    What is a Scrum Release Plan?

    5 Levels of Planning

    Vision, Roadmap, Release plan, Sprint plan, Daily plan

    Release Plan 

    Each team has its own release plan

    A subset of the product backlog is allocated into 6-7 sprints (Quarterly)

    Who creates it?

    PO and Scrum team

    Developers and testers collaborate with their product owner

    How many points per sprint?

    In order to create (and execute) a release plan, we use a team's velocity to predict the number of points a team can complete each sprint. 

    Velocity: The average # of points a team can complete per sprint based on historical performance. 

    • Only includes "completed" tickets
    • Completed = developed and tested

    HIP Sprint

    Hardening, Innovation, Planning

     

    Keys to Release Plan

    1. Identify risks and dependencies
    2. Only fill up each to 80% capacity. Leaves room for injection, unknowns, and improvements that come out of retrospectives
    3. All tickets developed and tested within same sprint
    4. Small tickets (1-3 points)
    5. Sprints will be grouped with similar tickets that can be more easily completed together
    6. QA to conduct mini-regressions every sprint focusing on key areas affected by tickets
    7. Every ticket is demo'd to and accepted by the Product Owner
    8. Product Owner will be building and prioritizing features and tickets for the next quarterly increment.
    9. Entire scrum team collaborates on release plan

    Anticipated challenges

    1. Ordered feature backlog (team roadmap) - Product team

    2. Enough product backlog (Jira tickets) to fill 6-sprints - Product team / Scrum teams

    3. Develop and test in the same sprint - Technology management / Scrum teams
    4. Velocity per team is unknown - Scrum teams
    5. Un-tested tickets need to be caught up - Technology management
    6. Amount of testers per team  - Technology management

    Backlog requirement

    Need to fill 6 sprints

    In order to create a release plan, a team's backlog must be ordered, and backlog items refined to the level needed to size them. 

    1. Ordered feature backlog

    2. Enough product backlog to fill 6 sprints

    1. Create a team's Vision
    2. Create a team's Roadmap and have it transparent in Jira
    3. Ordered backlog in Jira that can fill 6 sprints
    4. Jira expertise
    5. Understanding of scrum best practices

    Product Team

    2. Enough product backlog to fill 6 sprints

    • Become very efficient at Backlog Refinement
    • Assist product team in getting 6 sprints worth of tickets ready for filling a release plan
    • Help transform backlog items from "In requirements" to "Ready for Dev"
      • Clear and specific acceptance criteria for every ticket
      • Split tickets into multiple smaller tickets often
      • Estimated / Sized, based on dev and testing effort
    • ​Understanding of scrum best practices

    Scrum Team

    3. Develop and test in the same sprint
    4. Establish team velocity
    Technology management / Scrum teams

    • Ability to dev and test all tickets in the same sprint
      • ​More testers?
      • More cross-functional teams?
      • Lower WIP limits, more swarming
    • ​More detailed sprint planning
      • Smaller tickets
      • Tickets sized by entire team (Planning Poker)
      • Task planning vs point planning
    • ​Velocity can be established in 2-3 sprints provided dev and testing in same sprint

    Establishing Velocity

    Velocity takes 3-4 sprints to determine

    All tickets must be tested and accepted within the same sprint in order to establish a velocity.

    5. Un-tested tickets need to be caught up
    Technology management

    • Decryption-like catch-up effort?
    • Volunteer catch-up effort?
    • Remove low-priority tickets from Denali?
    • Resource efficiency vs. flow efficiency

    6. Do we have enough testers?
    Technology management

    • Do we have enough testers to develop and test in the same sprint?
    • Tester to developer ratio?
    • FE to BE developer ratio?

    Action Items / Next Steps

    1. Next meeting to discuss un-tested ticket backlog, no in-sprint testing
    2. Engage with Product Team and get them involved
    3. Release Planning weekly standup

    Next Steps
    Actions
    Questions

    Scrum Release Planning - Part 1

    By Rich Finelli

    Made with Slides.com

    Scrum Release Planning - Part 1

    • 84

    More from Rich Finelli