Terms in Agile Fundamentals

Get familiar with the core Agile concepts from the manifesto to daily ceremonies.

min

exercises

Upd. on

Mar 2, 2026

Start lesson quiz

Agile transformed how teams build products by replacing rigid waterfall processes with flexible, iterative development. Born from frustration with slow delivery and outdated requirements, 17 software developers gathered in 2001 to define better ways of working. They created principles emphasizing customer collaboration, working software, and responding to change over following fixed plans. These foundational ideas shaped frameworks like Scrum that help teams deliver value faster through short cycles called sprints. Teams break work into small pieces, meet daily to stay aligned, and reflect regularly on how to improve. This approach has spread beyond software to marketing, operations, and other fields because the core principles work anywhere people collaborate on complex projects. Understanding these fundamentals helps you participate effectively in product discussions and Agile ceremonies.

Agile manifesto

The Agile Manifesto is a declaration created by 17 software developers in February 2001 at a Utah ski resort. They were seeking alternatives to complicated, documentation-heavy development processes that failed to meet changing business needs. The manifesto states 4 values:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan^[1]

The manifesto doesn't reject processes, tools, documentation, contracts, or plans. Instead, it acknowledges these have value while emphasizing that people, working software, collaboration, and adaptability matter more. The manifesto became the foundation for Agile methodologies worldwide, extending far beyond software development to marketing teams, operations groups, and even nonprofit organizations. Its universal appeal comes from addressing fundamental collaboration challenges that exist across industries.^[2]

Agile mindset

Agile mindset refers to the attitudes and beliefs teams hold about how work should be done, going beyond simply following Agile practices. Teams can implement daily standups, sprints, and retrospectives, yet still operate with a waterfall mentality if they resist change, hide problems, or prioritize plans over reality. The mindset emerges when teams genuinely embrace the manifesto's values in their daily decisions and interactions.

This mindset manifests in how teams respond to challenges. When requirements change late in development, teams with an Agile mindset ask how the change improves customer value rather than defending the original plan. When problems surface, they share them immediately instead of hiding issues until status meetings. When choosing between perfect documentation and working software, they build first and document what's actually needed.

The mindset creates psychological safety where teams can experiment, fail fast, learn quickly, and adapt based on real feedback rather than assumptions. Understanding this distinction helps explain why some teams succeed with Agile while others struggle despite using the same frameworks.^[3]

Agile principles

The 12 Agile principles provide detailed guidance for applying the four Agile values in daily work. These principles describe a culture where change is welcome and customer needs drive decisions. The principles are:

Satisfy customers through early and continuous delivery of valuable software
Welcome changing requirements, even late in development
Deliver working software frequently, from weeks to months
Business people and developers must work together daily
Build projects around motivated individuals and trust them
Face-to-face conversation is the most efficient communication method
Working software is the primary measure of progress
Agile processes promote sustainable development at a constant pace
Continuous attention to technical excellence and good design enhances agility
Simplicity, maximizing the amount of work not done, is essential
Best architectures, requirements, and designs emerge from self-organizing teams
Teams regularly reflect on how to become more effective and adjust their behavior

Together, these principles shape how Agile teams plan, execute, and continuously improve their work. They emphasize customer value, adaptability, collaboration, technical quality, and regular reflection.^[4]

Pro Tip! When stakeholders request late changes, ask "how does this improve customer value?" rather than resisting. This turns disruptions into conversations about priorities and trade-offs.

Agile framework

An Agile framework is a structured approach that applies Agile values and principles to organize how teams work. Different frameworks emerged as teams experimented with various implementations of Agile thinking:

Scrum organizes work into fixed-length sprints with defined roles and ceremonies.
Kanban visualizes workflow and limits work in progress to improve flow.
Extreme Programming focuses on technical practices like pair programming and test-driven development.
Lean emphasizes eliminating waste, optimizing the whole system, and delivering value as fast as possible.

These frameworks share common elements like iterative development, frequent delivery, and continuous improvement, but implement them differently based on specific contexts and challenges. Some teams use frameworks exactly as designed, while others adapt elements to fit their situation. The key is maintaining alignment with Agile values and principles rather than rigidly following any specific framework. Organizations adopting Agile often start with one framework, then evolve their approach based on what works for their teams and products.^[5]

Daily scrum

The daily scrum is a 15-minute meeting held at the same time and place each workday during a sprint. The development team uses this brief synchronization to inspect progress toward the sprint goal and adapt their plan for the next 24 hours. Each team member typically shares what they accomplished since the last daily scrum, what they plan to accomplish before the next one, and what obstacles might prevent progress.

This meeting exists to identify blockers quickly and maintain team alignment, not to provide status reports to managers. The timebox forces concise updates and prevents problem-solving discussions that should happen separately. Teams often stand during the meeting to reinforce keeping it short. The daily scrum helps teams catch issues early, coordinate dependencies between members, and maintain momentum throughout the sprint. When done well, it creates transparency about progress and allows rapid responses to emerging challenges.^[6]

