Agile Flashcards
1
Q
ACP
A
Agile Certified Practitioner
2
Q
Acceptance Test-Driven Development
A
A method used to communicate with business customers, developers, and testers before coding begins.
3
Q
Adaptive Leadership
A
A leadership style that helps teams to thrive and overcome challenges throughout a project.
4
Q
Agile
A
To develop a goal through periodic experimentation in order to fulfill the need of a complex decision.
5
Q
Affinity Estimation
A
A method used to quickly place user stories into a comparable-sized group.
6
Q
Agile Adaption
A
To adapt the project plan continuously through retrospectives in order to maximize value creation during the planning process.
7
Q
Agile Coaching
A
To help achieve goals that are either personal or organizational.
8
Q
Agile Experimentation
A
To use the empirical process, observation, and spike introduction while executing a project to influence planning.
9
Q
Agile Manifesto
A
A statement that reflects Agile Philosophy that includes: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to changes over following a plan.
10
Q
Agile Manifesto Principles
A
A document that describes the twelve principles of the Agile Manifesto.
-Customer satisfaction
-Welcome changes
-Frequent delivery
-collocated team
-motivated individuals
-face to face conversatoin
-working software
-constant pace
-continuous attention
-simplicity
-self-organization
-regular reflection
11
Q
Agile Manifesto: Customer Satisfaction
A
To satisfy customers through early and continuous delivery of products, to test and receive feedback, to inform customers on progress, and to fulfill the customer’s value by completing priority requirements.
12
Q
Agile Manifesto: Welcome Changes
A
To allow quick responses to changes in the external environment, and late in development to maximize the customer’s competitive advantage.
13
Q
Agile Manifesto: Frequent Delivery
A
To deliver software frequently to the customer, allowing for a quicker product release, faster provision of value to the customer and shorter delivery timeframe.
14
Q
Agile Manifesto: Collocated Team
A
To have individuals work together daily on a project to implement osmotic communication, focus, and receive instant feedback to achieve a common goal.
15
Q
Agile Manifesto: Motivated Individuals
A
To give individuals the empowerment, environment, support, and trust needed to complete a task successfully.
16
Q
Agile Manifesto: Face-to-Face Conversation
A
The most efficient and effective way to communicate in order to receive direct feedback and influence osmotic communication.
17
Q
Agile Manifesto: Working Software
A
Working software enables the measurement of progress, enhances customer satisfaction, and maintains and improves the quality of the software to help support project goals.
18
Q
Agile Manifesto: Constant Pace
A
To help team members establish a healthy work-life balance, remain productive, and respond to changes swiftly for progress during a project.
19
Q
Agile Manifesto: Continuous Attention
A
To enhance agility and time spent on work requirements in order to retain a well-balanced work environment.
20
Q
Agile Manifesto: Simplicity
A
Allows team members to focus on what is necessary to achieve the requirements needed to create and deliver value to the project and customer.
21
Q
Agile Manifesto: Self-Organization
A
A team that knows how to complete tasks effectively, has dedication to the project and is an expert on the process and project.
22
Q
Agile Manifesto: Regular Reflection
A
This allows a team to learn how to become more effective, what changes need immediate implementation, and behavior that needs adjustment.
23
Q
Agile Mentoring
A
To pass on and teach based on experience, knowledge, and skills to other individuals in the team or that work for the organization.
24
Q
Agile Methodologies
A
A way to complete a goal effectively and efficiently. Examples of Agile Methodologies include XP, Scrum, and Lean.
25
Agile Modeling
A workflow depiction of a process or system a team can review before it is turned into code. Stakeholders should understand the model.
26
Agile Planning
The most important aspect of the Agile project. Planning happens at multiple levels such as strategic, release, iteration, and daily. Planning must happen up-front and can change throughout the project.
27
Agile Smells
Symptoms of problems that affect Agile teams and projects.
28
Agile Space
A space that allows team members to establish collaboration, communication, transparency, and visibility.
29
Agile Themes
Themes used to help the team focus on the functions of iteration.
30
Agile Tooling
To increase team morale with software or artifacts.
31
Analysis
To develop possible solutions by studying the problem and its underlying need and to understand the information provided.
32
Approved Iterations
After the deadline of iteration is reached, the team and stakeholders conduct a meeting for approval. Stakeholders approve the iteration if the backlog used supports the product increment.
33
Architectural Spikes
Spikes that relate to any area of a system, technology, or application domain that is unknown.
34
Artifact
A process or work output Ex. Document, Code
35
Adaptive Software Development (ASD)
Exhibits continuous adaptation to the project and its processes with characteristics that include: mission-focused, feature-based, iterative, time-boxed, risk-driven, and change tolerant.
36
Automated Testing Tools
These tools allow for efficient and strong testing. Examples: Peer Reviews, Periodical Code-Reviews, Refactoring, Unit Tests, Automatic and Manual Testing.
37
Burn-Down Chart
A chart used to display progress during and at the end of an iteration. “Burning down” means the backlog will lessen throughout the iteration.
Burn rate = cost per iteration.
38
Burn-Up Chart
A chart that displays completed functionality. Progress will trend upwards, as stories are completed. Only shows complete functions, it is not accurate at predicting or showing work-in-progress.
39
CARVER
An acronym to measure the goals and mission of the project with each letter meaning: Criticality, Accessibility, Return, Vulnerability, Effect, and Recognizability.
40
Ceremony
A meeting conducted during an Agile project that consists of daily stand-up, iteration planning, iteration review, and iteration retrospective.
41
Chicken
An individual involved but not committed to an Agile project.
42
Collective Code Ownership
The entire team together is responsible for 100% of the code.
43
Common Cause
An issue solved through trend analysis because the issue is systematic.
44
Command & Control
Decisions created by higher-up individuals in the organization and handed over to the team.
45
Cone of Silence
An environment for the team that is free of distractions and interruptions.
46
Continuous Integration
To consistently examine a team member’s work. To build, and test the entire system.
47
Cross-Functional Team
Teams that consist of members who can multi-task well and complete various functions to achieve a common goal.
48
Crystal Family
An adaptable approach that focuses on the interaction between people and processes that consists of families that vary based on team size, system criticality, and project priorities.
49
Cumulative Flow Diagram
A chart that displays feature backlog, work-in-progress, and completed features.
50
Customer-Valued Prioritization
To deliver the maximum customer value early in order to win customer loyalty and support.
51
Cycle Time
The time needed to complete a feature (user story).
52
Daily Stand Up
A brief meeting where the team shares the previous day’s achievements plans to make achievements, obstacles, and how to overcome the obstacles.
53
Decide As Late As Possible
To postpone decisions to determine possibilities and make the decision when the most amount of knowledge is available.
54
DEEP
The qualities of a product backlog include: detailed, estimate-able, emergent, and prioritized.
55
Disaggregation
To separate epics or large stories into smaller stories.
56
Distributive Negotiation
To reach a deal through tactics so both parties receive the highest amount of value possible.
57
Done
When work is complete and meets the following criteria: complies, runs without errors, and passes predefined acceptance and regression tests.
58
Dynamic Systems Development Model (DSDM)
A model that provides a comprehensive foundation for planning, managing, executing, and scaling agile and iterative software development projects based on nine principles that involve business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration.
59
Earned Value Management (EVM)
Earned Value Management, works well at iteration. It is a method to measure and communicate progress and trends at the current stage of the project.
60
Emergent
Stories that grow and change over time as other stories reach completion in the backlog.
61
Epic Story
A large story that spans iterations then disaggregated into smaller stories.
62
Escaped Defects
Defects reported after the delivery by the customer.
63
Expectancy Theory
An individual chooses to behave in a particular way over other behaviors because of the expected results of the chosen behavior.
64
Exploratory Testing
To inquire how the software works with the use of test subjects using the software and asking questions about the software.
65
Extreme Persona
A team-manufactured persona that exaggerates to induce requirements a standard persona may miss.
66
eXtreme Programming (XP)
A methodology in Agile with one-week iterations and paired development.
67
Feature-Driven Development (FDD)
A comprehensive model and list of features included in the system before the design work begins.
68
Feature
A group of stories that deliver value to the customers.
69
Fibonacci Sequence
The traditional Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21, 34, and so on. In Agile projects, this sequence is modified. The modified Fibonacci sequence is 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 - it is used to estimate the relative size of User Stories in terms of Story Points.
70
Finish Tasks One by One
Tasks must be finished in all iterations to meet the “Definition of Done” requirements as a way to track progress and allow frequent delivery.
71
Fishbone Diagram
A root cause diagram.
72
Five Whys
The root causes analysis technique that asks WHY five times. The problem is looked into deeper each time WHY is asked. Toyota developed this technique.
73
Fixed Time Box
Assigned tasks prioritized for completion based on an estimated number of days. Top priorities are usually completed first.
74
Force Field Analysis
To analyze forces that encourage or resist change.
75
Grooming
To clean up the product backlog by removal of items, disaggregation of items, or estimation of items.
76
High-Bandwidth Communication
Face-to-face communication also includes non-verbal communication.
77
High Performing Team
This team reaches maximum performance by creating of clear, detailed goals, open communication, accountability, empowerment, use of the participatory decision model, and the team consists of twelve dedicated members or fewer.
78
Ideal Time
The amount of time needed to complete an assignment without distractions or interruptions.
79
Information Radiator
Artifacts used to help maintain transparency of project status to team members and stakeholders.
80
Information Refrigerator
Information that is not transparent or useful to the team and stakeholders.
81
Innovation Games
A practice used to induce requirements from product, owners, users, and stakeholders.
82
Integrative Negotiation
To reach an agreement collaboratively that creates more value for both parties by a win-win solution. 0
83
Interaction
Face to face comms
84
IRR
Internal Rate of Return- a discount rate that makes the net present value of all cash flows from a project equal to zero. Used to determine the potential profitability of project or investment.
85
Intraspectives
To inspect within, during a meeting with the Agile team to review practices, usually when a problem or issue occurs.
86
Intrinsic Schedule Flaw
Poor estimation occurs at the beginning of the iteration.
87
INVEST
The benefits of good user stories, which include: Independent, Negotiable, Valuable, Estimate-able, Small, and Testable.
88
Iteration
Work cycle, Scrum uses 2-4 weeks, XP uses 1 week.
89
Iteration Backlog
Work to complete in a particular iteration.
90
Iteration H
Iteration used to prepare the launch of software and to test software.
91
Iteration 0
Iteration to complete tasks before the development work occurs, for technical and architectural spikes, and to gather requirements into the backlog.
92
Iteration Retrospective
A meeting used in Scrum, the team discusses ways to improve after work is completed.
93
Just-In-Time
Used to minimize inventory cost by materials delivered before they are required.
94
Kaizen
Based on Japanese management philosophy, to continuous improvement through small releases.
95
Kanban
A signal used to advance transparency of work-in-progress, a new task can begin once a previous one is complete.
96
Kanban Board
A chart that shows workflow stages to locate work-in-progress.
97
Kano Analysis
An analysis of product development and customer satisfaction based on needs fulfilled/not fulfilled vs. satisfaction/dissatisfaction.
98
Last Responsible Moment
To make decisions as late as possible in order to preserve all possible options.
99
Lean Methodology
To eliminate waste, an Agile method derived from manufacturing.
100
Little’s Law
The law limits work-in-progress efficiently with the development of an appropriate cycle time.
101
Low Performing Team
This team has a lack of trust, no accountability, fear of conflict, less commitment, and less attention to details and results.
102
Lean Software Development (LSD)
This methodology focuses on the “Value Stream” to deliver value to customers. The goal is to eliminate waste by focusing on valuable features of a system and to deliver value in small batches. Principles of Lean include: elimination of waste, amplify learning, to decide late as possible, deliver as fast as possible, empowerment the team, building integrity, and seeing the whole.
103
Minimal Viable Product (MVP)
A product with only the essential features delivered to early adopters to receive feedback.
104
Minimal Marketing Feature (MMF)
The smallest feature of a product that provides value to the end-user.
105
Monopoly Money
To give fake money to business features in order to compare the relative priority of those features.
106
MoSCoW Analysis
An analysis used to help stakeholders understand the importance of each requirement delivered. MoSCoW is the acronym for Must have, Should have, Could have, and Would like to have.
107
Osmotic Communication
To communicate by sharing an environment.
108
Pair Programming
When developers work together in XP Practice
109
Pareto Principle
Known as the 80/20 rule. For Agile projects, it means that 80% of all development should be spent on the top 20% of the features the customers need.
110
Participatory Decision Models
To have stakeholder’s involvement in decision-making with techniques such as a simple vote.
111
Persona
A depiction of the customer of the system with applicable details about usage.
112
Pig
A committed individual impacted by the outcome.
113
Plan-Do-Check-Act
Work cycle in smaller, quick iterations than traditional.
114
Planning Game
To prioritize work and estimate effort required by the creation of a release plan in XP.
115
Planning Poker
A tool used to estimate team effort on user stories.
116
Positive Value
To maximize value through incremental work in order to gain a competitive advantage.
117
Pre-Mortem
Team members asked to define reasons for a project’s failure and to identify causes of failure missed in previous analyses.
118
Productivity Variation
The difference between the planned and actual performance.
119
Product Backlog
The known features for a project.
120
Product Vision
A document that describes what the product is, who will use the product, why the product will be used, and how the product supports the strategy of a company.
121
Refactoring
To adjust working code to improve functionality and conservation.
122
Relative Prioritization
A list of all user stories and features ordered by highest priority to the lowest priority.
123
Relative Sizing
To estimate the size of a story in comparison with another story.
124
Requirements at a High Level
Requirements are in the form of user stories and collected at a high level to estimate a budget.
125
Requirements Prioritization Model
A model to rate each feature with the calculation of the weighted formula defined by the team.
126
Requirements Review
To review the requirements so they fulfill the needs and priorities of stakeholders.
127
Risk-Adjusted Backlog
A product backlog adjusted to help balance the risk and value factors of the product.
128
Risk-Based Spike
This spike helps the team remove major risks, and if the spike fails every approach possible, the project is defined as “fast failure”.
129
Risk Burn Down
A chart that displays risk and success with feature vs. time.
130
Risk Impact
To analyze the consequences of the risk if they occur based on their probability.
131
Risk Severity
How much the risk’s consequences will influence the success or failure of a project. Risk Probability (%) x Risk Impact ($) = Risk Severity
132
Rolling Wave Planning
To divide the planning phase into stages.
133
Scrum
A popular Agile methodology.
134
Scrum of Scrums
Meetings used to organize large projects with scrum masters from different teams.
135
Software Development Life Cycle (SDLC)
This cycle tends to be long and requires a lot of advanced planning.
136
Self-Directing Team
This team has the capability to make their own decisions, empowerment, mutual accountability, and collective ownership of a project, which leads them to be more productive and efficient.
137
Self-Organizing Team
Naturally formed teams that interact with minimal management supervision.
138
Shu-Ha-Ri Model
Originated in Japan as a way to understand learning and mastery, Shu – obeying the rules, Ha - consciously moving away from the rules, and Ri – consciously finding an individual path.
139
Special Cause
A cause that occurs once because of special reasons.
140
Specification Breakdown
This occurs when requirements for the specification are incomplete or conflicting.
141
Spike
An experiment that helps a team answer, a particular question and determines future actions.
142
Sprint
A consistent iteration that lasts from one week to one month in order to measure velocity in Scrum.
143
Sprint Plan
A document that explains sprint goals, tasks, and requirements and how the tasks will reach completion.
144
Sprint Retrospective
A team-member meeting occurs after each sprint to evaluate the product and process to improve efficiency and effectiveness.
145
Sprint Review
A meeting that occurs after each sprint to show the product or process to stakeholders for approval and to receive feedback.
146
Story Card
An index card that displays the user story.
147
Story Map
A prioritization tool that backlogged stories made smaller and organized by user functionality.
148
Story Point
A unit of measurement to estimate the difficulty of a user story.
149
Swarming
When the team collaborates to focus on a single user story.
150
Tabaka’s Model
A model originated in Japan to describe a team with values that include self-organization, empowered to make decisions, belief in vision and success, a committed team, trust, participatory decision making, consensus-driven, and construction disagreement.
151
Tasks
The smaller jobs to fulfill a user story, usually divided among team members.
152
Team Empowerment
A team that is empowered has collaboration, responsibility, and self-sufficiency.
153
Team Formation
Formation happens when a team creates ground rules and processes to build bonds and shared goals.
154
Team Participation
When the team discusses the requirements that will fulfill the customer’s needs.
155
Team Space
An area for team members to collocate, usually a physical location, in some cases a virtual location is created.
156
Team Velocity
The number of story points completed during iteration and used to determine the planned capacity.
157
Technical Debt
Technical decisions a team chooses to not implement currently, but must do so or face difficulty in the future.
158
Test-Driven Development (TDD)
A written acceptance test for a module with the code built to pass the tests in order to ensure correct performance.
Red - Green -
159
Tester
Explains acceptance test to the customers then consistently measures the product against the test and records results for the team. (XP Role)
160
Theme
A group of stories, iteration, or releases idea determined by the customer, and the team agrees with the idea.
161
Time-boxing
To set a fixed delivery date for a project or release.
162
Unit Testing
These tests are used for continuous feedback to achieve quality improvement and assurance.
163
Usability Testing
An exploratory test uses a test subject to understand the usability of the software.
164
Users Involvement
The active involvement of users in the development cycle of a project so team members can receive feedback about the user’s requirements.
165
User Story
At least one business requirement increases the value for the user.
166
Validation
The way to make sure that the product is acceptable to the customer.
167
Value-Based Prioritization
To allow the PO or customer to determine which function to implement first based on the value it delivers.
168
Value-Driven Delivery
To realize the values needed to deliver a project.
169
Value Stream Mapping
A tool used to analyze a chain of processes with the desired outcome of eliminating waste.
170
Velocity
The total number of features that a team delivers in an iteration.
171
Verification
To ensure the product meets requirements and specifications.
172
Waterfall
Resistant to change that requires heavy planning and a sequential, traditional approach.
173
Wide-Band Delphi Estimating
An estimation technique for user stories. The PO presents user stories & discusses challenges. Each story’s estimates plotted, and then the team comes to an agreement on the range of points.
174
WIP Limits
To limit work-in-progress so a team can do the following: maintain focus on completing work, maintaining quality, and delivering value.
175
Wireframe
A lightweight non-functional UI design that shows the customer the vital elements and how they will interact before coding.
176
WIP
Work-In-Progress- Stories that have started, which are displayed in workflows to show progress and what still needs to be completed.
177
Workflow
A series of phases or stages the team has agreed to execute for a project.
178
100-Point Method
A method that allows customers to score (total 100 points) different features of a product.
179
Agile Approaches and Methods
Kanban, scrum, XP, FDD, DSDM, AUP, and Crystal.
180
Definable Work
Clear procedures based on similar past projects
181
3 Cs of User Stories
Card, conversation, confirmation
182
Use Case Diagram
A use case model consists of a use case diagram and narrative text detailing the use cases. The diagram is a picture of the system, actors, and use cases. It contains the system boundary, called a boundary box, the actors, and the use cases.
183
Acceptance Test
Formal description of a software product, expressed as an example of a usage scenario.
184
Highsmith Decision Spectrum
People can indicate support and reservations at same time.
