Deep Dive into Agile – Agile Practices
This domain, Deep Dive into Agile – Agile Practices, tests practical, comparative knowledge: can you explain how Scrum, Kanban, and XP practices work, select them for a context, and avoid mechanical adoption? The exam favors understanding purpose and mechanics over reciting a single framework.
Core rules and concepts
- Scrum has three accountabilities (Product Owner, Scrum Master, Developers), five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), three artifacts (Product Backlog, Sprint Backlog, Increment), and the Definition of Done. Events exist to create transparency and adaptation.
- Kanban practices include visualizing workflow, limiting WIP, managing flow, making policies explicit, implementing feedback loops, and improving collaboratively. Flow metrics include lead time, cycle time, throughput, and WIP. Little's Law is average cycle time ≈ WIP / throughput.
- XP engineering practices include test-driven development, continuous integration, refactoring, pair programming, small releases, collective code ownership, and sustainable pace.
- Backlog practices include user stories, vertical slicing, acceptance criteria, INVEST, and refinement. The Definition of Done is a quality gate; acceptance criteria are item-specific.
- Estimation practices include relative sizing, planning poker, and flow-based forecasts. Story points are capacity forecasts, not productivity scores; flow-based alternatives use item counts and cycle-time distributions.
Worked example
A team has a 25-day cycle time and a large “ready” column. The coach maps the value stream and finds review waits and stories that are too big. She introduces WIP limits, splits stories vertically, adds a pull policy for review, and tracks a cycle-time scatterplot rather than velocity. Reasoning: the constraint is flow and batch size, not effort; Kanban and XP practices address the system, while Scrum events can still provide inspection.
Traps that cost marks
- Confusing Product Owner and Scrum Master accountability.
- Treating story points as a productivity metric or comparing velocity across teams.
- Using WIP limits as per-person caps rather than pull-system policies.
- Mixing the Definition of Done with acceptance criteria.
- Assuming a scaling framework is plug-and-play; scaling changes dependencies, not just ceremonies.
- Adding practices without removing old ones, creating process debt.