Release Planning is not part of Scrum, but Releases still need to be managed. How do we “promise dates” and manage to them without losing our agility? This seems like a hard problem – and it is – but in this talk I’ll show you how to do it. According to standard Project Management principles, the Release Manager does two things: she produces a Release Plan, and she keeps this plan in balance with the Realities of Development throughout the Release. A bad Release Manager tries to change Reality to match the Plan, and a good Release Manager knows that she must change the Plan to match Reality. This balancing the Plan with Reality is an inherently agile process… and is an example of the basic “contract” between Development and Management – that Development will provide good information and data to Management, and that Management will make good decisions based on that information and data.

Come let me show how you can have good Agile Release Management in your Organization.

 
1 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Here is the basic agenda for this talk:

1. Philosophy/Overview

  • What is a Release Plan?
    • Basic Elements
      • Cost: Hours or Dollars (Hours more common for Software Projects)
      • Scope: features to be delivered
      • Schedule: how many Sprints it will take
    • Types
      • When can I have it? when Schedule is the variable
      • What can I have? when Scope is the variable
      • How much will it cost? when both Schedule and Scope are fixed (the “fixed price” option)
  • Who is the Release Manager (RM)?
    • Kept away from the Developers
    • Accountable for:
      • Creating the Release Plan
      • Keeping the Release Plan ‘in sync’ with Development (and other) Realities throughout the Sprint
    • A “bad” RM tries to make Reality conform to the Plan
    • A “good” RM adapts the Plan to the Realities
    • The RM is must be able to justify the ‘current’ Release Plan, at any time, based on data… and the Developers saying they can do it is NOT data – this is the defining characteristic of a “good” RM… just sayin’…
  • What are Planning Assumptions?
    • When the RM creates the plan, he/she creates some baseline Planning Assumptions, which assume the existence of StoryPoints (SPs), which will be defined later in this talk:
      • Size: how many SPs will it take to deliver the Features that are in Scope?
      • Capacity: how ‘fast’ will SPs be earned, in SPs/100Hr (for example)
      • BurnRate: how many hours will be spent, in Hrs/Sprint
    • These baselines are used to justify the plan, and will be continually re-baselined throughout the Release, using the following process…
  • What is the overall Process?
    • First, create the Plan (we’ll do an example later)
    • Second, each Sprint:
      • Collect the Actuals (Actual Hours Spent, Actual SPs earned, proposed Scope changes)
      • Do Variance analysis, comparing the Actuals to the Baselines (I’ll describe this later, too)
      • Modify the Baselines, as required
      • Modify the Plan if the new Baselines require it

2. Details

  • StoryPoints are "a relative measure of size that can be applied to Stories and Epics." They are estimated differently for each
  • Defining StoryPoints for Stories
    • For Stories, the size is based on getting the Story to Done. For Acceptance-Based Stories, this means they meet their Acceptance Criteria and have the appropriate technical quality – and their Size is given in StoryPoints. For Time-Boxed Stories, their Size is given in Hours. By using the current Baseline for Capacity, StoryPoints and Hours can be converted back and forth…  
    • For Acceptance-Based Stories, we use an estimation game, with the definition of a StoryPoint being: “StoryPoints are a Relative measure of Ideal Effort, where Ideal Effort is the amount of effort something would take if there were *no* impediments.”
    • For Time-Boxed Stories, we just set a number of Team Hours to use
  • Defining StoryPoints for Features
    • The StoryPoint estimate for a Features is an estimate of how many StoryPoints it will take to Release a Feature
    • This is the hard one to estimate, and I will present a number of heuristics showing how to do this.
  • Example Plan
    • I will walk through the creation of a sample Release Plan
    • Blue StoryPoints versus Red StoryPoints discussion...
  • Variance Analysis
    • I will show a simple method for comparing Actuals to Baselines, whose purpose is to determine whether the current Baseline is supported by the actuals. This method is a variation of the Earned Value TCPI metric, which determines “how fast do we need to speed up to catch up?”
  • Other Metrics
    • I will also show Velocity, BurnUps, CPI and SPI (from EVM), and Earned Business Value (EBV) metrics

3. Q&A

Learning Outcome

This course is for those intending to use Scrum for software Projects, and have the needs for managing Releases. The attendees will:

  • Know that Release Management is an inherently agile process,
  • Be able to describe what a Release Plan looks like,
  • Understand what the underlying Planning Assumptions are and how they justify the Plan,
  • Recognize how and why the Planning Assumptions are analyzed and potentially re-baselined each Sprint, and
  • Have an understanding of the underlying StoryPoint-based metrics.

Target Audience

Product Owners, Release Managers, Project Managers, Program Managers

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal