Key Components of an Agile Project:

PRODUCT INITIATION (PROJECT BACKLOG)

 Product Backlog or list of requirements or features are compiled from inputs from
Stakeholders, Customers and Users
 Project is Approved
 Product Backlog is prioritized
 Cross functional team is established to work on the backlog
 Product Owner is introduced to ensure the prioritization of the backlog and is
responsible for the return on investment

SPRINT PLANNING (SPRINT BACKLOG)

 During Sprint Planning, user stories are selected from the Project Backlog and added
to the Sprint Backlog.
 Sprint Backlog is prepared with entire team detailing the time it will take to do the
work and agreeing on how much can be done during the sprint

DAILY SCRUM
 Daily Scrum Meeting is held each day during a sprint
 Guidelines for the daily scrum:
o All members of team come prepared with updates
o Meeting starts on time even if some members are missing
o Meeting should happen at the same location and same time each day
o Meeting length should be limited to 15 minutes or less
o Each team member answers three questions:
 What have you done since yesterday?
 What are you planning to do today?
 Are there any impediments preventing you from moving forward?
o No detailed discussions should occur at this meeting.

SPRINT REVIEW (DEMO)

 Carried out at the end of each sprint
 Team members show or demonstrate what they have completed
 Product Owners and Stakeholders provide feedback; it is up to the Product Owner do
determine if the work product is acceptable and can be released to Production.
 Product Backlog and burndown chart are updated
SPRINT RETROSPECTIVE
 Occurs after the sprint review
 Team members discuss what went well and what needs to improve with regard to the
people, relationships, processes and tools
 Possible improvements are identified and agreed upon for the next sprint

A
ACCEPTANCE TESTS
Details the user's expectations and provides guidance to developers on how to handle different
situations or conditions. The acceptance tests are written from the user's point of view and may
take the form “given <a condition or context>, when I do <event>, then <outcome>”. Each user
story typically has multiple acceptance tests. Rather than writing detailed requirements and
acceptance tests, the acceptance tests are used to flesh out the details of the user story.

AGILE MANIFESTO
The origin of agile development methodologies. Crafted in 2001 by several software
developers, the manifesto stresses the importance of individuals and interactions over
processes and tools; working software over comprehensive documentation; customer
collaboration over contract negotiation; and responding to change over following a plan.

AGILE TEAM
The collaborative team comprised of the product owner, the scrum master, business analyst
and the delivery team.

B
BACKLOG
A product backlog (PBL) is a collection of prioritized high-level requests (also known as
requirements) of work to be done. A backlog entry may have many associated child user
stories or it may be concise enough to transition into a full detailed user story. It is often used
to create the features list when first beginning a project. A Sprint backlog (SBL) is a prioritized
list of tasks to be completed during the sprint.

BACKLOG GROOMING
An ongoing process whereby the product owner and/or customer manages the product backlog
based on information gathered in the feedback cycles inherent to agile practices. The activities
of backlog grooming can include: adjusting rank; breaking down stories that are going to be
worked on in the next few iterations; creating new stories; updating existing stories; deleting
obsolete stories; elaborating acceptance criteria.

BURNDOWN
A type of chart that shows work remaining over time. It is useful for predicting when all of the
work will be completed. Outstanding work can be represented in terms of either time or story
points.

C
CHILD STORY
A user story that represents the breakdown of a large feature or initiative into a smaller
segment. Only the lowest-level child story in a user story hierarchy can be scheduled into an
iteration or release.

CONTINUOUS FLOW
A type of software methodology that allows new code to be released as soon as it is finished,
instead of holding to a defined release schedule. See also Lean.

CONTINUOUS INTEGRATION
A software development practice where members of a team integrate their work frequently;
usually each developer integrates their code into the code base at least daily.
D
DoD (DEFINITION OF DONE)
List of development activities required to consider an increment of functionality as “Done”. The
exit-criteria to determine whether a product backlog item is complete. In many cases the DoD
requires that all regression tests should be successful.

E
EPIC STORY
A user story that represents a large feature or set of work, which is further defined by related
child stories. Parent stories cannot be scheduled into an iteration or release, as they are
considered too large. Synonymous with parent story.

