0% found this document useful (0 votes)

31 views74 pages

Agile Encyclopedia 1710905813

Uploaded by

saurabgemini861

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

31 views74 pages

Agile Encyclopedia 1710905813

Uploaded by

saurabgemini861

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 74

Encyclopedia of Agile

An Indexed glossary of terms used in Agile Software Development

The intention of compiling this Encyclopedia of Agile was to create a document that can be used both as an
offline reference, and as an online linked reference to some of the top thought leaders in the software
industry.

The terms and definitions found in this encyclopedia are public domain. The wording of the definitions were
taken from the following sources, with reference links to these sources for more in depth coverage of the
terminology definitions and etymology.

While the content is not new, or original, I hope that you find the various indexes and references helpful in
your search for understanding of all things Agile.

http://www.wikipedia.org/

Scrum.org

Agile Glossary

ScrumAlliance
Agile Glossary

Agile Glossary

2
Scrum Terminology Index

Scrum Roles Scrum Activities

ScrumMaster Planning
Certified ScrumMaster Release Planning
Product Owner Sprint Planning
Team Backlog Grooming
Delivery Team Sprint a.k.a Iteration
Cross-Functional Team Daily Scrumaka Daily Standup
Sprint Review a.k.a Demo
Retrospective a.k.a Kaizen

Scrum Artifacts Types Of Stories

User
Backlog Technical
Product Backlog Defect
Sprint Backlog Spike
Burndown Chart Tracer Bullet
Burnup Chart Research
Action Items
Parking Lot
Product Vision Statement
Team Agreements
Definition of Done
Working Agreements

www.cprime.com i
Agile Terminology Index

2.5 Big Ball of Mud 8

2.6 Big Visible Charts 9

1 A 1
2.7 * Blocked 9
1.1 Acceptance Testing 1
2.8 Bottleneck 9
1.2 * Adaptive 1
2.9 Branching 9
1.3 * Affinity Estimating 1
2.10 Breaking the Build 10
1.4 * Agile 2
2.11 Build Process 10
1.5 Agile Development Practices 2
2.12 Burn-Down Chart 10
1.6 Agile Estimation 3
2.13 Burn-Up Chart 11
1.7 Agile Manifesto 3
2.14 Business Alignment 12
1.8 Agile Methods 4
2.15 Business Value 12
1.9 Agile Methodology 4
3 C 12
1.10 Agile Modeling 5
3.1 Capacity 12
1.11 Agile Planning Basics 5
* CANI 12
1.12 Agile Project Management 5
3.2 * Card-Conversation-Confirmation 13
1.13 Agile Software Development 6
3.3 Certified ScrumMaster 13
1.14 * Agile Unified Process 6
3.4 Chicken 13
1.15 * Agilista 6
3.5 Code Smell 14
1.16 * Agility 6
3.6 Colocation 14
1.17 Alignment 6
3.7 Continuous Integration 14
1.18 ALM 7
3.8 Cross-Functional Team 14
1.19 * Anchoring 7
3.9 * Crystal 15
1.20 Application Lifecycle Management
7 3.10 Customer 15

2 B 7 4 D 15

2.1 Backlog 7 4.1 Daily Scrum 15

2.2 Backlog Item 8 4.2 Daily Standup 15

2.3 Backlog Item Effort 8 4.3 Defect 15

2.4 Backlog Grooming 8 4.4 Definition of Done 16

www.cprime.com ii
Agile Terminology Index

4.5 Delivery Team 16 6.9 * Functional Test 22

4.6 * Dependency Injection Principle 17 7 G 22

4.7 Design Pattern 17 8 H 23

4.8 Distributed Development Team 17 8.1 * Ha 23

4.9 Distributed Scrum 17 9 I 23

4.10 Domain Model 18 9.1 Impediment 23

4.11 DSDM 18 9.2 INVEST 23

4.12 * Dynamic Systems Development 9.3 * Integration Test 24

Method 18
9.4 Inspect and Adapt 24
5 E 18
9.5 * Interface Segregation Principle 24
5.1 * Earned Value Chart 18
9.6 * Iron Triangle 24
5.2 Emergence 18
9.7 IT Alignment 24
5.3 Empiricism 18
9.8 Iteration 24
5.4 Epic 19
10 J 25
5.5 EssUP 19
11 K 25
5.6 * Essential Unified Process: 19
11.1 Kanban 25
5.7 Estimation 19
11.2 * Kata 26
5.8 * Estimate to Complete Chart 19
11.3 * Kaizen 26
5.9 Extreme Programming 20
12 L 26
6 F 21
12.1 Lean Software Development 26
6.1 Fail-Fast 21
* Levels of Planning, 5 27
6.2 Feature 21
12.2 * Liskov Substitution Principle 27
6.3 FDD 21
12.3 * Load Test 27
6.4 * Feature Driven Development 21
13 M 27
6.5 Fibonacci Sequence 21
13.1 Minimum Marketable Features 27
6.6 Flow 21
14 N 28
6.7 * Forked Development 22
15 O 28
6.8 Fog Of War 22
15.1 OpenUP 28

www.cprime.com iii
Agile Terminology Index

15.2 * Open Unified Process 28 18.1 * Reactive 34

15.3 * Open Closed Principle 28 18.2 Refactoring 34

15.4 * Osmotic Communication 28 18.3 Release (Software) 35

16 P 28 18.4 Release Backlog 35

16.1 Pair Programming 28 18.4.1.1.1 TBD

16.2 Parallel Development 29 18.5 Release Management 35

16.3 * Pareto Principle 29 18.5.1.1.1 TBD

16.4 * Parking Lot 29 18.6 Release Plan 35

16.5 Pattern 29 18.7 Release Planning 36

* Performance Test 29 18.8 Research Story 36

16.6 Pig 30 18.8.1.1.1 TBD

16.7 Planning 30 18.9 Resources 36

16.8 Planning Game 30 18.9.1.1.1 TBD

16.9 Planning Poker 31 18.10 Retrospective 36

16.10 * Pragmatic Programming 31 18.11 * Ri 37

16.11 * Predictive 32 18.12 * ROI 37

16.12 * Prioritization 32 18.13 * Ron Dori 37

16.13 * Process Framework 32 19 S 37

16.14 Product 32 19.1 * Schedule 37

16.15 Product Backlog 32 19.2 * Scope 37

16.16 * Product Backlog Item 33 19.3 Scrum 37

16.17 Product Owner 33 19.4 ScrumBut 38

16.18 * Product Roadmap 33 19.5 ScrummerFall 39

16.19 Product Vision 33 19.6 ScrumPlus 40

16.20 * Productivity 34 19.7 Scrum Team 40

16.21 * Profiling 34 19.8 ScrumMaster 40

17 Q 34 19.9 Scrum Snowman 41

18 R 34 19.10 Self-Organization 41

www.cprime.com iv
Agile Terminology Index

19.11 * Shu 42 20.10 * Tracer Bullet 50

19.12 * Shu-Ha-Ri 42 20.11 * Transparency 50

19.13 * Sidebar 42 20.12 * Tuckman Model 51

19.14 * Single Responsibility Principle 42 21 U 51

* Software Quality Metrics 42 21.1 Unit Testing 51

19.15 * SOLID OOD Principles 43 21.2 User Story 51

19.16 Spike 44 22 V 52

19.17 Sprint 44 22.1 Velocity 52

19.18 Sprint Backlog 44 22.2 * Velocity Tracking 52

19.19 Sprint Burn-Down Chart 44 22.3 Vision 52

19.20 Sprint Planning Meeting 44 22.4 Voice of the Customer (VOC) 53

19.21 Sprint Review 45 23 W 53

19.22 Stakeholder 45 23.1 Wiki 53

19.23 Standup Meeting 46 23.2 * WIP 53

19.24 Story 46 23.3 * Work Breakdown Structure 53

19.25 Story Points 47 23.4 Work in Progress (WIP) 53

19.26 * Stress Test 47 24 X 54

19.27 * Swarming 47 24.1 XP 54

20 T 47 25 Y 54

20.1 Task 47 25.1 * YAGNI 54

20.2 Task Board 48 25.2 * YAGRI 54

20.3 * Task Breakdown 48 26 Z 54

20.4 Team 48 26.1 Reference Articles and Papers 55

20.5 Technical Debt 49 Agile Architectures 55

20.6 * Technical Story 49 26.1.1 Agile Architecture 55

20.7 Test Automation 49 by Chris Sterling @ SolutionsIQ, CST 55

20.8 Test-Driven Development 50 by Mickey Phoenix @ SolutionsIQ, CSM 55

20.9 Time-box 50 Distributed Scrum 55

www.cprime.com v
Agile Terminology Index

26.1.2 Successful Distributed Agile Team by John Rudd @ SolutionsIQ 57

Working Patterns 55
26.1.12 Agile ROI Part II: The Business Case for
by Monica Yap @ SolutionsIQ, CSM 55 Agility 57

26.1.3 Case Study: Implementing Distributed by David Wylie @ SolutionsIQ 57

Extreme Programming 55
26.1.13 Scrum in the Enterprise 57
by Monica Yap @ SolutionsIQ, CSM 55
by Kevin Thompson @ cPrime.com, CSM,
26.1.4 Daily Scrums in a Distributed World CSP, PMP, PhD 57
55
26.1.14 How Uncertainty Works 57
by Kevin Thompson @ cPrime.com, CSM,
by Kevin Thompson @ cPrime.com, CSM,
CSP, PMP, PhD 55
CSP, PMP, PhD 57
Meta-Scrum 55
26.1.15 The Price of Uncertainty 57
26.1.5 Establishing and Maintaining Top to
by Kevin Thompson @ cPrime.com, CSM,
Bottom Transparency Using Meta-Scrum 56
CSP, PMP, PhD 57
by Brent Barton @ SolutionsIQ, CST 56
26.1.16 How Agile should your Project be? 58
Agile Adoption 56
by Kevin Thompson @ cPrime.com, CSM,
26.1.6 Introduction to Scrum 56 CSP, PMP, PhD 58

by Kevin Thompson @ cPrime.com, CSM, 26.1.17 Integrating Waterfall and Agile

CSP, PMP, PhD 56 Development 58

26.1.7 Scrum as Project Management 56 by Shayan Alam @ cPrime.com, PMP 58

