Agile and Scrum Fundamentals Questions

Sprint Planning

• PM role: Present the sprint goal, prioritize backlog items, clarify scope and acceptance criteria; collaborate with tech lead to ensure feasibility.
• Preparation: Refine top backlog items, write/confirm user stories and acceptance criteria, estimate priority and dependencies, align on team capacity.
• Artifacts: Sprint goal, prioritized sprint backlog, user stories with AC, capacity/velocity data.
• Effective outcomes: Clear sprint goal, committed backlog within capacity, developers understand acceptance criteria and risks.

Backlog Refinement (Grooming)

• PM role: Continuously ready the backlog—break down epics, reprioritize, answer questions, remove blockers.
• Preparation: Research customer feedback, update business value, draft story splits, identify dependencies and UX/tech needs.
• Artifacts: Refined stories, estimates, priority scores, mockups, links to research.
• Effective outcomes: Consistent pipeline of ready stories (next 2–3 sprints), accurate estimates, reduced clarification during planning.

Sprint Review

• PM role: Showcase value delivered, link increments to business outcomes, collect stakeholder and customer feedback.
• Preparation: Prepare demo script, success metrics, list of questions for stakeholders, invite right participants.
• Artifacts: Demoable increment, acceptance status, metrics/dashboards, release notes.
• Effective outcomes: Stakeholder alignment on shipped value, validated assumptions, prioritized feedback captured for backlog.

Retrospective

• PM role: Participate as collaborator, bring customer/market perspective, avoid dictating solutions; help remove organizational impediments.
• Preparation: Gather data (metrics, incidents), solicit themes from stakeholders, prepare ideas for improvement.
• Artifacts: Actionable improvement items, owner and timeline, incident/metric summaries.
• Effective outcomes: Agreed experiments or actions with owners, measurable improvement next sprint (e.g., fewer blockers, improved cycle time).

Across ceremonies: communicate decisions to stakeholders, keep roadmaps updated, and ensure traceability from customer needs to delivered outcomes.

A pragmatic Definition of Done (DoD) for small iterative features should be short, testable, and focused on reducing rework and release risk. Core items I use as a PM:

• Acceptance criteria met and signed off by PM/PO (clear user-focused scenarios)
• Code merged to main with green CI (linting + unit tests)
• Automated tests: unit + integration for critical paths
• Manual/UX validation: basic exploratory testing + cross-browser checks
• End-to-end smoke test passing in staging
• Feature flag or canary rollout configured for incremental release
• Minimal docs: user-facing help/snippets + short engineering notes (how it’s built, config)
• Monitoring & alerting: key metrics, error logs, and SLOs instrumented
• Accessibility checklist passed for affected screens (keyboard, labels, contrast)
• Release notes and rollback plan

How these items reduce risk and aid maintainability:

• Testing (automated + smoke/manual) catches regressions early, shortens feedback loops, and lowers probability of hotfixes.
• Docs (user and engineering) prevent repeated questions, speed onboarding, and reduce knowledge debt that causes rework.
• Monitoring and alerts give early detection of issues post-release and enable safe incremental rollouts (quickly detect & rollback).
• Accessibility ensures compliance and prevents costly retrofits; it also improves UX and reduces edge-case bugs.
• Feature flags and a clear rollback plan make releases reversible and let teams validate in production with minimal blast radius.

This DoD keeps iterations small, safe to release, and sustainable over time.