F
FEATURE
Product or system features are high-level expressions of desired system behavior, a direct
representation of a customer or stakeholder’s request, that can be developed in a PSI
(Potentially Shippable Increment) or release timebox (usually 10-12 weeks).

H
HARDENING SPRINT
Sprint(s) which is planned to be added to the end of the project to implement defect fixes or
feature refinements.

I
IDEAL DAY
An estimation unit that considers the time it would take to complete a task without interruptions.

ITERATION
The terms iteration and sprint are used synonymously. An Iteration is a single complete
development timebox of requests to be worked on and accepted usually resulting in an internal
release. An Iteration produces intermediate deployable code that has been discussed,
designed, implemented and tested. Each Iteration is a subset of the final product under
development and builds on the functionality of the prior Iteration. The Iterations grow
incrementally to become the final system. A Project can contain one or many Iterations.

K
KANBAN
System of tracking work across various stages of development with an emphasis on just-in-time
delivery while not overloading the team members. In this approach, the process, from definition
of a task to its delivery to the customer, is displayed for participants to see and team members
pull work from a queue. Work is represented by cards, and stages are represented by columns
on a board. A card is moved to the next column when it enters the next stage. Refer to Lean.

L
LEAF NODE
Refers to any user story that has no children.

LEAN
Software development practices adapted from the Lean Manufacturing principles developed by
Toyota. The focus of Lean methodology is to eliminate waste, amplify learning, decide as late
as possible, deliver as fast as possible, build integrity, empower the team, and see the whole.
One may practice Lean by utilizing the Kanban method of agile development.

M
MoSCoW
An acronym used to prioritize work, and/or aspects of a particular feature. Stands for must
have, should have, can have, and won't have. May be used to define the acceptance criteria of
a user story.
P
PARENT STORY
A user story that represents a large feature or set of work, which is further defined by related
child stories. Parent stories cannot be scheduled into an iteration or release, as they are
considered too large. Synonymous with epic story.

PLANNED VELOCITY
The total number of story points (or other unit type) the team estimates they can complete
within an iteration or release. This value is also known as available resources. This total can be
estimated by averaging the total number of story points successfully completed in past
iterations or releases.

POINTS
Points or story points are the most common unit of measure used to estimate the relative size
and complexity of user stories in agile development. If one user story is 1 point and another is
2 points then the 2 point user story is expected to take twice as much effort to develop as the
first.

PREDECESSOR
Any user story that must be completed before another user story can start or finish.

PRODUCT BACKLOG
A prioritized list of functional and non-functional requirements for a system or product.

PRODUCT OWNER
A role on an agile delivery team that is responsible for collecting and ranking business
requirements on the product backlog. A product owner does not manage a delivery team, but
communicates what must be built in the next release or iteration. In exchange for the team's
commitment to finish the top-most ranked work in an iteration, the product owner agrees to
protect the team from any changes in requirements during the iteration.

PSI
Potentially Shippable Increment. A timebox, usually 10 weeks, in which a PSI of features is
developed.

R
RANK
An attribute of a work product that describes its importance for a release or iteration.

RELEASE
A timebox where work occurs in support of an internal or external delivery of a working, tested
version of the system or software. In scrum, a release consists of multiple iterations or sprints to
deliver new system code.

RETROSPECTIVE
Also referred to as Sprint Retrospective. Conducted after the sprint review where the team
discusses what went well and what needs to improve with regard to the people, relationships,
processes and tools. The Scrum team identifies possible improvements and agrees on
measures for the next sprint.

S
SCRUM
An iterative and incremental agile software development framework for managing software
projects and product or application development. Scrum enables teams to self-organize by
encouraging physical co-location or close online collaboration of all team members and daily
face to face communication among all team members and disciplines in the project. A key
principle of Scrum is its recognition that during a project the customers can change their minds
about what they want and need (often called requirements churn), and that unpredicted
challenges cannot be easily addressed in a traditional predictive or planned manner. As such,
Scrum focuses on maximizing the team's ability to deliver quickly and respond to emerging
requirements.
SCRUM OF SCRUMS
The Scrum of Scrums (meeting) is a technique to scale Scrum up to large development groups
(over a dozen people), which allows clusters of teams to discuss their work, focusing especially
on areas of overlap and integration. Each daily scrum within a sub-team ends by designating
one member as an "ambassador" to participate in a daily meeting with ambassadors from other
teams, called the Scrum of Scrums.

