1. On the Spot Actions and Quick Fixes
1.1. 1. Absorb
1.1.1. What to do
1.1.1.1. Absorb the work
1.1.2. Perspective
1.1.2.1. Sprint
1.1.2.2. Non-action
1.1.3. When to apply
1.1.3.1. Occasional occurences
1.1.3.2. Small size
1.1.3.3. Doesn't interrupt flow
1.1.3.4. Doesn't jeopardize sprint goal
1.1.3.5. Adding process costs more
1.1.4. Costs and risks
1.1.4.1. Team may not deliver some items
1.1.4.2. Velocity drops slightly
1.2. 2. Break Up and Carry Over
1.2.1. What to do
1.2.1.1. Complete original item as planned
1.2.1.2. Separate off new requirements as new item
1.2.1.3. Carry over to next sprint
1.2.2. When to apply
1.2.2.1. Size of changes is noticeable
1.2.2.2. Danger to break team's flow
1.2.2.3. Risk of scope creep
1.2.3. Perspective
1.2.3.1. Sprint
1.2.3.2. On the spot
1.2.4. Costs and risks
1.2.4.1. Delayed release of whole feature (initial plus new requirements)
1.2.4.2. PO should set expectations with stakeholders
1.3. 3. Replace
1.3.1. What to do
1.3.1.1. Insert new item
1.3.1.2. Remove item of the same size
1.3.1.3. Put at the top of backlog or plan for next sprint
1.3.2. Perspective
1.3.2.1. Sprint
1.3.2.2. On the spot
1.3.3. When to apply
1.3.3.1. Size of changes is noticeable
1.3.3.2. Rule of thumb: whenever a user story is added
1.3.3.3. May break team's flow
1.3.4. Costs and risks
1.3.4.1. Replaced item is delayed
1.3.4.2. PO should set expectations with stakeholders
1.4. 4. Plan a Buffer
1.4.1. What to do
1.4.1.1. Option 1
1.4.1.1.1. During planning create buffer item
1.4.1.1.2. Subtract from buffer each time new item is added
1.4.1.1.3. If buffer reaches 0, reject new work
1.4.1.1.4. Rejected work goes to backlog
1.4.1.2. Option 2
1.4.1.2.1. Plan for less than avg. velocity
1.4.1.2.2. Absorb new items
1.4.2. When to apply
1.4.2.1. Size of changes is significant
1.4.2.2. Still can achieve sprint goals
1.4.2.3. Rule of thumb: buffer < 20-30% of sprint backlog
1.4.3. Perspective
1.4.3.1. Temporary
1.4.3.2. Quick fix
1.4.4. Costs and risks
1.4.4.1. Slows down roadmap implementation
1.4.4.2. Doesn't fix the root cause
1.4.4.3. Masks real issues
1.4.4.4. Less reliable forecasting
2. Continuous Improvement Actions
2.1. 5. Improve Prioritization
2.1.1. What to do
2.1.1.1. Coach PO
2.1.1.2. Setup prioritization rules
2.1.1.3. Set stakeholders' expectations
2.1.1.4. Agree on meaning and frequency of 'urgent'
2.1.2. When to apply
2.1.2.1. Unplanned items come from PO or stakeholders
2.1.2.2. Urgency of items is often overestimated
2.1.2.3. Items can wait till next sprint
2.1.3. Perspective
2.1.3.1. Product life cycle
2.1.3.2. Fixing root cause
2.1.4. Costs and risks
2.1.4.1. Change of human behavior takes time
2.2. 6. Improve Quality
2.2.1. When to apply
2.2.1.1. Unplanned work mostly consists of bugs
2.2.1.2. Bugs are frequent
2.2.1.3. Bugs affect sprint goals and flow
2.2.2. Perspective
2.2.2.1. Product life cycle
2.2.2.2. Fixing root cause
2.2.3. Costs and risks
2.2.3.1. Fixing quality is harder than building it from start
2.3. What to do
2.3.1. Find causes for low quality
2.3.2. Remove them one by one
2.3.3. Try different strategies
2.4. In rare cases Plan a Buffer may be more economical
2.4.1. Risk that slowdown from poor quality quickly overgrows slowdown from fixing quality
2.4.2. PO should set expectations with stakeholders
2.5. 7. Remove Dependency
2.5.1. What to do
2.5.1.1. Slows down roadmap implementation
2.5.1.2. Increase dependent team's level of ownership
2.5.1.2.1. Share code base
2.5.1.2.2. Delegate responsibilities
2.5.1.2.3. Train
2.5.1.2.4. Set up code review process
2.5.1.2.5. Possibly, lend expert to dependent team
2.5.1.3. Time spent on trainings
2.5.1.4. Time to study new code base
2.5.1.5. Decouple sub-systems
2.5.1.5.1. Look for technological ways to reduce coupling
2.5.2. Perspective
2.5.2.1. Product life cycle
2.5.2.2. Fixing root cause
2.5.3. When to apply
2.5.3.1. Items come from downstream teams
2.5.3.2. Items are blockers for teams where they originated
2.5.4. Costs and risks
2.5.4.1. Effort to implement technological improvements
2.5.4.2. Lending expert
2.5.4.2.1. Drop in velocity for both teams
2.5.4.2.2. Team reforming and risk of conflict
2.6. 8. Adapt the Process
2.6.1. What to do
2.6.1.1. Get rid of iterations
2.6.1.2. Apply Kanban method
2.6.1.3. Try something totally different
2.6.2. When to apply
2.6.2.1. No control over unplanned work
2.6.2.2. Caused by external factors (market, high-level org issues, etc.)
2.6.2.3. Caused by external factors
2.6.2.3.1. Need to adapt to market
2.6.2.4. Caused by internal factors
2.6.2.4.1. Limited control over org-level improvements
2.6.2.4.2. Need to free up time for other improvements
2.6.3. Perspective
2.6.3.1. Avoiding root cause
2.6.3.2. Caused by external factors
2.6.3.2.1. Product life cycle
2.6.3.3. Caused by internal factors
2.6.3.3.1. Temporary
2.6.4. Costs and risks
2.6.4.1. Last resort
2.6.4.2. Team reforming and risk of conflict
2.6.4.3. Drop in velocity
2.6.4.4. If applied incorrectly, masks real issues