by Kevin Thompson @ cPrime.com, CSM, 26.1.18 Rational Unified Process Best

CSP, PMP, PhD 56 Practices 58

26.1.8 The Agile Story: Scrum Meets PMP 56 by Crystal Lee @ cPrime.com, PMP, 58

by Crystal Lee @ cPrime, PMP, CSM 56 26.1.19 Effective Retrospectives 58

26.1.9 When to Use Scrum 56 by Kendrick Burson @ cPrime.com, CSM,

CSPO 58
by Kevin Thompson @ cPrime.com, CSM,
CSP, PMP, PhD 56 26.1.20 Transitioning From Time-Based to
Relative Estimation 58
26.1.10 Agile Top-Down: Striking a Balance 56
by Ilan Goldstein @ ScrumAlliance.org,
by Bryan Stallings @ SolutionsIQ, CST 56
CSM, CSPO, CSP 58
26.1.11 Agile ROI Part I: The Business Case for
Agility 57

www.cprime.com vi
Agile Terminology Index

26.1.21 5 Common Mistakes We 26.1.31 How Should We Deal With the Mess
Make Writing User Stories 59 That Scrum Exposes? 61

by Krystian Kaczor @ ScrumAlliance; by Monica Yap @ SolutionsIQ, CSM, CSPO

CSM, CSP 59 61

26.1.22 Agile Project Dashboards 59 26.1.32 The Afternoon ScrumMaster: Keeping

Agile Teams on Track 61
Bringing value to stakeholders and
top management 59 by Dhaval Panchal @ SolutionsIQ 61

by Leopoldo Simini @ ScrumAlliance; 26.1.33 The Short Short Story 61

CSM, CSP 59
by Paul Dupuy @ ScrumAlliance; CSM 61
26.1.23 Daily Stand-up, Beyond Mechanics: A
26.1.34 Is Sustainable Pace Nice to Have?
Measure of Self-Organization 60
Think Again! 62
by Bachan Anand CSM, CSPO, CSP 60
by Manoj Vadakkan CSM, CSP 62
26.1.24 Affinity Estimation for Release
26.1.35 Agile User Interface Design and
Planning 60
Information Architecture From the Trenches 62
by Monica Yap @ SolutionsIQ 60
by Robin Dymond @ ScrumAlliance;
26.1.25 Managing Risk in Scrum, Part 1 60 CSM, CSP, CST 62

by Valerie Morris @ SolutionsIQ 60 26.1.36 Why Agile Does Matter in an

Embedded Development Environment 62
26.1.26 Product Owner Anti-Patterns 60
by Bent Myllerup @ ScrumAlliance;
by Monica Yap @ SolutionsIQ 60
CSM, CSPO, CSP, CSC 62
26.1.27 Card-Conversation-Confirmation 60
26.1.37 The Illusion of Precision 62
by Ron Jeffries, 2001 60
by Jim Schiel @ ScrumAlliance; CSM, CSP,
26.1.28 Recognizeing Bottlenecks in Scrum 60
CST 62
by Dhaval Panchal @ SolutionsIQ, CST 60
26.1.38 Specialization and Generalization in
26.1.29 If At First You Don't Succeed, Fail, Fail Teams 62
Again 61
by Bas Vodde @ ScrumAlliance; CSM,
by Michael Tardiff @ SolutionsIQ, CSM, CSPO, CSP, CST 62
CSPO 61
26.1.39 The Importance of Self-Organisation63
26.1.30 What is the Definition of Done (DoD) in
by Geoff Watts @ ScrumAlliance; CSM,
Agile? 61
CSP, CSC, CST 63
by Dhaval Panchal @ SolutionsIQ, CST 61

www.cprime.com vii
Agile Terminology Index

26.1.40 Manager 2.0: The Role of the Manager

in Scrum 63

by Pete Deemer @ ScrumAlliance; CSM,

CSP, CST 63

www.cprime.com viii
Encyclopedia of Agile Terminology

1A
1.1 Acceptance Testing

Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to
enable the customer to determine whether or not to accept the system.

Reference: Wikipedia

Return To Glossary

1.2 * Adaptive
Return To Glossary

1.3 * Affinity Estimating

Affinity Estimating is a process to quickly estimate a large number of stories with high level SWAG
estimates relative to other stories in the same project. To popular tactics are to estimate using either
relative or absolute points.

Estimating with absolute units:

When estimating with absolute units the facilitator will quickly review several stories, asking the
team for a flash vote on size (1,2,3,5,8,13,Epic). each new story is compared to the previously voted
stories for equivalent size. Each vote is a flash vote, no more than 60 seconds discussion. As each story
is estimated the story card is dropped onto the specified stack. By the end of the exercise al stories
have been assigned and absolute story point size

Estimating relative units:

When estimating with relative units the delivery team works in parallel, each selecting a stack of
stories and sorting them on a wall, floor or table in relative size, smallest to largest. As the team
members work through their stacks they can reference stories placed by other team members,
possibly moving those stories to a new location in the continuum. After all stories have been placed
and the team has reviewed the relative sorting order of the entire backlog the continuum is

www.cprime.com 1
Encyclopedia of Agile Terminology

translated to story points by marking equal gradations along the continuum (1,2,3,5,8,13,Epic). A this
point the team can reference the established boundaries and move stories to one side or the other of a
boundary line according to their best judgement. By the end of the process all stories will be assigned
a relative story point size.

1.5 Agile Development Practices

Procedures and techniques used to conduct Agile software development. Although there is no
canonical set of Agile practices, most Agile practitioners adopt some subset of Scrum and XP practices.

Broadly speaking, any practice or technique that facilitates the values and principles set forth in
the Agile manifesto can be considered an Agile practice.

The most popular agile methodologies include:

Extreme Programming (XP)

Scrum

Crystal,

Dynamic Systems Development Method (DSDM)

Lean Development

Feature Driven Development (FDD).

All Agile methods share a common vision and core values of the Agile Manifesto.

Some other well-known agile software development methods include:

Agile modeling

Agile Unified Process (AUP)

www.cprime.com 2
Encyclopedia of Agile Terminology

Essential Unified Process (EssUP)

Open Unified Process (Open UP)

Velocity Tracking

1.6 Agile Estimation

Agile estimation is a process of agreeing on a size measurement for the stories in a product backlog.
Agile estimation is done by the team, usually using Planning Poker.

Return To Glossary

1.7 Agile Manifesto

A philosophical foundation for effective software development, the Agile Manifesto was created by
representatives from Extreme Programming, Scrum, DSDM, Adaptive Software Development,
Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need
for an alternative to documentation-driven, heavyweight software development processes. It reads,
in its entirety, as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through
this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Twelve principles underlie the Agile Manifesto, including:

Customer satisfaction by rapid delivery of useful software

www.cprime.com 3
Encyclopedia of Agile Terminology

Welcome changing requirements, even late in development

Working software is delivered frequently (weeks rather than months)

Working software is the principal measure of progress

Sustainable development, able to maintain a constant pace

Close, daily co-operation between business people and developers

Face-to-face conversation is the best form of communication (co-location)

Projects are built around motivated individuals, who should be trusted

Continuous attention to technical excellence and good design

Simplicity

Self-organizing teams

Regular adaptation to changing circumstances

Some of the manifesto’s authors formed the Agile Alliance, a non-profit organization that promotes
software development according to the manifesto’s principles.

References: Wikipedia, AgileManifesto.org, 12 Agile Principles

Return To Glossary

1.8 Agile Methods

See Agile Development Practices

Return To Glossary

1.9 Agile Methodology

Agile Methodology is an umbrella term for several iterative and incremental software development
methodologies.

See Agile Development Practices

Return To Glossary

www.cprime.com 4
Encyclopedia of Agile Terminology

1.10 Agile Modeling

Agile Modeling is a practice-based methodology for Modeling and documentation of software-based
systems. It

is intended to be a collection of values, principles, and practices for Modeling software that can be applied
on a software development project in a more flexible manner than traditional Modeling methods.

Return To Glossary

1.11 Agile Planning Basics

The four basics of Agile planning are: Product Backlog, Estimates, Priorities and Velocity.

• Estimates answer the question: “How long will it take or how many can we do by a given date?”

• Priorities answer the question: “Which capabilities are most important?

• The Product Backlog answers the question: “What capabilities are needs for financial success?”

• Velocity answers the question: “How much can the team complete in a Sprint?”

Return To Glossary

1.12 Agile Project Management

The style of project management used to support Agile software development. Scrum is the most widely
used Agile project management practice. XP practices also include practices that support Agile project
management. Essential feature of Agile project management include:

i. Iterative development cycles

ii. Self-organizing teams
iii. Multi-level planning
iv. Dynamic scope
v. Frequent collaboration with customer and/or business sponsors

1.13 Agile Software Development

Agile software development is a group of software development methodologies based on iterative and
incremental development, where requirements and solutions evolve through collaboration between self
organizing team, cross functional teams.

The development of software using Agile development practices and Agile project management.

Features of Agile software development include a heavy emphasis on collaboration, responsiveness to

change, and the reduction of waste throughout the development cycle.

Agile software development (ASD) focuses on keeping code simple, testing often, and delivering functional
bits of the application as soon as they're ready.

References: Wikipedia

Return To Glossary

1.14 * Agile Unified Process

Return To Glossary

1.15 * Agilista
Return To Glossary

1.16 * Agility
Return To Glossary

1.17 Alignment
Organizations with production dependencies across department boundaries run the risk of falling out of
phase (or alignment). Alignment includes any actions or policies that exist so that a process or activity in
one section of the organization is congruent with the organization's or business unit's governing mission.
The lack of business/IT alignment is a chronic problem for many organizations and frequently the root
cause of systemic software delivery failure. Agile development practices are designed to address many
of the root causes of misalignment between IT and the business.

References: Wikipedia

Return To Glossary

www.cprime.com 6
Encyclopedia of Agile Terminology

1.18 ALM
See: Application Lifecycle Management

Return To Glossary

1.19 * Anchoring
Return To Glossary

1.20 Application Lifecycle Management

"Application Lifecycle Management (ALM) is a continuous process of managing the life of an application
through governance, development and maintenance." (Wikipedia)

When Agile software development is introduced into an organization it generally requires substantial
changes in the organization's ALM tools and policies, which are typically designed to support alternative
methodologies such as Waterfall.

References: Wikipedia

Return To Glossary