Resolution of impediments is expected to focus on the challenges of coordination between the

teams, and may entail agreeing to interfaces between teams, negotiating responsibility
boundaries, etc. The Scrum of Scrums will track these working items via a backlog of its own,
where each item contributes to improving between-team coordination.

SCRUM MASTER
The person responsible for the Scrum process, making sure it is used correctly and maximizing
its benefits.

SCRUM MEETING
May be referred to as a daily standup. A brief meeting held between the delivery team, product
owner, and scrum master. While everyone stands (to keep the meeting from running long) each
team member reports on what work they did yesterday, what they plan to do today, and alerts
the scrum master of any impediments or issues that may be blocking them.

SPIKE
A time boxed period used to research a concept and/or create a simple prototype. Spikes can
either be planned to take place in between sprints or, for larger teams, a spike might be
accepted as one of many sprint delivery objectives. Spikes are often introduced before the
delivery of large or complex product backlog items in order to secure budget, expand
knowledge, and/or produce a proof of concept. The duration and objective(s) of a spike will be
agreed between the Product Owner and Delivery Team before the start. Unlike sprint
commitments, spikes may or may not deliver tangible, shippable, valuable functionality. For
example, the objective of a spike might be to successfully reach a decision on a course of
action. The spike is over when the time is up, not necessarily when the objective has been
delivered.

SPRINT
Synonymous with iteration. A time period (typically 1–4 weeks) in which development occurs
on a set of backlog items that the team has committed to. Also referred to as a timebox.

SPRINT REVIEW
Carried out at the end of each sprint where each member shows what he has completed,
receives feedback from the Product Owner and Stakeholders and the Product Backlog and
burndown chart are updated.

SPRINT ZERO
A sprint which occurs at the onset of the project before the actual development begins to work
on various setup activities and address any technical or logistical issues. Some activities
performed during this sprint may include choosing and setting up development and test
environments, requesting access rights, planning the initial user stories, etc. No product is
released at the end of this sprint. It can be shorter than a typical sprint.

SUCCESSOR
Any user story that cannot start or finish until another user story is completed.

SUPPLEMENTAL REQUIREMENTS
Behavioral and non-behavioral requirements of the system such as functional requirements,
nonfunctional requirements, and design constraints.
T
TASK
Work items added to the sprint backlog at the beginning of a sprint and broken down into hours.
Each task should not exceed 12 hours (or two days), but it's common for teams to insist that a
task take no more than a day to finish. A Task is a unit of work that, when performed,
contributes to the fulfillment and completion of a scheduled Work Product. Tasks allow
decomposition of scheduled items into manageable units of work. Team members can take
responsibility or ownership for each Task, providing estimates and remaining time for
completion. Tasks are the main units of work for a project team member.

TASK ESTIMATE
The amount of effort estimated to complete a single task. Generally recorded in hours, but does
not directly correlate to user story estimates.

TEST CASE
A set of known conditions or variables and behaviors associated with a feature or requirement
that define acceptance of work associated with the work item; a test case also captures test
results. A Test Case is considered the Acceptance Testing procedures for clarifying the
behavior for a work product. A work product may be the user story or a defect. A test case
may be assigned to one work product. A work product may have many test cases.

U
USER STORY
A listing of acceptance criteria needed to deliver a new feature or piece of work. Generally
written from the perspective of a user of the system. A commonly used format is: As a X, I want
to Y, so that Z. “A user story is the smallest piece of functionality that is valuable and
acceptable to a customer.” It is a software system requirement formulated as one or more
sentences in the everyday or business language of the user that can be completed within an
Iteration. A User Story is unique in that it can be decomposed into Parent/Child or hierarchical
User Stories.

V
VELOCITY
The total effort a team is capable of in a sprint. Agile teams typically use the sum of story points
associated to accepted user stories delivered in a sprint as their velocity calculation. The
number is derived by evaluating the work (typically in user story points) completed from the last
sprint's backlog items. The collection of historical velocity data is a guideline for assisting the
team in understanding how much work they can do in a future sprint.