43

Popular Agile
Terms -
Explained with
Examples
Agile:

A project management
approach that emphasizes
iterative development,
collaboration, and flexibility.
Example: Scrum and
Kanban are popular Agile
methodologies.
Scrum:
A framework for managing and
organizing work in an Agile
project. It consists of roles
(Scrum Master, Product
Owner, and Development
Team), events (Sprint Planning,
Daily Standup, Sprint Review,
and Sprint Retrospective), and
artifacts (Product Backlog,
Sprint Backlog, and
Increment).
Sprint:
A timeboxed period (usually 1-
4 weeks) during which a Scrum
team works on a set of
prioritized tasks. Example: The
team completed a two-week
sprint and delivered a working
software increment.
User Story:
A concise description of a
software feature or
requirement from the
perspective of an end-user. It
follows the template: "As a
[role], I want [feature], so that
[benefit]." Example: As a user, I
want to be able to search for
products by category, so that I
can quickly find what I'm
looking for.
Product Backlog:
A prioritized list of all desired
features, enhancements, and
bug fixes for a product.
Example: The Product Owner
regularly updates the Product
Backlog based on customer
feedback and market trends.
Sprint Backlog:
A subset of items from the
Product Backlog that the team
commits to completing during
a sprint. Example: The
Development Team pulled user
stories from the Product
Backlog and added them to the
Sprint Backlog for the
upcoming sprint.
Burndown Chart:
A visual representation of the
work remaining in a sprint or
release. It shows the progress
of completed tasks over time.
Example: The team's burndown
chart indicates that they are on
track to complete all planned
work by the end of the sprint.
Kanban:
A visual management system
that helps teams visualize and
track their work. It uses a board
with columns representing
different stages of work (e.g.,
"To Do," "In Progress," "Done").
Example: The team uses a
Kanban board to track tasks,
with sticky notes moving
across columns as work
progresses.
Daily Standup:
A short daily meeting where
team members share progress,
discuss challenges, and plan
their work for the day.
Example: During the daily
standup, each team member
answers three questions: What
did I accomplish yesterday?
What am I working on today?
Are there any obstacles
blocking my progress?
Retrospective:
A meeting held at the end of a
sprint or project to reflect on
what went well, what could be
improved, and identify
actionable items for the next
iteration. Example: The team
conducted a retrospective to
discuss the challenges they
faced during the sprint and
brainstorm ideas for process
improvement.
Velocity:
The rate at which a team
completes work during a
sprint. It is measured by the
number of story points or tasks
completed. Example: The
team's average velocity over
the past three sprints is 20
story points per week.
Epic:
A large user story that cannot
be completed within a single
sprint and needs to be broken
down into smaller, more
manageable user stories.
Example: Building a login
system for a web application
can be an epic, which can be
further divided into user stories
like user registration,
password recovery, and
account settings.
Acceptance Criteria:
The conditions or
requirements that a user story
must meet to be considered
complete and accepted by the
Product Owner. Example: The
acceptance criteria for a user
story about the search
functionality could include
requirements like "Search
results should be displayed
within two seconds" or "Search
should support partial keyword
matches."
Definition of Done:
A shared understanding of the
criteria that must be met for a
user story or task to be
considered done and
potentially shippable. Example:
The team's definition of done
includes code review, unit
testing, functional testing, and
documentation.
Product Owner:
The person responsible for
defining and prioritizing the
product backlog, collaborating
with stakeholders, and
ensuring that the team builds
the right product. Example: The
Product Owner gathers
feedback from users, defines
user stories, and makes
decisions about product
features.
Scrum Master:
The facilitator and servant-
leader for the Scrum team.
They ensure that the team
adheres to Scrum practices,
remove impediments, and
foster an environment
conducive to collaboration and
self-organization. Example:
The Scrum Master helps the
team resolve conflicts and
ensures that the daily standup
is focused and timeboxed.
Development Team:
The self-organizing group
responsible for delivering the
product. It consists of
developers, testers, designers,
and other specialists required
to complete the work. Example:
The Development Team
estimates user stories, breaks
them down into tasks, and
collaborates to deliver high-
quality software.
Sprint Planning:
A meeting where the team and
Product Owner define the
goals and select user stories
for the upcoming sprint.
Example: In the sprint planning
meeting, the team estimates
the effort required for each
user story and commits to
completing a subset of them in
the next sprint.
Sprint Review:
A meeting held at the end of a
sprint to demonstrate the
completed work to
stakeholders and gather
feedback. Example: The team
showcased the new features
developed during the sprint
and received feedback from
the Product Owner and key
stakeholders.
Sprint Retrospective:
A meeting where the team
reflects on the sprint and
identifies what worked well,
what didn't, and actions to
improve in the future. Example:
During the sprint retrospective,
team members discussed the
need for better communication
and agreed to hold more
frequent knowledge-sharing
sessions.
Agile Manifesto:
A set of values and principles
that underpin Agile
methodologies. It emphasizes
individuals and interactions,
working software, customer
collaboration, and responding
to change. Example: The Agile
Manifesto values "Customer
collaboration over contract
negotiation" and "Responding
to change over following a
plan."
Backlog Refinement:
A collaborative activity where
the team and Product Owner
review and update the items in
the Product Backlog. Example:
The team and Product Owner
regularly meet to discuss and
clarify user stories, estimate
their effort, and prioritize them
for upcoming sprints.
Spike:
A time-boxed investigation or
research activity undertaken to
gain knowledge, reduce
uncertainty, or explore
potential solutions. Example:
The team conducted a spike to
evaluate different payment
gateway options before
deciding which one to integrate
into the application.
Continuous Integration:
A development practice where
team members frequently merge
their code changes into a central
repository. It ensures early
detection of integration issues and
promotes collaboration. Example:
The team uses a CI server that
automatically builds and tests the
application whenever changes are
pushed to the repository.
Continuous Delivery:
A practice where software is
continuously tested, integrated,
and made ready for deployment
throughout the development
process. Example: With
continuous delivery, the team can
release new features to
production at any time, as they are
thoroughly tested and meet the
required quality standards.
Burnup Chart:
A visual representation of the
progress of work completed
(burned) over time, along with the
total scope (burned plus
remaining work). Example: The
burnup chart shows that the team
has completed 80% of the total
planned work, and the remaining
work is expected to be finished
within the next two sprints.
Velocity-Based Planning:
A planning approach that uses the
team's historical velocity to
forecast how much work they can
accomplish in future sprints.
Example: Based on the team's
average velocity of 30 story points
per sprint, they can estimate that
they will complete approximately
60 story points over the next two
sprints.
Planning Poker:
A technique used by Agile teams to
estimate the relative effort or
complexity of user stories. Team
members use a set of cards with
different numbers or Fibonacci
sequence values to indicate their
estimation. Example: During
planning poker, team members
assign story points to a user story,
with each person revealing their
estimate simultaneously.
Cycle Time:
The time taken to complete a user
story or task from start to finish. It
includes both active work and wait
times. Example: The team's average
cycle time for user stories is three
days, including development,
testing, and review periods.
Lead Time:
The total time taken for a user story
or feature to go from the initial
request to being completed and
ready for deployment. It includes
wait times and active work periods.
Example: The team's average lead
time for user stories is seven days,
including analysis, development,
testing, and review periods.
Lean:
A philosophy and methodology that
aims to eliminate waste, optimize
value delivery, and maximize
efficiency in the development
process. Example: Lean principles
advocate for minimizing handoffs
and delays between different
stages of the development cycle.
Feature Driven
Development:
An iterative and incremental
software development approach
that focuses on developing features
in short iterations. Example: In FDD,
the development team identifies
features, creates a feature list, and
plans and executes iterative feature
delivery.
Story Points:
A unit of measurement used to
estimate the effort or complexity of
user stories. It represents the
relative size of work rather than
specific time durations. Example:
The team assigned five story points
to a user story they estimated as
being twice as complex as a three-
point story.
WIP Limit:
A constraint on the maximum
number of items that can be
simultaneously worked on in a
particular stage of the development
process. It helps prevent
bottlenecks and promotes flow.
Example: The team has set a WIP
limit of three user stories in the "In
Progress" column on their Kanban
board.
Increment:
A new version or release of the
product that includes the features
completed during a sprint. It should
be in a potentially shippable state.
Example: At the end of the sprint, the
team delivered an increment that
included new search functionality,
user registration, and product listing
features.
Definition of Ready:
A set of criteria that a user story
must meet before it can be
considered ready to be worked on
by the team. Example: The team's
definition of ready includes clear
acceptance criteria, estimated
effort, and any necessary
dependencies or designs.
MoSCoW:
A prioritization technique used to
categorize requirements or user
stories into four categories: Must
have, Should have, Could have, and
Won't have (this time). Example: The
Product Owner and team used the
MoSCoW technique to prioritize
user stories for the next sprint.
Technical Debt:
The accumulated cost of shortcuts
or suboptimal design and
development decisions made during
the software development process.
Example: The team decided to
refactor a part of the codebase
affected by technical debt to
improve maintainability and
performance.
Product Roadmap:
A strategic plan that outlines the
vision, goals, and key milestones for
a product over time. Example: The
product roadmap includes features
like mobile app support, integration
with third-party services, and
enhanced reporting capabilities
planned for the next six months.
Minimum Viable Product:
A version of a product with the
minimum set of features required to
meet the needs of early adopters
and gather feedback for future
iterations. Example: The team
focused on developing the core
functionalities of the product for the
MVP release, deferring non-
essential features to subsequent
iterations.
Agile Coach:
An experienced professional who
provides guidance and support to
teams and organizations
transitioning to Agile
methodologies. Example: The Agile
Coach facilitated workshops,
provided training sessions, and
coached teams on Agile practices
and principles.
Test-Driven Development:
A development approach where tests
are written before the corresponding
code is implemented. It promotes
code quality, encourages modular
design, and ensures that all
requirements are covered by tests.
Example: The team practiced TDD by
writing failing tests for a specific
feature, implementing the necessary
code, and then running the tests to
validate its functionality.
Test-Driven Development:
A development approach where tests
are written before the corresponding
code is implemented. It promotes
code quality, encourages modular
design, and ensures that all
requirements are covered by tests.
Example: The team practiced TDD by
writing failing tests for a specific
feature, implementing the necessary
code, and then running the tests to
validate its functionality.
Thank You