2B
2.1 Backlog
The generic term for a repository of requirements (stories / work items) that define a system and it’s
many parts. The outermost scope of work defined is the Product Backlog, which defines all
requirements/features/defects/stories for a given product. A Product Backlog is subdivided into one or
more Release Backlogs. During Sprint planning the delivery team estimates the top most Backlog Items in
the current Release Backlog and assigns them to their Sprint Backlog where they are tracked and
implemented for the current sprint.

See also: Product Backlog Item, Task, Iteration, Sprint, Sprint Backlog Product Owner, Planning Game

References: Wikipedia

Return To Glossary

www.cprime.com 7
Encyclopedia of Agile Terminology

2.2 Backlog Item

See: Product Backlog Item

References: Wikipedia

Return To Glossary

2.3 Backlog Item Effort

Some Scrum practitioners estimate the effort of product backlog items in ideal engineering days, but
others prefer less concrete backlog effort estimation units. Alternative units might include story points,
function points, or "t-shirt sizes" (1 for small, 2 for medium, etc). The advantage of more vague units is that
they're explicit about the distinction that product backlog item effort estimates are estimates of effort, not
duration. Also, estimates at this level are rough guesses that should never be confused with actual
working hours (Note that sprint tasks are distinct from product backlog items and task effort remaining is
always estimated in hours).

References: SolutionsIQ:Backlog Item Effort

Return To Glossary

2.4 Backlog Grooming

Backlog grooming is both an ongoing process and the name for a meeting:

The process of adding new user stories to the backlog, re-prioritizing existing stories as needed, creating
estimates, and deconstructing larger stories into smaller stories or tasks.

A meeting or ceremony that occurs regularly within a team's iteration cycle. Scrum
Alliance founder Ken Schwaber recommends that teams allocate 5% of their time to revisiting and
tending to the backlog. Backlog grooming is the term favored by the Scrum Alliance, although Scrum co-
founder Jeff McKenna and Australian CST Kane Mar prefer to call this ceremony Story Time.

Return To Glossary

2.5 Big Ball of Mud

“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-
code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient
repair. Information is shared promiscuously among distant elements of the system, often to the point
where nearly all the important information becomes global or duplicated. The overall structure of the

www.cprime.com 8
Encyclopedia of Agile Terminology

system may never have been well defined. If it was, it may have eroded beyond recognition.
Programmers with a shred of architectural sensibility shun these quagmires. Only those who are
unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of
patching the holes in these failing dikes, are content to work on such systems.”

o Brian Foote and Joseph Yoder, Big Ball of Mud.

References: Wikipedia, Big Ball of Mud

Return To Glossary

2.6 Big Visible Charts

Big visible charts are exactly what you would think they would be: Big charts posted near the agile team
that describe in different ways the team's progress. Big visible charts not only can be useful tools for the
team but also make it easier for any stakeholder to learn how the team is progressing. Big visible charts
are an important tool for implementing the essential agile values of transparency and communication.

References: XPProgramming.com

Return To Glossary

2.7 * Blocked
See Also:

Return To Glossary

2.8 Bottleneck
Any resource or process whose capacity is less than or equal to the demand placed on it, thus
constraining the flow of work or information through the process.

2.10 Breaking the Build

When a developer adds changes to the source code repository that result in the failure of a
subsequent build process, the developer has "broken the build." Avoiding breaking the build is a
commitment generally required by agile software developers and integral to the XP practice continuous
integration.

The build is broken if the build process cannot successfully completed for any number of reasons
including (but not limited to) failure to compile, compiling with unacceptable warnings, or the failure of
any number of (usually) automated software tests. The more comprehensive the build process, the higher
the threshold for breaking the build.

If a code submission does result in breaking the build, the developer should immediately remove the
cause. If the build breaks but the immediate cause is not self-evident, a frequent practice of established
agile development teams is to take immediate action to fix the build.

Return To Glossary

2.11 Build Process

"The amount of variability in implementation makes it difficult to come up with a tight definition of a Build
Process, but we would say that a Build Process takes source code and other configuration data as input
and produces artifacts (sometimes called derived objects) as output. The exact number and definition of
steps depends greatly on the types of inputs (Java versus C/C++ versus Perl/ython/Ruby source code) and
the type of desire output (CD image, downloadable zip file or self-extracting binary, etc). When the source
code includes a compiled language then the Build Process would certainly include a compilation and
perhaps a linking step." (Anthillpro)

Return To Glossary

2.12 Burn-Down Chart

A Burn down chart is a chart showing how much work remaining in a sprint. Calculated in hours
remaining and maintained by the Scrum Master daily.

A publicly displayed chart that depicts the total task hours remaining per day. It shows where the team
stands regarding completing the tasks that comprise the backlog items that achieve the goals of the

www.cprime.com 10
Encyclopedia of Agile Terminology

sprint. The X-axis represents days in the sprint, while the Y-axis is effort remaining (usually in ideal
engineering hours). To motivate the team, the sprint burn-down chart should be displayed prominently. It
also acts as an effective information radiator. A manual alternative to this is a physical task board.
Ideally, the chart burns down to zero by the end of the sprint. If the team members are reporting their
remaining task hours realistically, the line should bump up and down.

2.13 Burn-Up Chart

Representation of the amount of stories completed, with points plotted on an X and Y axis that map an
upward trend of work completed until reaching 100%.

www.cprime.com 11
Encyclopedia of Agile Terminology

Return To Glossary

2.14 Business Alignment

See: Alignment

Return To Glossary

2.15 Business Value

Each user story in the Product Backlog should have a corresponding business value assigned. Typically
assign (L,M,H) Low, Medium, High. Product Owner prioritizes Backlog items by highest value.

An informal term that includes all forms of value that determine the health and well-being of the firm in
the long run. It expands the concept of value of the firm beyond economic value to include other forms of
value such as employee value, customer value, supplier value, channel partner value, alliance partner
value, managerial value, and societal value. In the context of agile development, it is what management is
willing to pay for and a way to identify the value of "work" or a story.

References: Wikipedia

Return To Glossary

3C
3.1 Capacity
Capacity is the Number of Teammates (Productive Hours x Sprint Days).

Example:

o Team size is 4,
o Productive hours per person per day are 5,
o Sprint length is 30 days.
o Capacity = 4(5x30) = 600 hours.

Return To Glossary

* CANI
Constant And Never-ending Improvement

www.cprime.com 12
Encyclopedia of Agile Terminology

Ron Jeffries, 2001

References: Card-Conversation-Confirmation

Return To Glossary

3.3 Certified ScrumMaster

Someone who is acting in the role of ScrumMaster on a Scrum team and who has attended a two-
day Certified ScrumMaster (CSM) class to obtain certification.

References: Wikipedia

Return To Glossary

3.4 Chicken
Scrum slang for someone who is interested in a project but has no responsibility for working on a task in
the active iteration. They may observe team meetings but cannot vote or talk.

Chickens are the people that are not committed to the project and are not accountable for deliverables.

References: Wikipedia

3.5 Code Smell

"Any symptom in the source code of a computer program that indicates something may by wrong."
(Wikipedia)

Common code smells are often used to diagnose the quality of legacy code. Code smells generally indicate
that the code should be refactored or the overall design should be reexamined.

3.7 Continuous Integration

"Continuous Integration is a software development practice where members of a team integrate their
work frequently, usually each person integrates at least daily - leading to multiple integrations per day.
Each integration is verified by an automated build (including test) to detect integration errors as quickly
as possible. Many teams find that this approach leads to significantly reduced integration problems and
allows a team to develop cohesive software more rapidly." (MartinFowler.com)

References: Wikipedia

Return To Glossary

3.8 Cross-Functional Team

Team comprised of members with all functional skills and specialties necessary to complete a project
from start to finish.

www.cprime.com 14
Encyclopedia of Agile Terminology

References: Wikipedia

Return To Glossary

3.9 * Crystal
1990s

Return To Glossary

3.10 Customer
The recipient of the output (product, service, information) of a process. Customers may be internal or
external to the organization. The customer may be one person, a department, or a large group. Internal
customers (outside of Information Technology) are sometimes called the "Business."

References: Wikipedia

Return To Glossary

4D
4.1 Daily Scrum
See: Standup Meeting

Return To Glossary

4.2 Daily Standup

See: Standup Meeting

Return To Glossary

4.3 Defect
A defect is a failure or bug of the product to behave in the expected fashion. Defects are stored in a bug-
tracking system, which may or may not be physically the same system used to store the Product Backlog.
If not, then someone (usually the Product Owner) must enter each Defect into the Product Backlog, for
sequencing and scheduling.

See Also: Story, User Story, Technical Story, Spike, Tracer Bullet

www.cprime.com 15
Encyclopedia of Agile Terminology

Return To Glossary

4.4 Definition of Done

The criteria for accepting work as completed. Specifying these criteria is the responsibility of the entire
team, including the business. Generally, there are three levels of "Done" (also known as Done-Done-Done):

Done: Developed, runs on developer's box

Done: Verified by running unit tests, code review, etc.

Done: Validated as being of deliverable quality with functional tests, reviews, etc.

However, the exact criteria for what constitutes "Done" varies to meet the specific needs of different
organizations and initiatives. An important agile principle is to deliver (potentially) releasable
software after every iteration. The definition of done is a key component of Agile project governance
used to help teams comply with this principle.

Return To Glossary

4.5 Delivery Team

In agile software development, the delivery team refers to the cross-functional group of people that have
made a collective commitment to work together to produce the work product and improve their
performance over time. In addition to software development and test roles, the team may include any
skill set necessary to deliver the work product.

The delivery team usually includes people skilled to understand customer requirements and conduct
software design, coding and testing. Additional skills (e.g. UI design, usability, etc.) may also be included,
especially when they are integral to the software release.

The delivery team is encouraged to be self-organizing and to take collective responsibility for all work
commitments and outcomes. Delivery teams respond to requirements (often presented as user stories) by
collectively defining their tasks, task assignments, and level of effort estimates.

The ideal size for a delivery team adheres to the magic number seven plus or minus two rule.

4.6 * Dependency Injection Principle

Single Responsibility Principle

Open Closed Principle,

Liskov Substitution Principle,

Interface Segregation Principle,

Dependency Injection Principle

Return To Glossary

4.7 Design Pattern

"A design pattern is a general reusable solution to a commonly occurring problem in software design."
(Wikipedia)