Sprint planning

Sprint planning is a collaborative meeting where the team decides what work to accomplish in the upcoming sprint and how they will complete it. The product owner presents prioritized backlog items while team members ask questions to understand requirements. The team then estimates effort for each item and determines their capacity based on availability, vacations, and other commitments. The meeting produces two key outputs: a sprint goal that provides focus and a sprint backlog containing selected items broken into tasks. Teams use various estimation techniques, like story points or hours, to gauge how much work fits in the sprint.

The goal is reaching a realistic commitment that the team feels confident achieving, not identifying every possible task or creating perfect estimates. Effective sprint planning balances thoroughness with efficiency, typically lasting about 45 minutes per week of sprint length. This planning creates shared understanding and alignment before development work begins.^[7]

Pro Tip! Track velocity for 3 sprints before using it for planning. Until then, commit to less than you think possible and build confidence through successful delivery.

Backlog refinement, previously called backlog grooming, is the ongoing process of reviewing, updating, and preparing product backlog items for future sprints. The product owner and development team regularly examine backlog items to ensure they are appropriately detailed, estimated, and prioritized. This continuous activity keeps the backlog current and aligned with customer and business needs rather than letting it become an overwhelming, outdated list.

During refinement sessions, teams remove irrelevant stories, create new ones based on discovered needs, split large stories into smaller pieces that fit within sprints, add acceptance criteria, and estimate effort for upcoming items. Near-term items receive detailed specifications with complete user stories and development estimates, while longer-term items remain more general to avoid wasted effort on work that might change. Effective refinement makes sprint planning faster and more efficient because the team has already discussed questions and clarified requirements for top-priority items.^[1][2]

Pro Tip! Schedule refinement for three days before sprint planning ends. This gives the product owner time to resolve any issues the team identifies without delaying the next sprint start.

Sprint review

The sprint review is a collaborative meeting held at the end of each sprint where the team demonstrates completed work to stakeholders and gathers feedback. Unlike a formal presentation, this working session focuses on inspecting the product increment and adapting plans based on what was accomplished and what changed in the environment. The product owner explains which backlog items are done, developers discuss what went well and what problems arose, and the team demonstrates working software.

Stakeholders provide feedback that helps shape future work, and the product backlog may be adjusted to meet new opportunities or address concerns raised during the review. The sprint review is timeboxed to a maximum of 4 hours for a one-month sprint, typically shorter for shorter sprints. This meeting differs from the retrospective because it examines the product itself rather than team processes. The sprint goal provides context for the demonstration, helping stakeholders understand the sprint's objective and evaluate whether the increment moves the product closer to its overall goals.^[8]

Pro Tip! Keep reviews informal without extensive preparation. Teams spending hours creating presentation slides miss the point. Demonstrate working software and focus on conversation, not polish.

Definition of ‘done’

The definition of ‘done’ is a shared understanding of what "complete" means for product backlog items and increments. This checklist ensures consistent quality standards across all work the team delivers. Common criteria include:

Code written and reviewed
Tests passing
Documentation updated
Acceptance criteria met
Deployment to production or staging environments

Without a clear definition, team members might have different interpretations of when work is finished. The definition of ‘done’ provides transparency for stakeholders about what they can expect from completed work. It helps teams avoid accumulating technical debt by ensuring quality standards are met before declaring items finished. The Scrum team creates and maintains this definition, adapting it as needed when they discover gaps or want to raise quality standards. During sprint planning, the team considers the definition when estimating how much work fits in the sprint. During the sprint review, only items meeting the definition of done are demonstrated to stakeholders.^[1][2]

Pro Tip! Review your definition of done quarterly. As team skills improve and tooling advances, raise standards by adding more rigorous quality checks to push continuous improvement.

Retrospective

The retrospective is a meeting held at the end of each sprint where the team reflects on how they worked together and identifies improvements for the next sprint. Unlike other Scrum meetings focused on the product, retrospectives examine the team's processes, tools, interactions, and Definition of Done. The team discusses what went well, what problems arose, and how issues were or were not resolved.

This meeting cultivates continuous improvement by creating dedicated time for reflection and adaptation. Teams often use techniques like start-stop-continue, where they identify practices to begin, practices to eliminate, and practices to maintain. The most impactful improvements get added to the next sprint backlog as action items. Successful retrospectives require psychological safety where team members feel comfortable sharing honest feedback without fear of blame. The Scrum Master facilitates ensuring productive discussion while the entire team, including the product owner, participates and commits to improvements.^[1][2]

Pro Tip! Use the "5 whys" technique when identifying problems. Ask "why" 5 times to get past symptoms and find root causes that the team can actually fix.