William "RED" Davidson Presentation
54
From Basic to Complete William “RED” Davidson Release Planning
-
Upload
hyperdrive-agile-leadership-powered-by-bratton-company -
Category
Leadership & Management
-
view
401 -
download
0
Transcript of William "RED" Davidson Presentation
From Basic to Complete
William “RED” Davidson
Release Planning
Presentation Backlog
• Why and What of Release Planning
• Basic Release Plans
• Items to Complete a Release Plan
• Suggested Implementation
• Is Release Planning Agile?
Before we do business, I need to know what I’m going to get and when I
will get it.
Agile Planning Onion
Daily
Sprint
Release
Product
Portfolio
Strategy / Vision
A Release Plan is a lightweight strategy to
deliver a solution, determine its probable
completion date(s) and its costs.
Release Planning ProcessProduct Vision
Create the Backlog
Size items in the Backlog
Order the Backlog
Velocity Range
Finalize Release Plan
Mike CohnFixed date, variable scope (most common)-or-Fixed scope, range of dates
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?
Fixed Date, Variable ScopeCapacity: 6 hours
Drive to port 4h 20 minRest stops (2) 20 minPark, check-in 30 minLunch stop at Woody’s BBQ 30 minVisit Sam Houston statue 10 minAntique shopping in Buffalo 30 min
=================================================================================
Will
Maybe
Won’t=================================================================================
• 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
Must Do’s Every Sprint
Deliver Value,Delight
ImproveProduct
Develop the Team & Processes
Jeremy (iOS Customer) wants to … so that…
Begin with the end in mind.
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!
Developing Great Teams
• Team formation.• Ongoing team building.• Working Agreements.• Training.• Cross training.• Knowledge management.• Workforce planning.
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.
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.
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.
Software development is solving unique problems, not the same problem over and over.
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).
Agile Test Pyramid
UI
System
Integration
UnitMore tests, mainly automated.
Fewer tests, generally manual, automated when possible.
Reduce the Time to Customer Availability
Check-in All the worknecessary to make
the product ready for customer consumption.
Zero (impactful) defects.
In use, solving customer’s problems.
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.
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 & StoriesVision
Delivering Customer Value
Desired Outcomes List - Prioritized
Customer’s Desired Outcome Measure
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)
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
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, ourproduct must be “accessible”.
> 60% support, supports with exception or through equivalent facilitation.
FIPS Certification No support this release.
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.
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/
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?
Opened 1955 Opened 1961
Disneyland(year round)
Knott’sBerryFarm
(year round except Christmas)
Six FlagsMagic
Mountain(seasonal,
open 243 daysin 2015)
All 18 Six Flags Parks Worldwide
25.6M
All 12 Disney Parks Worldwide134.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.7M2.8M
Universal Studio
Hollywood(year round)
$48-$95
6.8M
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.
Backlog Contents
• Team development• Process improvements• Product improvements• Customer value• Table stakes• Non-functional requirements• Assumptions, unknowns, dependencies• Fast delivery for fast feedback• Delight!
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.
• 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
Assign Backlog Items to Sprints
Reserve hardening sprints?
• 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 orParticipation
Low Risk orParticipation
50% 80%
Team Confidence
• Release Plan should be aggressive and achievable.• How does the team feel about the plan?
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!
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.
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
In preparing for battle, I have always found that plans are useless but planning is indispensable.
Dwight D. Eisenhower
• 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.
Presentation Backlog
• Why and What of Release Planning
• Basic Release Plans
• Items to Complete a Release Plan
• Suggested Implementation
• Is Release Planning Agile?