Return To Glossary

4.8 Distributed Development Team

Refers to development teams that work on the same project but are located across multiple geographic
locations or work sites. Distributed development teams are becoming the norm for today’s software
projects. When co-location is not an option, distributed teams are faced with the challenge of keeping
software projects on track and keeping remote developers engaged collaboratively. Agile development is
more difficult for distributed teams and generally require that special practices are adopted that
mitigate the inherent risks of distributed development.

4.9 Distributed Scrum

See Distributed Development Team

Return To Glossary

www.cprime.com 17
Encyclopedia of Agile Terminology

4.10 Domain Model

Information model describing the application domain that creates a shared language between business
and IT

References: Wikipedia

Return To Glossary

4.11 DSDM
See Dynamic Systems Development Method

Return To Glossary

4.12 * Dynamic Systems Development Method

Return To Glossary

5 E

5.1 * Earned Value Chart

Return To Glossary

5.2 Emergence
Emergence is an attribute of complex systems. When applied to software development, it is the principle
that the best designs and the best ways of working come about over time through doing the work, rather
than being defined in advance as part of an over-arching specification or detailed project plan.

References: SolutionsIQ: Epic

Return To Glossary

5.5 EssUP
See Essential Unified Process

Return To Glossary

5.6 * Essential Unified Process:

Return To Glossary

5.7 Estimation
The process of agreeing on a size measurement for the stories or tasks in a product backlog. On agile
projects, estimation is done by the team responsible for delivering the work, usually using a planning
game.

Estimates on stories are made in abstract story points.

Estimates on tasks are made in hours.

5.8 * Estimate to Complete Chart

Return To Glossary

www.cprime.com 19
Encyclopedia of Agile Terminology

5.9 Extreme Programming

1996

A software development methodology adhering to a very iterative and incremental approach, Extreme
Programming is intended to improve software quality and responsiveness to changing customer
requirements. As a type of agile software development, it advocates frequent releases in short
development cycles (time-boxing), which is intended to improve productivity and introduce checkpoints
where new customer requirements can be adopted.

XP consists of a number of integrated practices for developers and management - the original twelve
practices of XP include:

1. Small Releases
2. On-site Customer
3. Sustainable Pace
4. Simple Design
5. Continuous Integration
6. Unit Testing
7. Coding Conventions
8. Refactoring Mercilessly
9. Test-Driven Development
10. System Metaphor
11. Collective Code Ownership
12. Pair Programming
Most successful Agile practitioners adopt some subset of XP practices, often in conjunction with Scrum.

6.4 * Feature Driven Development

Return To Glossary

6.5 Fibonacci Sequence

A sequence of numbers in which the next number is derived by adding together the previous two (e.g. 1,
2, 3, 5, 8, 13, 21, 34...). The sequence is used to size stories in Agile estimation techniques such as Planning
Poker.

References: Fibonacci Sequence

Return To Glossary

6.6 Flow
Continuous delivery of value to customers (vs. big-batch, big-release, big-bang).

www.cprime.com 21
Encyclopedia of Agile Terminology

6.7 * Forked Development

Return To Glossary

6.8 Fog Of War

“The fog of war is a term used to describe the uncertainty in situation awareness experienced by
participants in military operations. The term seeks to capture the uncertainty regarding own capability,
adversary capability, and adversary intent during an engagement, operation, or campaign.”

Wikipedia
In Agile the fog of war refers to the increasing uncertainty of estimates.

As stories increase in size the level of confidence in the estimates decreases.

As stories are scheduled farther away for implementation the level of confidence in those estimates
decreases significantly. For this reason it is not reasonable to depend on estimates for stories expected to
be implemented more than a month out. As those stories come into view on the near term schedule new
estimates can be made with greater confidence.

Generally the best estimates are given during sprint planning sessions where the story is expected to be
implemented that sprint.

References: Wikipedia

Return To Glossary

6.9 * Functional Test

See Also:

Return To Glossary

7 G

www.cprime.com 22
Encyclopedia of Agile Terminology

8H
8.1 * Ha
See Also: Shu-Ha-Ri, Shu, Ri

Return To Glossary

9I
9.1 Impediment
In Scrum: Anything that prevents a team member from performing work as efficiently as possible is an
impediment. Each team member has an opportunity to announce impediments during the daily standup
meeting. The ScrumMaster is charged with ensuring impediments are removed. ScrumMasters often
arrange sidebar meetings, Parking Lot, when impediments cannot be resolved on the spot in the daily
Scrum meeting.

9.3 * Integration Test

See Also:

Return To Glossary

9.4 Inspect and Adapt

"Inspect and Adapt" is a slogan used by the Scrum community to capture the idea of discovering over the
course of a project emergent software requirements and ways to improve the overall performance of
the team. It neatly captures the both the concept of empirical knowledge acquisition and feedback-loop-
driven learning.

9.5 * Interface Segregation Principle

Single Responsibility Principle,

Open Closed Principle,

Liskov Substitution Principle,

Interface Segregation Principle

Dependency Injection Principle

Return To Glossary

9.6 * Iron Triangle

Return To Glossary

9.7 IT Alignment
See: Alignment

Return To Glossary

9.8 Iteration
A period (from 1 week to 2 months in duration) during which the Agile development team produces an
increment of completed software. All system lifecycle phases (requirements, design, code, and test) must

www.cprime.com 24
Encyclopedia of Agile Terminology

be completed during the iteration and then (empirically) demonstrated for the iteration to be accepted as
successfully completed. At the beginning of the iteration, the business or the product owner identifies the
next (highest priority) chunk of work for the team to complete. The development team then estimates the
level of effort and commits to completing a segment of work during the iteration. During the iteration, the
team is not expected to change objectives or respond to change requests. However, at the front end of the
next iteration the business or product owner is free to identify any new segment of work as the current
highest priority.

12.2 * Liskov Substitution Principle

See Also: SOLID OOD Principles: SingleResponsibilityPrinciple, OpenClosedPrinciple,
InterfaceSegregationPrinciple, DependencyInjectionPrinciple

Return To Glossary

12.3 * Load Test

See Also:

Return To Glossary

13 M
13.1 Minimum Marketable Features
The smallest set of functionality that must be realized in order for the customer to perceive value. A
"MMF" is characterized by the three attributes: minimum, marketable, and feature. A feature is
something that is perceived, of itself, as value by the user. "Marketable" means that it provides significant
value to the customer; value may include revenue generation, cost savings, competitive differentiation,
brand-name projection, or enhanced customer loyalty. A release is a collection of MMFs that can be
delivered together within the time frame.

References: Wikipedia

Return To Glossary

www.cprime.com 27
Encyclopedia of Agile Terminology

14 N

15 O
15.1 OpenUP
See Open Unified Process

Return To Glossary

15.2 * Open Unified Process

Return To Glossary

15.3 * Open Closed Principle

See Also: SOLID OOD Principles: SingleResponsibilityPrinciple, LiskovSubstitutionPrinciple,
InterfaceSegregationPrinciple, DependencyInjectionPrinciple

Return To Glossary

15.4 * Osmotic Communication

Return To Glossary

16 P
16.1 Pair Programming
"An Agile software development technique in which two programmers work together at one
workstation. One types in code while the other reviews each line of code as it is typed in. The person
typing is called the driver. and the person reviewing the code is called the observer or navigator. The
two programmers switch roles frequently." (Wikipedia)

www.cprime.com 28
Encyclopedia of Agile Terminology

Pair programming is one of the original 12 extreme programming practices. As counter-intuitive as it

may seem to the uninitiated, pair programming is more productive than two individuals working
independently on separate tasks.

Return To Glossary

16.2 Parallel Development

Parallel development occurs whenever a software development project requires separate development
efforts on related code bases. For example, when a software product is shipped to customers, a product
development team may begin working on a new major feature release of the product, while a product
maintenance team may work on defect corrections and customer patch releases of the shipped product.
Both teams begin work from the same code base, but the code necessarily diverges. Frequently the code
bases used in parallel development efforts must be merged at some future date, for example, to ensure
that the defect corrections provided by the product maintenance team are integrated into the major
release that the product development team is working on.

Return To Glossary

16.3 * Pareto Principle

References: BetterExplained, Wikipedia

Return To Glossary

16.4 * Parking Lot

Return To Glossary

16.5 Pattern
See: Design Pattern

Return To Glossary

* Performance Test
See Also: Profiling, Acceptance Test, Functional Test, SystemTest, Integration Test, Unit Test, Stress Test,
Load Test

Return To Glossary

www.cprime.com 29
Encyclopedia of Agile Terminology

16.6 Pig
Scrum slang. Someone who is responsible for doing a task on an active iteration. It comes from the joke, "A
chicken and a pig talk about breakfast. The chicken says, 'Let's have bacon and eggs.' The pig replies, 'That's
fine for you. You are just making a contribution, but I have to be fully committed.'" Pigs are actively
involved in the project.

plans are useless but planning is indispensable. Dwight Eisenhower

See Also: Product Vision, Product Roadmap, Release Plan, Sprint Plan, Daily Standup

References: AgileJournal, RallyDev

Return To Glossary

16.8 Planning Game

"The main planning process within extreme programming is called the Planning Game. The game is a
meeting that occurs once per iteration, typically once a week. The planning process is divided into two
parts." (Wikipedia)

www.cprime.com 30
Encyclopedia of Agile Terminology

In XP, the planning game includes iteration (or sprint) planning and release planning. In scrum, sprint and
release planning are two of the five levels of planning used in Agile projects.

16.9 Planning Poker

"Planning Poker is a consensus-based technique for estimating, mostly used to estimate effort or relative
size of tasks in software development." (Wikipedia)

Planning poker is a game used to apply estimates to stories. It uses a voting approach designed to avoid
influence bias (anchoring).

How it Works:

1. Each estimator selects a set of cards.

2. Facilitator reads item to be estimated, and moderates a brief discussion to clarify details.
3. Facilitator calls for estimates. Each estimator places estimate face down, hiding the value.
4. Facilitator calls for vote, and all estimators turn over cards at the same time.
5. If all cards agree, their value is recorded as the estimate.
6. Otherwise, facilitator asks high and low estimators to explain their reasoning, and moderates a
brief discussion to clarify issues.
7. Repeat 3-6 until estimates converge

References: Wikipedia

