Release planning methodology overview
Download
1 / 17

Release Planning Methodology Overview - PowerPoint PPT Presentation


  • 201 Views
  • Updated On :

Release Planning Methodology Overview. Release Planning Framework. Provide a software release planning framework that balances business concerns software development concerns provides better predictability of end-date delivered debugged feature set provides early notification of slips

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Release Planning Methodology Overview' - Gabriel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Release planning framework l.jpg
Release Planning Framework

  • Provide a software release planning framework

    • that balances

      • business concerns

      • software development concerns

    • provides better predictability of

      • end-date

      • delivered debugged feature set

    • provides early notification of slips

    • allows for re-planning as events unfold

    • deals explicitly with uncertainty

Lecture 3




Eliciting potential requirements l.jpg

?

Next Release

Potential Requirements

Eliciting Potential Requirements

  • Starts with a wish list

  • Stated as business requirements

    • Features or architectural enhancements

Lecture 3


Sizing potential requirements l.jpg
Sizing Potential Requirements

  • Cost / Benefit analysis

    • Cost: financial + opportunity = person days

  • Sizing in ECDs

    • Inherent size of the work item

    • Who will work on it

    • The productivity of that person on that work item

  • Ensure units are well-understood (more later)

Lecture 3


Sizing the available resources l.jpg
Sizing the Available Resources

  • Who can work on the next release?

    • Must have skills and familiarity to contribute

  • For how long?

    • Must count workdays in the coding phase

    • Each resource available all that time?

    • Subtract estimated vacation

  • How dedicated to the next release

    • Work factor = w

    • Converts 8-hour (nominal, arbitrary) days to time available to code and unit test during the coding phase

    • E.g. w=0.6 means can dedicate 0.6x8 = 4.8 hours/workday

    • Accounts for

      • Other tasks, sickdays, meetings, weekends, ...

    • Range is 0 .. 9, usually 0.6 or so

Lecture 3


The capacity constraint l.jpg
The Capacity Constraint

  • After all is done in a release

    Actual Resource Used == Sum of Actual Times for Features

  • This is always true. It is a constraint.

  • In planning, knowing that this must work out at the end, can estimate both sides and force the estimates to be equal

    Resource Estimate == Sum of Feature Estimates

Lecture 3


A geometric analogy capacity l.jpg

p

e

r

s

o

n

s

days

1 person-day

A Geometric Analogy - Capacity

Lecture 3




A simple release plan l.jpg
A Simple Release Plan

Dates: Coding phase: Jul.1—Oct.1

Beta availability: Nov.1

General availability: Dec.1

Capacity: days available

Fred 31 ecd

Lorna 33 ecd

… …

Bill21 ecd

total317 ecd

Requirement: days required

AR report 14 ecd

Dialog re-design 22 ecd

… …

Thread support87 ecd

total317 ecd

Status: Capacity: 317 effective coder-days

Requirement: 317 effective coder-days

Delta: 0 effective coder days

Lecture 3


Non coding time and resource l.jpg
Non-Coding Time and Resource

  • In RP, we explicitly plan coding only.

    • Other

      • types of resources:

        • Testers, documenters, managers

      • phases:

        • Specification, testing

    • These are sized relative to the coding phase and the coding resource

  • Why?

    • Debugged code is the ultimate target

      • Can’t be 90% done on that and still ship intended feature set

    • How much time to devote to documentation?

    • How much time to devote to testing?

    • When is enough, enough?

  • How?

    • Establish ratios

    • Measure what works for ratios for a given product

    • Adjust next time around

    • Converges rapidly

    • Initial guess is usually pretty good

Lecture 3


Resource ratios l.jpg
Resource Ratios

  • Typical ratios I have used

  • Adjust to taste

  • Assumes availability throughout the (overlapping) release cycle.

Lecture 3


Phase length ratios l.jpg
Phase Length Ratios

  • Typical ratios I have used

  • Adjust to taste

Lecture 3


Release overlap l.jpg
Release Overlap

  • Overlapping release cycles smoothes resource utilization

Lecture 3


Shipping the release l.jpg
Shipping The Release

  • After dcut, proactive management is gone.

  • Can only watch defect arrivals and hope for the best.

    • If your ratios are off: forgetaboutit,

Lecture 3


ad