Principles of Product Management: Agile & Scrum (Sprints, Sprint Planning, Daily Stand‑up, Sprint Review, Retrospective)

Agile & Scrum (Sprints, Sprint Planning, Daily Stand‑up, Sprint Review, Retrospective)

Agile & Scrum (Sprints, Sprint Planning, Daily Stand-up, Sprint Review, Retrospective) – Study Guide

What This Is

Agile is a mindset for delivering software incrementally and iteratively, while Scrum is the most popular framework that puts Agile into practice. It matters because it helps teams ship value faster, adapt to change, and reduce waste—critical for modern product development. Example: A fintech startup uses Scrum to launch a new fraud-detection feature in 2-week sprints, testing small increments with real users before scaling.

Key Terms & Frameworks

• Agile Manifesto: 4 values (e.g., "Working software over documentation") + 12 principles (e.g., "Deliver working software frequently").
• Scrum Team: 3 roles:
• Product Owner (PO): Owns the backlog, prioritizes work, and defines "what" to build.
• Scrum Master: Facilitates ceremonies, removes blockers, and coaches the team on Agile.
• Development Team: Engineers, designers, etc. who build the product (typically 5–9 people).
• Sprint: A fixed-length iteration (usually 1–4 weeks) where a "Done" increment is delivered.
• Product Backlog: Ordered list of all desired work (features, bugs, tech debt) managed by the PO.
• Sprint Backlog: Subset of the product backlog selected for the current sprint, plus a plan to deliver it.
• Definition of Done (DoD): Explicit criteria for when a backlog item is complete (e.g., "Code reviewed, tested, deployed to staging").
• Velocity: Average story points completed per sprint (used for forecasting, not a KPI).
• Story Points: Relative measure of effort (not time) for a backlog item (e.g., 1, 2, 3, 5, 8, 13).
• Sprint Goal: A 1–2 sentence objective for the sprint (e.g., "Enable one-click checkout for mobile users").
• Burndown Chart: Visualizes remaining work (y-axis) vs. time (x-axis) in a sprint.
• INVEST (User Stories): Criteria for well-written stories:
• Independent, Negotiable, Valuable, Estimable, Small, Testable.
• Three Pillars of Scrum: Transparency, Inspection, Adaptation.

Step-by-Step / Process Flow

1. Pre-Sprint: Refinement
2. PO grooms the backlog (prioritizes, splits large items, adds details).
3. Team estimates effort (story points) and clarifies acceptance criteria.

4. Action: Run a 1-hour backlog refinement session mid-sprint to prep for the next sprint.

5. Sprint Planning (Start of Sprint)

6. PO presents the sprint goal and top-prioritized backlog items.
7. Team commits to what they can deliver (based on velocity and capacity).

8. Action: Use the Sprint Planning Formula:
   Team Capacity = (Available Devs × Sprint Days) – Planned Time Off – Meetings
   (e.g., 5 devs × 10 days = 50 days; minus 5 days for PTO/meetings = 45 days capacity).

9. Daily Stand-up (15 mins max)

10. Each team member answers:
    1. What did I do yesterday?
    2. What will I do today?
    3. What’s blocking me?

11. Action: Focus on blockers—escalate immediately if unresolved.

12. Sprint Review (End of Sprint)

13. Demo the "Done" increment to stakeholders (e.g., show the new fraud-detection UI).
14. Gather feedback to inform the next sprint.

15. Action: Prepare a 5-minute demo script (e.g., "Here’s how the feature reduces false positives by 20%").

16. Retrospective (After Review)

17. Team discusses:
    1. What went well?
    2. What didn’t?
    3. What to improve?

18. Action: Use the Start/Stop/Continue framework to generate actionable items.

19. Repeat

20. Next sprint starts immediately after the retrospective.

Common Mistakes

• Mistake: Treating the sprint backlog as fixed (e.g., refusing to add/remove items mid-sprint).
  Correction: The sprint goal is fixed, but the backlog can adapt if the goal is at risk. Example: If a critical bug emerges, swap it for a lower-priority item.