Return To Glossary

16.10 * Pragmatic Programming

16.13 * Process Framework

Return To Glossary

16.14 Product
Broadly speaking, product refers to a collection of tangible and intangible features that are integrated
and packaged into software releases that offer value to a customer or to a market. The term "product" is
often used in Agile software development to denote the software that is the subject of
the iteration or release. As such, "product" is generally used interchangeably with other names for
software release including "software release", "system", or "business application."

References: Wikipedia

Return To Glossary

16.15 Product Backlog

The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of
product backlog Items. These included both functional and non-functional customer requirements, as well
as technical team-generated requirements. While there are multiple inputs to the product backlog, it is
the sole responsibility of the product owner to prioritize the product backlog.

During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based
on the product owner's priorities.

See: Backlog

Return To Glossary

www.cprime.com 32
Encyclopedia of Agile Terminology

16.16 * Product Backlog Item

A unit of work, usually a story or a task, listed on the project backlog.

16.17 Product Owner

Product Owner is one of the key roles in Scrum. The product owner is the primary business
representative who represents the business stakeholders' "voice of the customer" and the "voice of the
business" to the sprint team. The responsibilities of the Product Owner include:

i. Establishing, nurturing, and communicating the product vision

ii. Creating and leading a team of developers to best provide value to the customer
iii. Monitoring the project against its ROI goals and an investment vision
iv. Making decisions about when to create an official release

The product owner is a role rather than a position. Consequently, several people likely participate in the
product owner role for larger projects.

References: Wikipedia

Return To Glossary

16.18 * Product Roadmap

Return To Glossary

16.19 Product Vision

The product vision is one of the five levels of planning.

A product vision is a brief statement of the desired future state that would be achieved through the
project initiative. The product vision may be expressed in any number of ways including financial
performance, customer satisfaction, market share, functional capability, etc. The product vision is
typically the responsibility of executive sponsorship and is articulated to the Agile development team by
the business and by the product owner, if the team is using Scrum.

References: Wikipedia:Elevator Pitch

18.3 Release (Software)

The movement of a software product or system from development into production. One principle of Agile
development is to focus on releasing software into productive use as soon as a minimum marketable
feature set can be delivered, and then proceeding with frequent incremental releases. This is in contrast
to alternative project approaches where most requirements are delivered in one “big bang” release.

It is desirable in Agile development to produce releasable software after every iteration (or sprint), even
if the code is not actually put into production for use by end-users.

18.4 Release Backlog

18.4.1.1.1 TBD
See Also:

Return To Glossary

18.5 Release Management

18.5.1.1.1 TBD
See Also:

Return To Glossary

18.6 Release Plan

The release plan is a schedule for releasing software into productive use. Typical release plans include
the key features to be delivered, along with corresponding release dates. Release plans may also expose
key milestones or dependencies that parallel project activities. In agile development, release plans can be
mapped back to the iterations (sprints) that implement the released features.

18.7 Release Planning

Release planning refers to planning activities used to estimate when software will be released into
product use. Activities include projecting the level of effort in terms of the number of iterations that will
be necessary to deliver the desired features. This is typically done by extrapolating the development
team's performance on the basis of its velocity.

A release planning meeting that brings together all parties that have a stake in the outcome and have
some kind of delivery responsibility to achieve the release is often necessary to produce a viable release
plan. This is especially the case when several development and non-development production efforts are
running in parallel with possible dependencies.

Release planning is one of the five levels of planning.

18.8 Research Story

18.8.1.1.1 TBD
Return To Glossary

18.9 Resources

18.9.1.1.1 TBD
Return To Glossary

18.10 Retrospective
A time-boxed meeting held at the end of an iteration, or at the end of a release, in which the team
examines its processes to determine what succeeded and what could be improved. The retrospective is
key to an Agile team's ability to "inspect and adapt" in the pursuit of "continuous improvement." The Agile
retrospective differs from other methodologies' "Lessons Learned" exercises, in that the goal is not to
generate a comprehensive list of what went wrong. A positive outcome for a retrospective is to identify
one or two high-priority action items the team wants to work on in the next iteration or release. The
emphasis is on actionable items, not comprehensive analysis. Retrospectives may take many forms, but

www.cprime.com 36
Encyclopedia of Agile Terminology

there is usually a facilitator, who may or may not be a member of the team, and the process is typically
broken down into three phases: data gathering, data analysis, and action items.

See Also: Sprint, Release, Inspect & Adapt, Effective Retrospectives, CANI, Kaizen, Inspect & Adapt

References: Wikipedia

Return To Glossary

18.11 * Ri
See Also: Shu-Ha-Ri, Shu, Ha

Return To Glossary

18.12 * ROI
Return To Glossary

18.13 * Ron Dori

See Also:

Return To Glossary

19 S
19.1 * Schedule
Return To Glossary

19.2 * Scope
Return To Glossary

19.3 Scrum
A lightweight process framework originally developed in 1995 by Ken Schwaber and Jeff Sutherland.

Scrum is a framework for the iterative development of complex products, particularly software. Scrum
is the most widely recognized Agile framework, and is compatible with other Agile practices
like Extreme Programming. Scrum is comprised of a series of short iterations - called sprints - each of
which ends with the delivery of an increment of working software. The framework is comprised of:

www.cprime.com 37
Encyclopedia of Agile Terminology

v. Three roles of the Scrum Team

1. Product Owner
2. ScrumMaster
3. Delivery Team

• Five Time-boxes:
1. Sprint
2. Sprint Planning Meeting
3. Daily Standup Meeting
4. Sprint Review
5. Retrospective

• Three artifacts:
1. Burn-down charts
2. Product backlog
3. Sprint backlog

Sometimes the term Scrum is used interchangeably with the term Agile, but this is incorrect. Agile is not
a framework, but a broader set of values and principles, while Scrum is a specific framework that fits
comfortably under the Agile umbrella.

See Also:

References: ScrumAlliance, Scrum.org, ScrumGuide

Return To Glossary

19.4 ScrumBut
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize
the full benefits of product development using Scrum. Every Scrum role, rule, and timebox is designed to
provide the desired benefits and address predictable recurring problems. ScrumButs mean that Scrum
has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the
problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the
side of the team.

www.cprime.com 38
Encyclopedia of Agile Terminology

A ScrumBut has a particular syntax: (ScrumBut)(Reason)(Workaround)

ScrumBut Examples:

"(We use Scrum, but) (having a Daily Scrum every day is too much overead,) (so we only have one per
week.)"

"(We use Scrum, but) (Retrospectives are a waste of time,) (so we don't do them.)"

"(We use Scrum, but) (we can't build a piece of functionality in a month,) (so our Sprints are 6 weeks long.)"

"(We use Scrum, but) (sometimes our managers give us special tasks,) (so we don't always have time to
meet our definition of done.)"

Sometimes organizations make short term changes to Scrum to give them time to correct deficiencies. For
example, "done" may not initially include regression and performance testing because it will take several
months to develop automated testing. For these months, transparency is compromised, but restored as
quickly as possible.

19.7 Scrum Team

The scrum team consists of three roles;

1. ScrumMaster
Maintains the processes (typically in lieu of a project manager)

2. Product Owner
Represents the stakeholders and the business

3. Delivery Team
A cross-functional group who do the actual analysis, design, implementation, testing, etc.

References: Wikipedia:Project Manager

Return To Glossary

19.8 ScrumMaster
The ScrumMaster is responsible for maintaining the Scrum process and the overall health of the team.
The ScrumMaster assures that the team is fully functional and productive. The ScrumMaster performs
this role by administering the Scrum time-boxes, facilitating the organic self-organization of the team, and
removing any obstacles that may be impeding the team’s progress.

What the ScrumMaster is not:

The ScrumMaster is not the task master, since the team is responsible for assigning its own tasks.

The ScrumMaster is not the supervisor of the team, since the supervisor/subordinate relationship may
impede the organic self-organization of the team.

A good ScrumMaster proactively anticipates problems, opportunities for improvement, and conducts pre-
planning so the team can focus on delivering its sprint commitments. The ScrumMaster also keeps the

www.cprime.com 40
Encyclopedia of Agile Terminology

team honest regarding its commitments and helps the team identify opportunities to improve
collaboration.

In Scrum, when the Scrum roles are properly fulfilled there is no need for a traditional project manager
to supervise the team. Nevertheless, many organizations choose to retain project managers, after they
adopt Scrum, to perform functions that extend beyond the scope of the Scrum team functions.

References: Wikipedia

Return To Glossary

19.9 Scrum Snowman

The scrum process of frequent and early feedback cycles is often referred to as the “snowman model” as
the cyclic graph resembles a snowman.

References: MountainGoatSoftware

Return To Glossary

19.10 Self-Organization
Self-organization is a property of complex adaptive systems, whereby the organization of the system
emerges over time as a response to its environment. In Agile development, particularly in Scrum, self-
organization is a property of the agile development team, which organizes itself over time, rather than
being ordered by an external force such as a project or development manager. Self-organization also
reflects the management philosophy whereby operational decisions are delegated as much as possible to
those who have the most detailed knowledge of the consequences and practicalities associated with those
decisions.

References: Wikipedia: Self-Organization, Wikipedia: Complex Adaptive Systems

Return To Glossary

19.11 * Shu
See Also: Shu-Ha-Ri, Ha, Ri

Return To Glossary

19.12 * Shu-Ha-Ri
See Also: Shu, Ha, Ri

Return To Glossary

19.13 * Sidebar
See Also: Parking Lot

Return To Glossary

19.14 * Single Responsibility Principle

Single Responsibility Principle

Open Closed Principle,

Liskov Substitution Principle,

Interface Segregation Principle,

Dependency Injection Principle

Return To Glossary

* Software Quality Metrics

Dynamic Source Analysis

Code Coverage

Line Coverage

Branch Coverage

Method Coverage

www.cprime.com 42
Encyclopedia of Agile Terminology

Class Coverage

Package Coverage

Static Source Analysis

Coding Standards

Style, Formatting

StyleCop

Architectural Rules Compliance

Findbugs, PMD, Checkstyle, FxCop

LCOM4

Complexity

CCN

NCSS

Coupling

Afferent Coupling

Efferent Coupling

Spider Graph

Duplication: CPD

19.15 * SOLID OOD Principles

See Also: Single Responsibility Principle

