William "RED" Davidson Presentation AgileCamp 2015

1. From Basic to Complete
William “RED” Davidson
Release Planning

2. Presentation Backlog
• Why and What of Release Planning
• Basic Release Plans
• Items to Complete a Release Plan
• Suggested Implementation
• Is Release Planning Agile?

3. Before we do business,
I need to know what I’m
going to get and when I
will get it.

4. Agile Planning Onion
Daily
Sprint
Release
Product
Portfolio
Strategy / Vision

5. A Release Plan is
a lightweight strategy to
deliver a solution,
determine its probable
completion date(s) and its costs.

6. Release Planning Process
Product Vision
Create the Backlog
Size items in the Backlog
Order the Backlog
Velocity Range
Finalize Release Plan
Mike Cohn
Fixed date, variable scope (most common)
-or-
Fixed scope, range of dates

8. Drive to Galveston
Departing at 8 AM, arrive by 2 PM.
Distance: 305 miles.
Rest stops, stops for lunch, shopping
and site seeing.
Size each and order.
Can we do it all?

9. Fixed Date, Variable Scope
Capacity: 6 hours
Drive to port 4h 20 min
Rest stops (2) 20 min
Park, check-in 30 min
Lunch stop at Woody’s BBQ 30 min
Visit Sam Houston statue 10 min
Antique shopping in Buffalo 30 min
=================================================================================
Will
Maybe
Won’t
=================================================================================

10. • Charter, Elevator Pitch, Product Box, Review, etc.
Focused on customer’s desired outcomes.
Product Vision
• User Stories (Epics) that satisfy the desired
outcomes.
Create the Backlog
• Relative estimation in points by team. Could use
team estimation game or Planning Poker.
Size items in the Backlog
• By value, by size, by risk, some combination.
Order the Backlog
• Historical data, sprint planning of first few sprints.
Velocity Range
• Based on constraints: Fixed Date with Variable Scope
or Fixed Scope over a Date range. Hardening Sprint?Finalize Release Plan

12. Must Do’s Every Sprint
Deliver Value,
Delight
Improve
Product
Develop the
Team & Processes

13. Jeremy (iOS Customer) wants to … so that…
Begin with the end in mind.

14. Create the Backlog
• Team development
• Process improvements
• Product improvements
• Customer value
• Table stakes
• Non-functional requirements
• Assumptions, unknowns, dependencies
• Fast delivery for fast feedback
• Delight!

15. Developing Great Teams
• Team formation.
• Ongoing team building.
• Working Agreements.
• Training.
• Cross training.
• Knowledge management.
• Workforce planning.

16. Making Expectations Explicit
• What is to be delivered?
• How will success be measured?
• Consequences of success or shortfall.
• Constraints and boundaries.
• How will progress be tracked? How often?
When is progress to be made visible?
• Feedback: type, frequency and from whom.
• From the team to the organization: the decision making authority,
knowledge, information and resources needed to be successful.

17. Working Agreements
• Team’s rules & code of conduct.
• Meeting dates, times, locations.
• Core hours.
• Definition of Ready (INVEST).
• Definition of Done (zero defects).
• Code Craftsmanship and
Team’s Coding Standards.
• PO’s expectations for completion
of Sprint Backlog.
• Metrics the team will use.
• Events that trigger Root Cause
Analysis.
• How team handles Production
Support and other interruptions.
• Frequency of team feedback
to/from team members.
• Dedicated time for learning.
• Technical practices such as pairing,
code reviews, test automation,
refactoring.
• How the team celebrates.

18. Dedicated time for team learning, e.g. 1 hour per week:
• Scrum Master to discuss Agile topics.
• Product Owner to discuss customers/competition.
• Team members discussing technical topics.
• Architects to discuss tech trends or cool topics learned at
vendors and conferences.
• UX to discuss Design Thinking.
• Team building activities.

21. Software development is solving
unique problems, not the same
problem over and over.

