Playbooks

The #1 reason Agile fails isn't the framework — it's the execution. Teams adopt ceremonies without understanding the principles behind them. They run standups as status meetings. They treat sprints as mini-waterfalls. The Agile Execution Playbook fixes this by focusing on the behaviors that actually drive delivery velocity.

Sprint planning isn't about filling a sprint with as many stories as possible. It's about making a deliberate commitment as a team. Start with capacity. Subtract PTO, meetings, and support burden. Only then pull stories in priority order. Each story needs clear acceptance criteria and a shared understanding — not just the PO's interpretation. Key practices: - Use Planning Poker only for stories with genuine uncertainty - Time-box planning to 2 hours for a 2-week sprint - Leave 15-20% buffer for unplanned work - Every story must have a Definition of Done before entering the sprint

If your standup is a round-robin status report, you're doing it wrong. Effective standups are about coordination, not reporting. The format that works: - Walk the board right-to-left (focus on getting things DONE) - Call out blockers immediately — don't wait for your 'turn' - Identify pairing opportunities - Flag scope creep early Keep it under 10 minutes. If it's taking longer, your sprint has too many items or too many people.

The most valuable ceremony in Agile is the retrospective — if you actually follow through on the action items. Frameworks that work: - Start/Stop/Continue for new teams - 4Ls (Liked, Learned, Lacked, Longed For) for mature teams - Timeline retrospective for complex sprints Critical rule: Pick max 2 action items. Assign owners. Track them in the next sprint. If you're not tracking retro actions, you're just venting.

Stop obsessing over velocity. It's a planning tool, not a performance metric. Metrics that actually improve delivery: - Cycle Time: How long from 'In Progress' to 'Done'? - Sprint Goal Achievement: Did you hit the goal, not just the points? - Sprint Spillover Rate: What % of committed work carries over? - Defect Escape Rate: How many bugs reach production? Track trends, not absolutes. A team improving their cycle time by 10% per quarter is winning.

A sprint without a goal is just a to-do list. The Sprint Goal gives the team a north star — it's the one thing that must be true by the end of the sprint. Good sprint goals are: - Outcome-focused ('Users can complete checkout without errors') - Achievable within the sprint - Valuable to the customer or business - Not just a list of stories rephrased Every decision during the sprint should be filtered through: 'Does this help us achieve the sprint goal?'

Capacity planning is the foundation of sprint predictability. Most teams skip this and wonder why they keep over-committing. The formula: 1. Calculate total available hours per person 2. Subtract planned meetings, support rotation, and PTO 3. Apply a focus factor (typically 60-70% for productive coding) 4. Map story points to capacity hours using historical data Do this for 3 sprints and you'll have a predictable baseline.

Work in Progress limits are the single most effective practice for improving throughput. Counter-intuitive but true: doing less work simultaneously means finishing more work total. Implementation: - Start with WIP limit = team size - 1 - Apply WIP limits per column on your board - When a column is at capacity, swarm on existing work - Exception: only break WIP for production incidents Teams that adopt WIP limits typically see 30-50% improvement in cycle time within 4 sprints.

The Sprint Review is your team's chance to shine — and to get real feedback. Don't waste it with slide decks. Format: - 5 min: Sprint Goal recap and achievement status - 20 min: Live demo of working software (not staging — production) - 10 min: Stakeholder Q&A and feedback - 5 min: What's next sprint preview Rules: - Only demo 'Done' items (per DoD) - Let the developers demo their own work - Record feedback as actionable backlog items - Share the recording with absent stakeholders

Every project has risks. The question is whether you identify them before or after they become problems. The best PMs I know spend 10% of their time on risk management — identifying, assessing, and planning mitigations. The worst PMs spend 40% of their time firefighting the risks they didn't see coming. Risk management isn't about preventing all bad things. It's about ensuring no bad thing catches you completely by surprise.

Run this 60-minute session at the start of every project and quarterly for ongoing programs: 1. Brainstorm (15 min): Every team member writes risks on sticky notes. No filtering. 2. Categorize (10 min): Group by type — Technical, Resource, Schedule, External, Organizational 3. Assess (20 min): Rate each risk on Probability (1-5) and Impact (1-5). Multiply for Risk Score. 4. Prioritize (15 min): Focus on scores > 12. Assign owners. Define mitigations. Output: A prioritized risk register with owners and planned responses.

For each high-priority risk, choose one of four strategies: - AVOID: Change the plan to eliminate the risk entirely. Best for high-probability, high-impact risks. - MITIGATE: Take action to reduce probability or impact. Most common strategy. - TRANSFER: Shift the risk to a third party (vendor, insurance, outsourcing). - ACCEPT: Acknowledge the risk and prepare a contingency plan. Use when cost of mitigation exceeds potential impact. Document the chosen strategy, specific actions, and trigger conditions for each risk.

Clear escalation paths prevent risks from festering: Level 1 (Team): Risks with score < 8. Team lead owns mitigation. Level 2 (PM): Risks with score 8-15. PM coordinates cross-team mitigation. Level 3 (Steering): Risks with score > 15. Requires executive sponsorship and resource allocation. Level 4 (Emergency): Active risks threatening launch date or budget. War room protocol. Escalation is not failure — it's responsible communication. Escalate early, escalate with data.

Stakeholder management is 80% communication and 20% management. The formula: Trust = Consistency x Transparency x Competence - Consistency: Send status updates on the same day, same time, same format. Never miss one. - Transparency: Share bad news early with a plan. Never hide risks. - Competence: Show you understand the domain, not just the process. One missed update or one hidden risk can destroy months of trust.

Every status report should answer 5 questions in under 2 minutes of reading: 1. Are we on track? (RAG status with one-line explanation) 2. What did we deliver? (Completed items with business value) 3. What's blocked? (Blockers with required action and owner) 4. What's coming next? (Next sprint/milestone focus) 5. Do you need anything from us? (Clear asks with deadlines) Format: One page max. Use color coding. Lead with the headline. Put details in appendix.

Bad news doesn't get better with age. Here's the framework: 1. Lead with the impact: 'The launch date is at risk of slipping 2 weeks.' 2. Explain the cause: 'Third-party API integration revealed undocumented rate limits.' 3. Present your plan: 'We've identified 3 options with tradeoffs...' 4. State your recommendation: 'I recommend Option B because...' 5. Ask for decision/support: 'I need your decision by Thursday to keep the revised timeline.' Never deliver bad news without a plan. Never deliver it by email alone — call first, then follow up in writing.

When a stakeholder asks for the impossible: 1. Acknowledge the desire: 'I understand the business pressure to launch by Q2.' 2. Present the data: 'Based on current velocity, we can deliver Features A-D by Q2, or A-F by Q3.' 3. Offer options: 'We could hit Q2 by descoping F and G, or by adding 2 engineers for 6 weeks.' 4. Let them choose: 'Which trade-off works best for the business?' Never say 'we can't.' Always say 'here's what we can do, and here's the trade-off.'