Open Closed Principle,

Liskov Substitution Principle,

Interface Segregation Principle,

www.cprime.com 43
Encyclopedia of Agile Terminology

Dependency Injection Principle

Return To Glossary

19.16 Spike
A story or task aimed at answering a question or gathering information, rather than implementing
product features, user stories, or requirements. Sometimes a user story is generated that cannot be
estimated until the development team does some actual work to resolve a technical question or a design
problem. The solution is to create a “spike,” which is a story whose purpose is to provide the answer or
solution. Like any other story or task, the spike is then given an estimate and included in the sprint
backlog.

Return To Glossary

19.17 Sprint
The Scrum term for an iteration. The sprint starts with a sprint planning meeting. At the end of the sprint
there is a sprint review meeting, followed by a sprint retrospective meeting.

References: Wikipedia

Return To Glossary

19.18 Sprint Backlog

A list of features, user stories or tasks that are pulled from the product backlog for consideration for
completion during the upcoming sprint. Product backlog features and user stories are broken down into
tasks to form the sprint backlog during the sprint planning meeting.

19.19 Sprint Burn-Down Chart

See Burn-Down Chart

19.20 Sprint Planning Meeting

Each sprint begins with a two-part sprint planning meeting, the activity that prioritizes and identifies
stories and concrete tasks for the next sprint. For a one-month or four-week sprint, this two-part meeting

www.cprime.com 44
Encyclopedia of Agile Terminology

should last eight hours; for a two-week sprint, it lasts about four hours. As a general rule of thumb, the
number of weeks in a sprint multiplied by two hours equals the total length of the spring planning
meeting.

a. Part one of the sprint planning meeting is a review of the product backlog. This is when the product
owner describes what needs to be built for the next sprint. During this part of the meeting, it is not
uncommon for the team to discuss the sprint objectives with the product owner, and ask clarifying
questions and remove ambiguity.

b. During part two of the sprint planning meeting, the team decides how the work will be built. The team
will begin decomposing the product backlog items into work tasks and estimating these in hours. The
product owner must be available during this meeting but does not have to be in the room. The output of
the second planning meeting is the Sprint Backlog.

References: Wikipedia, Card-Conversation-Confirmation

Return To Glossary

19.21 Sprint Review

A meeting held at the end of each sprint in which the delivery team shows what they accomplished
during the sprint; typically this takes the form of a demo of the new features. The sprint review meeting
is intentionally kept very informal. With limited time allocated for Sprint review prep. A sprint review
meeting should not become a distraction or significant detour for the team; rather, it should be a natural
result of the sprint.

References: Wikipedia

Return To Glossary

19.22 Stakeholder
Anyone external to the team with a vested interest in the outcome of the team's work.

19.23 Standup Meeting

The Daily Standup Meeting is a minimalist status meeting, time-boxed to fifteen minutes. Its purpose is to
ensure that questions are answered quickly, that issues are identified and addressed quickly, and to
provide Team members with a common understanding of how the Sprint is progressing. The
ScrumMaster facilitates this meeting.

Three questions asked:

i. What have you done since last daily scrum?

ii. What will you do before the next daily scrum?
iii. What obstacles are impeding your work?

These items are often referred to as Y-T-I (Yesterday, Today, Impediments)

The ScrumMaster ensures that participants call sidebar meetings for any discussions that go too far
outside these constraints.

The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all
team members arrive.

a.k.a: Daily Scrum, Daily Standup

References: Wikipedia

Return To Glossary

19.24 Story
Scrum requirements written in short narrative form. There are 5 types of requirement stories:

1. User Story
2. Technical Story
3. Defect
4. Spike
5. Tracer Bullet

See User Story

References: Wikipedia, Card-Conversation-Confirmation

www.cprime.com 46
Encyclopedia of Agile Terminology

Return To Glossary

19.25 Story Points

Story points are an abstract measure of effort to implement a story. Story points can be evaluated in
either Absolute or Relative units.

Absolute units are directly related to time with 1 story point equal to 8 person hours of work. Because
absolute units are directly related to time they can be compared across teams.

Relative units are based on a known pivot story and are rated as either larger or smaller than the pivot
by some factor. The size of the pivot is specific to the team, therefore estimates of stories across teams are
not equal, nor are velocity measurements.

19.26 * Stress Test

i. A description of the work to be performed, in either technical or business terms

ii. An estimate of how much time the work will take (hours, days)

www.cprime.com 47
Encyclopedia of Agile Terminology

iii. An owner, who may or may not be pre-assigned

iv. An exit criteria and verification method (test or inspection)
v. An indication of who will be responsible for the verification

20.2 Task Board

A chart that presents, at minimum, "to do", "in progress", and "done" columns for organizing a team's work.
Some teams include their backlog as a column on the task board, while others limit it to work to be
performed during the current iteration. Ideally, the task board is a physical thing, consisting of note cards
or sticky notes affixed to a wall, although distributed teams may use an online task board application. The
task board may illustrate tasks or other forms of work such as user stories. In Scrum, the task board is
often used to illustrate the tasks for the current sprint, populated with tasks for the current sprint, while
other Agile teams may populate it with user stories.

See Also: Sprint Backlog, Sprint Planning, Task, Kanban, Big Visible Charts

References: Wikipedia

Return To Glossary

20.3 * Task Breakdown

Return To Glossary

20.4 Team
In Agile Software Development, the team refers to the cross-functional group of people that have made a
collective commitment to work together to produce the work product and improve their performance
over time. In addition to software development and test roles, the team may include any skill set
necessary to deliver the work product.

In Scrum the Team can refer to one of two groups of people

1. Scrum Team: members identified by each of 3 Scrum roles.

2. Delivery Team: A cross-functional subset of the Scrum Team.

www.cprime.com 48
Encyclopedia of Agile Terminology

20.5 Technical Debt

A term coined by Ward Cunningham to describe the obligation that a software organization incurs when
it chooses a design or construction approach that's expedient in the short term but that increases
complexity and is more costly in the long term. Whether or not to incur technical debt is a tradeoff
decision that ideally is made in a deliberate manner at the point that work occurs.

20.6 * Technical Story

20.7 Test Automation

"The use of software to control the execution of tests, the comparison of actual outcomes to predicted
outcomes, the setting up of test preconditions, and other test control and test reporting function."
(Wikipedia)

In agile development, test automation is frequently used to automate unit tests, integration tests, and
functional tests. Since the definition of done for most agile projects requires that code be thoroughly tested
by the end of the iteration, test automation is critical if not necessary to obtain acceptable velocity. In
addition, for most practical purposes, test automation is necessary to effectively apply continuous
integration and remain true to the commitment to not "break the build."

20.8 Test-Driven Development

"Test-Driven Development is a software development process that relies on the repetition of a very short
development cycle: first the developer writes a failing automated test case that defines a desired
improvement or new function, then produces code to pass that test and finally refactors the new code to
acceptable standards." (Wikipedia)

Ken Beck is credited for having invented TDD, one of the original 12 XP practices.

20.10 * Tracer Bullet

Return To Glossary

20.11 * Transparency
Return To Glossary

www.cprime.com 50
Encyclopedia of Agile Terminology

20.12 * Tuckman Model

References: Wikipedia, TeamTechnology, TuckmansTeamDevelopmentModel.pdf

Return To Glossary

21 U
21.1 Unit Testing
"A unit is the smallest testable part of a software system. In procedural programming, a unit may be an
individual function or procedure." (Wikipedia)

Comprehensive unit test coverage is an important part of software integrity and should be automated to
support the incremental delivery requirements of agile software development teams. In most cases, unit
testing is the responsibility of the developer.

21.2 User Story

A requirement, feature and/or unit of business value that can be estimated and tested. Stories describe
work that must be done to create and deliver a feature for a product. Stories are the basic unit of

www.cprime.com 51
Encyclopedia of Agile Terminology

communication, planning, and negotiation between the Scrum Team, Business Owners, and the Product
Owner. Stories consist of the following elements:

i. A description, usually in business terms

ii. A size, for rough estimation purposes,
1. generally expressed in story points (such as 1, 2, 3, 5)
iii. An acceptance test, giving a short description of how the story will be validated

See Also: Story, Technical Story, Defect, Spike, Tracer Bullet, INVEST

References: Wikipedia

Return To Glossary

22 V
22.1 Velocity
Velocity measures how much work a team can complete in an iteration. Velocity is often measured
in stories or story points. Velocity may also measure tasks in hours or an equivalent unit. Velocity is used
to measure how long it will take a particular team to deliver future outcomes by extrapolating on the
basis of its prior performance. This works in Agile development, when work is comprehensively
completed after each iteration.

References: Wikipedia

Return To Glossary

22.2 * Velocity Tracking

Return To Glossary

22.3 Vision
See Product Vision

Return To Glossary

www.cprime.com 52
Encyclopedia of Agile Terminology

22.4 Voice of the Customer (VOC)

"Voice of the Customer (VOC) is a term used in business and Information Technology (through ITIL) to
describe the in-depth process of capturing a customer's expectations, preferences, and aversions.
Specifically, the Voice of the Customer is a market research technique that produces a detailed set of
customer wants and needs, organized into a hierarchical structure, and then prioritized in terms of
relative importance and satisfaction with current alternatives." (Wikipedia)

References: Wikipedia

Return To Glossary

23 W
23.1 Wiki
An editable intranet site where details of stories and tracking information may be recorded during
development.

References: Wikipedia

Return To Glossary

23.2 * WIP
See Work inProgress.

Return To Glossary

23.3 * Work Breakdown Structure

Return To Glossary

23.4 Work in Progress (WIP)

Any work that has not been completed but that has already incurred a capital cost to the organization.
Any software that has been developed but not deployed to production can be considered a work in
progress.

References: Wikipedia

Return To Glossary

www.cprime.com 53
Encyclopedia of Agile Terminology

24 X
24.1 XP
See: Extreme Programming

Return To Glossary

25 Y
25.1 * YAGNI
You Aint Gonna Need It (yet)

Return To Glossary

25.2 * YAGRI
You Aint Gonna Release It (yet)

Return To Glossary

26 Z

www.cprime.com 54
Resources: Articles & White Papers

26.1 Reference Articles and Papers

The following are links and abstracts relating to various articles and blogs found on the web. This
collection of articles were chosen for their value and importance to Agile Software Development.

