Introduction
Agile delivery is the daily work of turning intent into shipped, valuable software. It is the planning, the estimation, the daily synchronization, and the disciplined practices that make iterative work predictable enough for stakeholders to plan around. Without these mechanics, agility quickly slides into wishful thinking.
Delivery sits between strategy and engineering. Strategy says what is worth building; engineering says how it gets built; delivery is the connective tissue that turns one into the other through estimation, planning, sprint cadence, and a steady drumbeat of inspection and adaptation. The practices below are framework-agnostic — they work inside Scrum, Kanban, Scrumban, or any blend a team chooses.
Topics
Agile Roadmaps vs. Gantt Charts
Outcome-driven, time-flexible plans that communicate direction without committing to dates the team cannot honor.
Read →Release Planning
Coordinating multi-sprint efforts across teams and stakeholders without freezing scope into a fixed-date contract.
Read →Dependency Mapping
Surfacing the cross-team links that quietly determine whether a release ships on time, before they become blockers.
Read →Time-Based Estimates
When and why teams might estimate in hours or days, and where it breaks down for complex work.
Read →Planning Poker
A relative estimation technique that uses simultaneous reveal to surface assumptions rather than anchor on the loudest voice.
Read →Roman Estimation
A fast thumbs-up / thumbs-down / thumbs-sideways read for proposed work, used early to triage before serious sizing.
Read →NoEstimates Exploration
Skipping estimation entirely and forecasting from throughput and cycle time. What it solves and what it asks of the team.
Read →Definition of Ready
A shared bar for what counts as ready to start, used to keep half-formed work out of the sprint without becoming a stage gate.
Read →Sprint Planning Structures
Patterns for running planning — goal-first, capacity-first, swarm-style — and which fits which team maturity.
Read →Timeboxing
Using fixed-duration containers to force decisions, surface progress, and protect against work expanding without limit.
Read →Daily Scrum Techniques
Formats that go beyond the three questions — flow-based, swarming, blocker-first — and when each helps.
Read →Definition of Done
A shared bar for what counts as finished. The single most leveraged agreement a team makes.
Read →Done-Done Definition
Extending Definition of Done past the sprint boundary — what it means for a feature to be truly shipped, not just merged.
Read →Definition of Awesome
A UX quality bar layered on top of Definition of Done so polish does not get deferred indefinitely.
Read →Incremental Release Practices
Releasing thin slices of value continuously rather than batching features into infrequent big releases.
Read →Review & Showcase Techniques
Making sprint reviews into real feedback loops with stakeholders rather than status meetings dressed up as demos.
Read →Retrospectives
A short intro and link to the deeper Retrospective Techniques hub for formats, anatomy, and common pitfalls.
Visit hub →Where to Start
Most delivery problems start at the seams — between intent and ready work, between commitment and capacity, between done and shipped. Definitions of Ready and Done are the cheapest, highest-leverage agreements a team can make: they convert hidden disagreement into explicit shared standards. Forecasting and estimation choices come next, depending on whether predictability or speed of decision matters more in the team's context.
The deeper any team goes into delivery practice, the more it converges with technical practice, flow, and retrospective culture. Improvements in one area surface limits in another — tighter cycles expose technical debt, better forecasting reveals planning waste. Treat the list above as connected, not independent.
Back to Hubs