3 Agile Development and Project Planning
Learn how Agile values guide iterative delivery, adaptable planning, estimation, and team workflows, including how Scrum and Kanban support these practices.
Agile values and principles
uses short feedback cycles rather than treating an initial plan as fixed. Teams deliver useful work in increments, learn from users and results, and adjust what they do next. Agile is a set of values and principles, not one required process; Scrum and Kanban are examples of approaches teams may use to put its ideas into practice.
The Agile Manifesto values individuals and interactions, working software, customer collaboration, and responding to change, while recognizing value in processes, documentation, contracts, and plans as well. Its principles emphasize early delivery of value, frequent working software, close collaboration, sustainable pace, technical quality, simplicity, and regular reflection.
Agile does not mean no planning or no documentation. Planning and documentation should support delivery and learning rather than become ends in themselves. For example, a team may document an important interface or security decision while avoiding lengthy specifications for details likely to change.
Iterative delivery and feedback
revisits and improves a solution through repeated cycles. adds usable capabilities in pieces. Together, these approaches allow a team to deliver a small but valuable product improvement, get feedback, and adapt subsequent work.
A typical cycle proceeds through these steps:
Select a valuable, understandable piece of work.
Design, build, and test it to the team’s quality standard.
Integrate it into a working product increment.
Review the result with stakeholders or users.
Use feedback and experience to update priorities and plans.
For example, a team building an online store might first deliver product search, then improve filters after observing how shoppers use it. Each increment should be usable and meet agreed quality expectations; unfinished work is not a completed increment.
Planning and prioritization
Agile planning can happen at several levels. A team may set a product direction and longer-term goals, maintain an ordered list of desired work, and plan more specifically for the next short cycle. Plans become more detailed as work approaches and the team learns more.
A is an ordered, evolving list of work that may contribute to the product. Items near the top should be clear enough to discuss and small enough to complete within a cycle. Prioritization can consider user value, risk, dependencies, cost, and strategic goals; the order is revisited as evidence or needs change.
In Scrum, a is a fixed-length cycle of one month or less. Planning establishes why the is valuable, what work appears feasible, and how the team expects to do it. The team creates a and a plan, then adapts its detailed approach as it learns. Other Agile teams may use continuous flow instead of fixed Sprints.
Estimation and forecasting
Estimation helps a team reason about the relative effort, complexity, and uncertainty of work. Teams may use sizes such as small, medium, and large; story points; or time estimates. A relative estimate compares items within the same team: for example, a task thought to be twice as complex as a familiar task may receive a larger relative size. An estimate is a forecast, not a guarantee.
Estimates are more useful when the team has a shared understanding of the work. Breaking large or uncertain items into smaller pieces can improve that understanding. Teams can compare forecasts with completed work to improve future planning. In Scrum, developers consider factors such as past performance, upcoming capacity, and the team’s when judging how much work may be feasible in a .
—the amount of estimated work completed in a cycle—should not be treated as an individual performance score or a universal comparison between teams. Estimation scales differ, and using estimates as targets can encourage inflated estimates instead of honest learning. When uncertainty is high, a small experiment or a range of possible outcomes may be more useful than a precise-looking number.
Team workflows and Scrum events
An effective workflow makes work visible, limits excessive multitasking, and helps the team deliver completed work regularly. A board might show To Do, In Progress, Review, and Done. The team agrees what each state means and what must be true before work can move forward. In a flow-based approach such as Kanban, the team also controls work in progress so people finish existing work before starting too much new work.
Common Scrum events support a repeating workflow:
Planning: Agree on the and select work the team forecasts it can complete.
Daily Scrum: Developers inspect progress toward the goal and adjust their plan. This is a coordination event, not a status report to a manager.
Review: Inspect the product outcome with stakeholders and discuss what to do next.
Retrospective: Identify practical ways to improve quality and teamwork.
Backlog refinement—clarifying, splitting, and reordering upcoming work—is an ongoing activity, not a formal Scrum event. Across approaches, frequent communication, clear ownership, reliable integration and testing, and a shared support effective teamwork. This shared standard prevents work from being called complete while important quality steps remain.
Bringing the practices together
Agile planning combines direction with adaptability: teams prioritize valuable work, deliver it in small increments, inspect outcomes, and revise plans. Estimation supports forecasting but cannot eliminate uncertainty. Clear workflows, shared quality standards, stakeholder feedback, and regular team reflection help turn short development cycles into steady improvement.