Agile Architectures
Return To Glossary

26.1.1 Agile Architecture

by Chris Sterling @ SolutionsIQ, CST
by Mickey Phoenix @ SolutionsIQ, CSM

As companies begin to embrace Agile methods, questions about architecture begin to emerge. In
this presentation, learn about the approaches two experts took to better align businesses with
architecture goals.

Distributed Scrum
Return To Glossary

26.1.2 Successful Distributed Agile Team Working Patterns

by Monica Yap @ SolutionsIQ, CSM

Explore some common successful distributed team working patterns that have been used on
distributed Agile development projects in this white paper and related presentation.

26.1.3 Case Study: Implementing Distributed Extreme Programming

by Monica Yap @ SolutionsIQ, CSM

This white paper details the challenges a team at WDSGlobal faced in a distributed development
environment, lessons learned, and how issues such as global continuous integration, cultural
differences, and conflicting priorities were resolved across regions.

26.1.4 Daily Scrums in a Distributed World

by Kevin Thompson @ cPrime.com, CSM, CSP, PMP, PhD

Meta-Scrum
Return To Glossary

55
Resources: Articles & White Papers

26.1.5 Establishing and Maintaining Top to Bottom Transparency Using Meta-Scrum

by Brent Barton @ SolutionsIQ, CST

Learn how a properly executed Meta-Scrum helps drive transparency vertically into the
organization in this Agile Journal article.

Agile Adoption
Return To Glossary

26.1.6 Introduction to Scrum

by Kevin Thompson @ cPrime.com, CSM, CSP, PMP, PhD

The benefits and practices of Scrum

26.1.7 Scrum as Project Management

by Kevin Thompson @ cPrime.com, CSM, CSP, PMP, PhD

Comparing and Contrasting Scrum to Traditional Project Management

26.1.8 The Agile Story: Scrum Meets PMP

by Crystal Lee @ cPrime, PMP, CSM

Do you know what a Scrum is? Wondering if you should try Scrum on your next project?

26.1.9 When to Use Scrum

by Kevin Thompson @ cPrime.com, CSM, CSP, PMP, PhD

Scrum is a lightweight agile process framework used primarily for managing software
development.

26.1.10 Agile Top-Down: Striking a Balance

by Bryan Stallings @ SolutionsIQ, CST

Agile is being evangelized in executive boardrooms and introduced top-down with increasing
frequency. Learn about the appropriate role of senior leadership in an effective Agile
transformation in this Agile Journal article.

56
Resources: Articles & White Papers

26.1.11 Agile ROI Part I: The Business Case for Agility

by John Rudd @ SolutionsIQ

This Agile Journal article describes some of the financial benefits of adopting Agile and how to
quantify the potential value of these innovative practices for your organization. Learn how Agile
methods can help financial professionals squeeze money out of work-in-process, drive risk out of
projects, and improve project and portfolio return.

26.1.12 Agile ROI Part II: The Business Case for Agility
by David Wylie @ SolutionsIQ

This presentation explores how to quantify the potential value of Agile practices for your
organization and how to demonstrate this value for key decision makers.

26.1.13 Scrum in the Enterprise

by Kevin Thompson @ cPrime.com, CSM, CSP, PMP, PhD

"Scrum in the Enterprise" is a white paper written by Kevin Thompson, one of cPrime's Agile
Implementation Specialists. The paper talks about the common issues that companies face while
making the transition to Agile Development, while explaining how to prepare for and overcome
them. Kevin writes about topics from how to use Scrum in a hybrid environment to how to
collaborate in Scrum teams. This white paper will interest and benefit anyone who is involved
with Agile projects or just interested in the methodology.

26.1.14 How Uncertainty Works

by Kevin Thompson @ cPrime.com, CSM, CSP, PMP, PhD

Why it exists, how it behaves, how it accumulates, how to reduce it, and how to cope with it.

26.1.15 The Price of Uncertainty

by Kevin Thompson @ cPrime.com, CSM, CSP, PMP, PhD

A Mathematical Analysis of Classic and Agile Processes

Proponents of agile development processes, such as Scrum, frequently claim that agile projects
are more likely to be successful than traditional plan-driven projects. Unfortunately, attempts to
validate this claim based on statistical evidence are difficult. The difficulty arises partly because
the two approaches have different concepts of success, and partly because definitions of success

57
Resources: Articles & White Papers

are not uniform even within each approach. This paper addresses the question by performing a
simple mathematical analysis of plan-driven and agile projects.

26.1.16 How Agile should your Project be?

by Kevin Thompson @ cPrime.com, CSM, CSP, PMP, PhD

Advocates of agile development claim that agile software projects succeed more often than classic
plan-driven projects. Unfortunately, attempts to validate this claim statistically are problematic,
because "success" is not defined consistently across studies. This paper addresses the question
through a mathematical analysis of these projects. We model agile and plan-driven software
projects with identical requirements, and show how they are affected by the same set of
unanticipated problems. We find that that the agile project provides clear benefits for return-on-
investment and risk reduction, compared to the plan-driven project, when uncertainty is high.
When uncertainty is low, plan-driven projects are more cost-effective. Finally, we provide
criteria for choosing effective process types.

26.1.17 Integrating Waterfall and Agile Development

by Shayan Alam @ cPrime.com, PMP

Use these tips to help integrate both methodologies into your development organization.

26.1.18 Rational Unified Process Best Practices

by Crystal Lee @ cPrime.com, PMP,

Provide background on each best practice, in the context of current RUP adoption.

26.1.19 Effective Retrospectives

by Kendrick Burson @ cPrime.com, CSM, CSPO

A better understanding of Team Retrospectives with plenty of examples of different patterns for
facilitating.

26.1.20 Transitioning From Time-Based to Relative Estimation

by Ilan Goldstein @ ScrumAlliance.org, CSM, CSPO, CSP

Congratulations! You’ve finally convinced the team that relative story point estimation is a great
way to move forward and you’re now ready to jump into your first planning poker session. So

58
Resources: Articles & White Papers

where do you start? What’s a 1-point story? What’s a 3-point story? What’s a 13-point story? Your
team is looking to you and this process is almost as new to you as it is to them.

Most of the issues with gathering requirements in agile software development and agile testing
derive from issues with User Stories. Somehow expressing requirements in such a simple form
causes a lot of trouble to agile teams. Of course art of writing good User Stories is the most difficult
for new teams starting with a new agile project or these, which freshly transformed
development methods to agile software development methodologies. Mistakes made at that point
lead to wrong Test Cases, wrong understanding of requirements, and the worst of all wrong
implementation which can be direct cause of rejecting the deliverables of the iteration. Lets take a
look at the five most common mistakes people make writing User Stories.

26.1.21 5 Common Mistakes We Make Writing User Stories

by Krystian Kaczor @ ScrumAlliance; CSM, CSP

26.1.22 Agile Project Dashboards

Bringing value to stakeholders and top management

by Leopoldo Simini @ ScrumAlliance; CSM, CSP

“Scrum is all about delighting customers and delivering value to stakeholders.” I have read this
kind of statement since my first day working with Scrum in 2007. Even more, I’ve had the
privilege of taking part on Scrum teams th...

59
Resources: Articles & White Papers

26.1.23 Daily Stand-up, Beyond Mechanics: A Measure of Self-Organization

by Bachan Anand CSM, CSPO, CSP

26.1.24 Affinity Estimation for Release Planning

by Monica Yap @ SolutionsIQ

26.1.25 Managing Risk in Scrum, Part 1

by Valerie Morris @ SolutionsIQ

26.1.26 Product Owner Anti-Patterns

by Monica Yap @ SolutionsIQ

Part 1: The Absent Product Owner

Part 2: The Churning Backlog

Part 3: No Single Product Owner

Part 4: Copy the Old One

26.1.27 Card-Conversation-Confirmation
by Ron Jeffries, 2001

XP Practices for generating a well groomed backlog, elaborating story contents and validating
completed results.

“User stories have three critical aspects. We can call these Card, Conversation, and Confirmation.”

Ron Jeffries, 2001

26.1.28 Recognizeing Bottlenecks in Scrum

by Dhaval Panchal @ SolutionsIQ, CST

Part 1

Part 2

60
Resources: Articles & White Papers

26.1.29 If At First You Don't Succeed, Fail, Fail Again

by Michael Tardiff @ SolutionsIQ, CSM, CSPO

26.1.30 What is the Definition of Done (DoD) in Agile?

by Dhaval Panchal @ SolutionsIQ, CST

DoD is a collection of valuable deliverables required to produce software.

DoD is the primary reporting mechanism for team members.

DoD is informed by reality.

DoD is not static

DoD is an audit-able checklist.

26.1.31 How Should We Deal With the Mess That Scrum Exposes?
by Monica Yap @ SolutionsIQ, CSM, CSPO

Part 1 of 5) How Should We Deal With the Mess That Scrum Exposes?

Part 2 of 5) Scrum Exposes the Mess With No Quality Built In

Part 3 of 5) Scrum Exposes the Mess of Unstable Code Base

Part 4 of 5) Scrum Exposes the Mess of Excess Specialists

Part 5 of 5) The Mess That Scrum Exposes: Putting It All Together

26.1.32 The Afternoon ScrumMaster: Keeping Agile Teams on Track

by Dhaval Panchal @ SolutionsIQ

26.1.33 The Short Short Story

by Paul Dupuy @ ScrumAlliance; CSM

The short short story: How long does it have to be? Scrum teams often use user stories for backlog
items. Unfortunately, one of the most important aspects of a story—its extremely short length—
has been subtly transformed over time, an...

61
Resources: Articles & White Papers

26.1.34 Is Sustainable Pace Nice to Have? Think Again!

by Manoj Vadakkan CSM, CSP

Most of the time, “selling” Agile is easy these days. Everyone agrees that iterative and
incremental development is a better alternative; more user interaction is better; so on and so
forth. At some point, I will talk about the import...

26.1.35 Agile User Interface Design and Information Architecture From the Trenches
by Robin Dymond @ ScrumAlliance; CSM, CSP, CST

I was a Technology Director in a large web design company 6 years ago, and they failed to adopt
Scrum. There were numerous management dysfunctions; however the Creative managers were
the most resistant. Primarily, it was a case of not wanting real...

26.1.36 Why Agile Does Matter in an Embedded Development Environment