22. Product and Process Improvements
• Implement retrospective action item(s).
• Reduce number and/or impact of legacy bugs.
• Re-engineer problematic areas.
• Reduce build and test times.
• Reduce or eliminate hardening sprints.
• Implement the Agile Testing Pyramid.
• Implement engineering improvements (e.g. TDD,
continuous integration, automatic regression testing).

23. Agile Test Pyramid
UI
System
Integration
Unit
More tests, mainly automated.
Fewer tests, generally manual,
automated when possible.

24. Reduce the Time to Customer Availability
Check-in All the work
necessary to make
the product ready for
customer consumption.
Zero (impactful) defects.
In use, solving customer’s
problems.

25. Value Stream Mapping
• Understand how the work gets accomplished.
• Reduce or eliminate wait times between steps.
• Reduce or eliminate handoffs and approvals.
• Automate where feasible.
• Measure cycle time and strive to reduce.

26. Measurable
Desired
Outcomes
• Enriches the customer’s life.
• Solves a customer’s problem.
• Generates new revenue for customer.
• Saves the customer time.
• Saves the customer money.
Epics &
Stories
Vision
Delivering Customer Value

27. Desired Outcomes List - Prioritized
Customer’s Desired Outcome Measure

28. Table Stakes / Basics / Minimums
• Application analytics
• Regulatory compliance
• Industry or company standards compliance
• Certifications
• Internationalization, localization
• Installation, upgrade, conversion, rollback
• Backup, restore, disaster recovery
• Release checklists
• Non-functional Requirements (*ilities)

29. Non-Functional Requirements per Wikipedia
• Accessibility
• [Accuracy]
• Audit and control
• Availability (see service level agreement)
• Backup
• Capacity, current and forecast
• Certification
• Compliance
• Configuration management
• Dependency on other parties
• Deployment
• Documentation
• Disaster recovery
• Efficiency (resource consumption for given
load)
• Effectiveness (resulting performance in
relation to effort)
• Emotional factors (like fun or absorbing or
has "Wow! Factor")
• Environmental protection
• Escrow
• Exploitability
• Extensibility (adding features, and carry-
forward of customizations at next major
version upgrade)
• Failure management
• Fault tolerance (e.g. Operational System
Monitoring, Measuring, and Management)
• Legal and licensing issues or patent-
infringement-avoidability
• Interoperability
• Maintainability
• Modifiability
• Network topology
• Open source
• Operability
• Performance / response time (performance
engineering)
• Platform compatibility
• Price
• Privacy
• Portability
• Quality (e.g. faults discovered, faults
delivered, fault removal efficacy)
• Recovery / recoverability (e.g. mean time to
recovery - MTTR)
• Reliability (e.g. mean time between failures
- MTBF, or availability)
• Reporting
• Resilience
• Resource constraints (processor speed,
memory, disk space, network bandwidth,
etc.)
• Response time
• Reusability
• Robustness
• Safety or Factor of safety
• Scalability (horizontal, vertical)
• Security
• Software, tools, standards etc.
Compatibility
• Stability
• Supportability
• Testability
• Usability by target user community
• User Friendliness
en.wikipedia.org/wiki/Non-functional_requirement

30. Nonfunctional Requirements or NFRs or
System Qualities
• The presence or absence of NFRs should be noted.
• Collaboratively written by PO and Development Team.
• NFRs become backlog items or incorporated into the
team’s Definition of Done.
NFR Category Customer or Business Need Measurement
Accessibility For US Government to procure, our
product must be “accessible”.
> 60% support, supports with exception or
through equivalent facilitation.
FIPS Certification No support this release.

31. Assumptions: Product: Run experiment (Lean Startup).
Technical: Define spikes to validate ASAP.
Anything New:
Identify training needs. Define spikes to
learn new technology, tools and
techniques.
Dependencies: Identify and track others whom you
depend on to deliver. And vise versa.

33. Wanted: Fast Feedback!
• Thin vertical slices so you
can deliver to customers
early and often.
• Get feedback to improve
product.
http://www.agileforall.com/2012/01/new-story-splitting-resource/