• Mistake: Using velocity as a performance metric (e.g., "Team A’s velocity is higher than Team B’s").
  Correction: Velocity is for forecasting, not evaluation. Teams estimate differently, and comparing velocities is like comparing apples to oranges.

• Mistake: Skipping retrospectives or making them a complaint session.
  Correction: Structure retrospectives with data (e.g., burndown charts, cycle time) and action items (e.g., "Try pair programming for complex tasks").

• Mistake: PO dictating "how" to build something (e.g., "Use React for this feature").
  Correction: PO defines the "what" and "why"; the dev team owns the "how."

• Mistake: Stand-ups turning into status updates for managers.
  Correction: Stand-ups are for the team to sync. Managers should observe silently or ask questions afterward.

PM Interview / Practical Insights

1. Tricky Distinction: Sprint Goal vs. Sprint Backlog
2. Interviewer Trap: "Why do you need a sprint goal if you have a backlog?"

3. Answer: The sprint goal is the "why" (e.g., "Improve checkout conversion"), while the backlog is the "what" (e.g., "Add Apple Pay, fix mobile UI bugs"). The goal keeps the team aligned if priorities shift mid-sprint.

4. Stakeholder Pushback: "Why can’t we add this feature mid-sprint?"

5. Answer: Use the Scrum Rule of Thumb:

   
   
   • If the request aligns with the sprint goal, discuss with the team (they may swap it for another item).
   • If it doesn’t align, add it to the backlog for the next sprint.

6. Estimation: Story Points vs. Hours

7. Interviewer Trap: "Why not estimate in hours?"

8. Answer: Story points account for uncertainty and complexity (e.g., a "5-point" story might take 2 days or 2 weeks). Hours encourage micromanagement and ignore team variability.

9. Retrospective Anti-Patterns

10. Interviewer Question: "How do you handle a retrospective where the team blames one person?"
11. Answer: Redirect to systems, not people (e.g., "What process failed that allowed this to happen?"). Use the 5 Whys technique to find root causes.

Quick Check Questions

1. Scenario: Your team’s velocity drops from 50 to 30 points in the last sprint. The CTO asks, "Why is the team slowing down?" How do you respond?
2. Answer: Investigate root causes (e.g., tech debt, unclear requirements, external dependencies) before assuming performance issues. Velocity is a lagging indicator—look at cycle time, burndown charts, and retrospective notes.

3. Why: Velocity fluctuates; blaming the team without data erodes trust.

4. Scenario: A stakeholder demands a new feature be added to the current sprint. The sprint goal is "Improve mobile onboarding," but the feature is unrelated. What do you do?

5. Answer: Politely decline and add it to the backlog for the next sprint. Explain that the sprint goal is fixed, but you’ll prioritize it for the next planning session.

6. Why: Mid-sprint changes risk derailing the goal and team morale.

7. Scenario: During a stand-up, a developer says, "I’m blocked by the API team." What’s your next step?

8. Answer: Escalate immediately to the Scrum Master or PO to unblock them (e.g., "Can we schedule a sync with the API team today?").
9. Why: Blockers left unresolved waste time and delay the sprint.

Last-Minute Cram Sheet

1. Scrum Team = PO + Scrum Master + Dev Team (5–9 people).
2. Sprint = 1–4 weeks; goal is a "Done" increment.
3. Sprint Planning Formula: Capacity = (Devs × Days) – PTO – Meetings.
4. Stand-up 3 Questions: Yesterday, today, blockers.
5. Retrospective Frameworks: Start/Stop/Continue, Mad/Sad/Glad, 5 Whys.
6. Definition of Done (DoD): Explicit criteria for "complete" (e.g., tested, deployed).
7. Velocity = Average story points per sprint (for forecasting, not KPIs).
8. ⚠️ Sprint Goal > Sprint Backlog (goal is fixed; backlog can adapt).
9. ⚠️ Story points ≠ hours (they measure effort + uncertainty).
10. Burndown Chart: Tracks remaining work vs. time (should trend downward).