by Bent Myllerup @ ScrumAlliance; CSM, CSPO, CSP, CSC

The software industry has achieved great results by introducing agile methods like Scrum. Agile
methods create outcomes that benefit customers as well as management and employees of the
business. The results have been proven in the form of increas...

26.1.37 The Illusion of Precision

by Jim Schiel @ ScrumAlliance; CSM, CSP, CST

For me, one of the most intriguing, yet not explicitly stated, fundamentals of AgileDevelopment is
the practice of analyzing and designing just enough of what we are planning to build that we can
then move forward to build it. You can find specifi...

26.1.38 Specialization and Generalization in Teams

by Bas Vodde @ ScrumAlliance; CSM, CSPO, CSP, CST

Specialization in Scrum has been a hot topic for many years and pops up at every Scrum course I
run. It is an important issue that’s particularly relevant for a new team in their first Sprint.
Scrum defines specialization as a cross-functio...

62
Resources: Articles & White Papers

26.1.39 The Importance of Self-Organisation

by Geoff Watts @ ScrumAlliance; CSM, CSP, CSC, CST

"An empowered organization is one in which individuals have the knowledge, skill, desire, and
opportunity to personally succeed in a way that leads to collective organizational success." --
Stephen R. Covey, Principle-centered Leadership

26.1.40 Manager 2.0: The Role of the Manager in Scrum

by Pete Deemer @ ScrumAlliance; CSM, CSP, CST

63
Bibliography

Agile Terminology Guide for PMP Prep
No ratings yet
Agile Terminology Guide for PMP Prep
28 pages
Chapter 10 Intro To Agile
No ratings yet
Chapter 10 Intro To Agile
39 pages
Agile Project Management (Keywords Review)
No ratings yet
Agile Project Management (Keywords Review)
15 pages
Introduction To Agile and Scrum
100% (1)
Introduction To Agile and Scrum
65 pages
Agile Cheat Sheet
No ratings yet
Agile Cheat Sheet
1 page
Agile
No ratings yet
Agile
3 pages
Agile Project Management - Scrum Framework
No ratings yet
Agile Project Management - Scrum Framework
4 pages
Prabin Sepm Report
No ratings yet
Prabin Sepm Report
15 pages
Document 61
No ratings yet
Document 61
3 pages
Agile Terms
No ratings yet
Agile Terms
27 pages
AGILE - Methodology July 2017 Srinivas-Kothuri
100% (2)
AGILE - Methodology July 2017 Srinivas-Kothuri
23 pages
Methodologies Agile-Scrum (Elias Hajjar)
No ratings yet
Methodologies Agile-Scrum (Elias Hajjar)
30 pages
Agile Software
No ratings yet
Agile Software
57 pages
An Introduction To AGILE
No ratings yet
An Introduction To AGILE
43 pages
Agile Glossory
No ratings yet
Agile Glossory
15 pages
Manifesto
No ratings yet
Manifesto
56 pages
Agile Methodology Overview
No ratings yet
Agile Methodology Overview
9 pages
UNIT 1 Agile
No ratings yet
UNIT 1 Agile
76 pages
Agile Scrum Certification Guide
No ratings yet
Agile Scrum Certification Guide
2 pages
Agile 11x17 PDF
No ratings yet
Agile 11x17 PDF
2 pages
Unit 1: Agile: Randula Tharaka
No ratings yet
Unit 1: Agile: Randula Tharaka
37 pages
SPM Agile Project Management
No ratings yet
SPM Agile Project Management
25 pages
Agile
100% (1)
Agile
24 pages
CEN512 Agile Software Engineering-Module 2
No ratings yet
CEN512 Agile Software Engineering-Module 2
41 pages
Saschaf - Agile Development Buzz Words
No ratings yet
Saschaf - Agile Development Buzz Words
4 pages
Scrum - Quick Guide Scrum - Overview
No ratings yet
Scrum - Quick Guide Scrum - Overview
19 pages
Agile Methods for Software Teams
No ratings yet
Agile Methods for Software Teams
16 pages
Agile Terms
No ratings yet
Agile Terms
36 pages
Agile Terms for Practitioners
No ratings yet
Agile Terms for Practitioners
36 pages
Unit-2 Software Engineering
No ratings yet
Unit-2 Software Engineering
28 pages
Agile Methodology, Values & Principles
100% (1)
Agile Methodology, Values & Principles
121 pages
ASD Unit 1
No ratings yet
ASD Unit 1
89 pages
Agile Methodology: Janessa Marielle Cruz
100% (1)
Agile Methodology: Janessa Marielle Cruz
34 pages
Agile Cheatsheet
No ratings yet
Agile Cheatsheet
17 pages
Agile - Scrum Methodologies
No ratings yet
Agile - Scrum Methodologies
2 pages
1 Agile Methodology
No ratings yet
1 Agile Methodology
19 pages
Agile Scrum Methodology-Final - Sastry
No ratings yet
Agile Scrum Methodology-Final - Sastry
34 pages
Module 1and2
No ratings yet
Module 1and2
331 pages
Pelclova MastersThesis
No ratings yet
Pelclova MastersThesis
75 pages
Agile Project Management Guide
100% (1)
Agile Project Management Guide
291 pages
Scrum 1
No ratings yet
Scrum 1
37 pages
Aaron A. Blair - Agile Project Delivery - A Practical Approach For Corporate Environments Beyond Software Development (2020)
No ratings yet
Aaron A. Blair - Agile Project Delivery - A Practical Approach For Corporate Environments Beyond Software Development (2020)
294 pages
Agile Scrum
No ratings yet
Agile Scrum
32 pages
Agile Methods
No ratings yet
Agile Methods
7 pages
CodeBeamer ALM Agile Software Development Guide
No ratings yet
CodeBeamer ALM Agile Software Development Guide
17 pages
Agile Summary
No ratings yet
Agile Summary
6 pages
43 Popular Agile
No ratings yet
43 Popular Agile
45 pages
Agile
No ratings yet
Agile
32 pages
Scrum - Overview: Waterfall Model
100% (1)
Scrum - Overview: Waterfall Model
27 pages
Agile Scrum for Professionals
100% (1)
Agile Scrum for Professionals
178 pages
Agile Insights for Scrum Masters
75% (4)
Agile Insights for Scrum Masters
20 pages
Module - 2 - Agile Framework - Ch1
No ratings yet
Module - 2 - Agile Framework - Ch1
16 pages
Agile Practices Presentation
No ratings yet
Agile Practices Presentation
15 pages
Week21LectureAgileDevelopment Cb12c27e Da8a 4ccb 8c1e 6ec23ecdac5d 109054
No ratings yet
Week21LectureAgileDevelopment Cb12c27e Da8a 4ccb 8c1e 6ec23ecdac5d 109054
33 pages
Agile Methodology1
No ratings yet
Agile Methodology1
32 pages
Agile & Scrum Basics for Beginners
No ratings yet
Agile & Scrum Basics for Beginners
15 pages
7 Popular Project Management Methodologies - Zenkit
No ratings yet
7 Popular Project Management Methodologies - Zenkit
1 page
100 - CSM - Interview Questions With ANSWERS - PM
No ratings yet
100 - CSM - Interview Questions With ANSWERS - PM
17 pages
Agile Exam Questions and Ans 1 PDF Scrum (Software Development) Agile Software Development 3
No ratings yet
Agile Exam Questions and Ans 1 PDF Scrum (Software Development) Agile Software Development 3
2 pages
Agile Development Process Guide
No ratings yet
Agile Development Process Guide
80 pages
Dzone Researchguide Automatedtesting
No ratings yet
Dzone Researchguide Automatedtesting
41 pages
Full Comparison - Agile Vs Scrum Vs Waterfall Vs Kanban
No ratings yet
Full Comparison - Agile Vs Scrum Vs Waterfall Vs Kanban
21 pages
Secure Resilient and Agile Software Development Instant Download
100% (1)
Secure Resilient and Agile Software Development Instant Download
133 pages
DM 200 Agile Questions
0% (1)
DM 200 Agile Questions
6 pages
Multiple Choice Question On Agile and Extreme Model
No ratings yet
Multiple Choice Question On Agile and Extreme Model
8 pages
Spiral Model Is A Risk-Driven Software Development Process
No ratings yet
Spiral Model Is A Risk-Driven Software Development Process
4 pages
Safe 5.0
No ratings yet
Safe 5.0
13 pages
Framework for Comparing SDMs
No ratings yet
Framework for Comparing SDMs
9 pages
CIS201 Exam Review Guide
No ratings yet
CIS201 Exam Review Guide
5 pages
TFM Esquivel Romero 2020
No ratings yet
TFM Esquivel Romero 2020
82 pages
Assignment 2
No ratings yet
Assignment 2
7 pages
Education Personal Statement Work Experience Career Growth: Principal Software Engineer Scrum Master
No ratings yet
Education Personal Statement Work Experience Career Growth: Principal Software Engineer Scrum Master
1 page
Computer Assignment
No ratings yet
Computer Assignment
2 pages
Reference For PPT RADTAC ABC2011 Designing and Implementing A Successful Agile Transformation
No ratings yet
Reference For PPT RADTAC ABC2011 Designing and Implementing A Successful Agile Transformation
48 pages
RAD Model
No ratings yet
RAD Model
6 pages
3 Chapter - 03 Agile Development
No ratings yet
3 Chapter - 03 Agile Development
27 pages
AnkiDroid Open Source Development in Android
No ratings yet
AnkiDroid Open Source Development in Android
133 pages
Agile Method: By: Jairus Delos Reyes Sam CJ Sanchez JR
No ratings yet
Agile Method: By: Jairus Delos Reyes Sam CJ Sanchez JR
22 pages
Scrum Master Training Content
No ratings yet
Scrum Master Training Content
13 pages
DEVASC Module 3
No ratings yet
DEVASC Module 3
87 pages
SIA Unit1 Questions
No ratings yet
SIA Unit1 Questions
2 pages
Xcrum Agile Integration Team20
No ratings yet
Xcrum Agile Integration Team20
18 pages
SAD Models
No ratings yet
SAD Models
11 pages
Features of Software Development Lifecycle - SDLC Solutions
No ratings yet
Features of Software Development Lifecycle - SDLC Solutions
1 page
It13102: Software Engineering (3 1 0 4)
No ratings yet
It13102: Software Engineering (3 1 0 4)
8 pages