34. http://www.latimes.com/business/la-fi-disney-parks-reach-capacity-on-
christmas-20141226-story.html
Our highest priority is
to satisfy customers…
But what happens if
you delight them?

35. Opened 1955 Opened 1961

36. Disneyland
(year round)
Knott’s
Berry
Farm
(year round
except Christmas)
Six Flags
Magic
Mountain
(seasonal,
open 243 days
in 2015)
All 18 Six Flags
Parks Worldwide
25.6M
All 12 Disney Parks Worldwide
134.3M
(9 of the top 10 by attendance)
$99 $42-$47 $48-$73
www.teaconnect.org/images/files/TEA_103_49736_150603.pdf
16.8M
3.7M
2.8M
Universal
Studio
Hollywood
(year round)
$48-$95
6.8M

38. see what was possible,
and then take it a step further…
and then a step beyond that.
to give his guests more value than they
expected to receive for their dollar
How to Be Like Walt: Capturing the Disney Magic Every Day of Your Life.

41. Backlog Contents
• Team development
• Process improvements
• Product improvements
• Customer value
• Table stakes
• Non-functional requirements
• Assumptions, unknowns, dependencies
• Fast delivery for fast feedback
• Delight!

42. Identify Minimum Viable Product & Must
Haves (per Jeff Patton)
The minimum viable product is the smallest product release that
successfully achieves its desired outcomes.
The MVP is not the crappiest product
you could possibly release.
• Use Story Mapping when decomposing
desired outcomes into epics and stories.
• Use Buy a Feature to determine what’s really
important to the stakeholders.

43. • Production Support
• Team Learning
• Research for follow-on projects
• Hack-a-thons
• …
• Budget time for each item.
• Older products may need more
time in support.
Dave Ramsey
Velocity Range: Allocate Team’s
Capacity for Ongoing Activities

44. Assign Backlog Items to Sprints
Reserve hardening sprints?

45. • MVP and Musts should consume only 50% to 80% of
the team’s capacity (fixed date):
• If MVP and Musts are >80% of the team’s capacity,
you have a fixed scope project. State the release date
as a range.
MVP and Musts as Percent of Team’s Capacity
High Risk or
Participation
Low Risk or
Participation
50% 80%

46. Team Confidence
• Release Plan should be aggressive and achievable.
• How does the team feel about the plan?

47. Implementing Release Planning
• Use Scrum!
• Gather dedicated team.
• Build backlog of planning items.
• Size each item.
• Order backlog.
• Define completion date range
for planning.
• Go!

48. What Does a Good Release Plan Look Like?
• Customers identified and ready to
contribute.
• You have a backlog.
• Backlog contains customer value,
product & process improvements and
team development.
• Backlog is sized and ordered
(prioritized).
• Backlog items that make up the MVP
and Must Haves identified.
• Velocity determined, either estimated
or from historical data. Capacity
allocated for ongoing activities.
• Number of sprints determined. Some
sprints could be empty for TBD,
emergencies, etc.
• Release date determined.
• Backlog refinement prior to Sprint 1
completed.
• Scrum team believes the Release Plan
is achievable.

50. Release Planning
Does not create working software.
Can avoid release planning when…
• Stable teams.
• Excellent engineering practices and
infrastructure.
• Well understood product, table stakes
and
non-functionals.
• Thin slices of user’s needs.
#NoEstimates
Agile

51. In preparing for battle,
I have always found
that plans are useless
but planning is
indispensable.
Dwight D. Eisenhower

52. • Release Planning generates
knowledge and shared
understanding among
teams and stakeholders.
• Keep Release Planning as lean as possible.
• Stop doing it if it becomes a checklist item.

53. Presentation Backlog
• Why and What of Release Planning
• Basic Release Plans
• Items to Complete a Release Plan
• Suggested Implementation
• Is Release Planning Agile?

54. William “Red” Davidson
PMP PMI-ACP CSM
CSPO ICP-ACC SAFe-SA
reddavidson@yahoo.com
www.linkedin.com/in/reddavidson