ACP Workbook 3

Agile Certified Practitioner (ACP) Exam Prep
Chapter 03 - Agile Principles & Mindset

Slide 1
Domain Tasks
1. Advocate for agile principles by modeling those principles & discussing agile values in order
to develop a shared mindset across the team as well as between the customer & the team.
2. Help ensure that everyone has a common understanding of the values & principles of agile &
a common knowledge around the agile practices & terminology being used in order to work
effectively.
3. Support change at the system or organization level by educating the organization &
influencing processes, behaviors, & people in order to make the organization more effective
& efficient.
4. Practice visualization by maintaining highly visible information radiators showing real
progress & real team performance in order to enhance transparency & trust.
5. Contribute to a safe & trustful team environment by allowing everyone to experiment & make
mistakes so that each can learn & continuously improve the way he or she works.
6. Enhance creativity by experimenting with new techniques & process ideas in order to
discover more efficient & effectives ways of working.
7. Encourage team members to share knowledge by collaborating & working together in order
to lower risks around knowledge silos & reduce bottlenecks.
8. Encourage emergent leadership within the team by establishing a safe & respectful
environment in which new approaches can be tried in order to make improvements & foster
self-organization & empowerment.
9. Practice servant leadership by supporting & encouraging others in their endeavors so that
they can perform at their highest level & continue to improve.
v. 6.0- © Copyright and all rights reserved –
Looking Glass Development, LLC.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 2
 PMBOK Guide is a framework.
 Agile represents a family of methodologies.
 Agile methodologies fit within the PMBOK

Guide.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 3
Agile is Iterative & Incremental

 Incremental development – is a staging &
scheduling strategy in which the various
parts of the system are developed at
different times or rated and integrated as
they are completed.
 Iterative development – is a rework

scheduling strategy in which time is set
aside to revise and improve parts of the
system.
Alistair Cockburn

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 4
• In Option 1 the
Deliverable A
best resource for
Option 1 A A the deliverable
Option 2 A C A attempts to do
Deliverable B each task for the
Option 1 B B feature and nothing
Option 2 B B C gets delivered.
Deliverable C
• In Option 2
Option 1 C C
resourcing is
Option 2
applied based upon
availability and two
features are
delivered.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 5
The Beginning of Agile

 February, 2001 in Snowbird, Utah
Kent Beck Mike Beedle
Arie van Bennekum Alistair Cockburn
Ward Cunningham Martin Fowler
James Grenning Jim Highsmith
Andrew Hunt Ron Jeffries
Jon Kern Brian Marick
Robert C. Martin Steve Mellor
Ken Schwaber Jeff Sutherland
Dave Thomas

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 6
Agile Development Values…

 Individuals & Interactions OVER Processes &
Tools
 Customer Collaboration OVER Contract

Negotiations
 Responding to Change OVER Following a Plan
 Working Software OVER Comprehensive

Documentation

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 7
The 12 Principles of Agile Software

1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 8

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 9
Needed
Features
Never Used 36% Role of the Product
Features Owner is to cut off
the project before
45%
we do what won’t
be used.
Rarely Used
Features, 19%

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 10
 16 different methodologies are “Agile”

 Most common include:
◦ Scrum
◦ Extreme Programming
◦ Feature-Driven Development (FDD)
◦ Dynamic Systems Development Method (DSDM)
◦ Crystal (Crystal Clear, Crystal Yellow, Crystal Orange…)
 Closely related methodologies include:
◦ Lean software development
◦ Kanban
 Exam focuses on Scrum & XP although others
might appear.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 11
 Based on industrial process theory

◦ Self-organization
◦ Emergence
 Defined Process Control vs. Empirical Process
Control
◦ Defined Processes - Repeatable processes such as
in manufacturing. Leads to commoditization. In
projects often leads to rework.
◦ Empirical Processes - Complex processes where it
is difficult to have consistent processes. Focuses on
3 keys.
v.6.0 Copyright - Looking Glass

Development, All rights reserved.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 12
Foundation
 Visibility – The aspects of the process that
affect the outcome must be visible to those
controlling the process & what is seen must be
true.
 Inspection – The various aspects of the process
must be examined frequently enough that
unacceptable variances in the process can be
detected.
 Adaptation – If one or more of the processes
are determined out of control the processes
change.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 13
The Scrum Roles

 Product Owner – Responsible for representing
interests of all stakeholders, obtaining funding,
defining initial requirements, ROI, and objectives
(Product Backlog).
 The Development Team – Develops the functionality.

Is self-managing, self-organizing, and cross
functional.
 Scrum Master – Responsible for the Scrum process,

teaching Scrum to everyone, implementing Scrum so
it fits with culture, and that everyone follows Scrum
rules & practices.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 14
 C – Committed
 F – Focused
 O – Open
 R – Respected & Respectful
 C – Courageous
 E - Extreme

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 15
A Project Vision
 Serves as a Charter or Schedule Status/Trend: CV:
Project Datasheet
-$21,000 CPI: 0.90 OKBad
5 Line
Cost Status/Trend: SV: -$13,000 SPI: 0.93 GoodBad
Actual Costs: $188,000 Cost EAC: $362,852 Sch. EAC: 56.05 Weeks
Project Start Date: 10/22/2010 Project ID: 1234
Project Name: Sample Project Target Dt: 10/21/2011 Project Manager: Joe Smith
Project Duration Est.: 52 Weeks Forecast Dt: 11/18/2011 Product Manager:
Project Budget Est.: $326,000 Executive Sponsor: The Big Boss
Required to begin any

Development Methodology: Waterfall Spiral XP/Scrum Earned Value Reporting: Yes No Stage Gate Mgmt: Yes No
Primary Stakeholders: Performance Trends

$400
$300
project.
$200
$100
$0
In Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Never longer than a

$1,000's Forecast Costs Forecast Results Budget
Project Scope Statement Project Success Criteria

single page. Project Key Performance Indicators (KPIs) Key Constraints / Assumptions
 Includes 5 key pieces

of information: Need,
Pyramid Management Project Justification
Fixed Flexible Accept Priority Business Benefit
Scope Increased Revenue
Quality Operational Efficiency
Schedule Reduced Costs
justification, success
Costs Regulatory / Mandate
Portfolio Fit
Project Prioritization (# out of # for org.): Tranform
1 out of 10 Grow
Run
Major Project Milestones and/or Phases Primary Risks
criteria, prioritization,
constraints &
Change Management Process Communication & Reporting Process
assumptions. Sponsor Approval:
PM Approval:
Date:
Date:
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 16
Product Backlog
• A prioritized list of
items to be delivered.
• Each item is “relatively
independent” of the
others.
• Backlog may be
reprioritized at any
time.
• Items = User Stories or PBIs
• PBI = Product Backlog Item

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 17
2–6
Vision Week Daily Scrum
Sprints Every 24 Hours
Sprint Review
Not longer than 4
Release Planning
hours
for a 30 day sprint nor
Ranked more than 1 hour to
Product plan.
Backlog
Sprint end date &
deliverables do not
change
PO, SM & Team
conduct Sprint Sprint
Planning Tasks
Meeting Shippable Product
Sprint
• 1/ to complete
2 Backlog
grooming.
• 1/ to define tasks
2
& task estimates in
½ or full days. No
task longer than 1
day. Sprint Retrospective
Not more than 2 hours
for a 30 day sprint.
Scrum = 3 Roles + 4 Artifacts + 5 Meetings Not more than 1 hour
v. 6.0- © Copyright and all rights reserved – to plan.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 18

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 19
PBI To Do In Validat Impede Done

Progress e d
PBI 1 Task Task Task

Task Task
Task
Task Task
Task Task
PBI 2 Task Task Task
PBI 3 Task
Task Task Task Task
Task Task
Task Task
Task
Task
PBI 4 Task
Task Task
Tech Tech Tech Tech

Technical Tech
Tech Tech Tech
Tech
Debt Tech Tech
Debt Debt Debt Tech
Debt Debt
Debt
Debt Debt Debt Debt Debt
Debt
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 20
PBI To Do In Progress Validate Impeded Done

5 3 2
PBI Task Task Task Task
PBI Task Task Task
Tas
Task Task Task Task
PBI
k
PBI Task Task
PBI Tas
Task Task
k
Technical
Debt

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 21
Overview
 XP is a methodology that introduces checkpoints
when new requirements can be adopted to
improve productivity.
 Iterations of 1 to 2 weeks in length.
 Created by Kent Beck @ Chrysler with Ward

Cunningham & Ron Jeffries.
 12 practices grouped into four (4) areas.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 22
Basics
 XP’s Focus is on:
◦ Goals
◦ Activities
◦ Values
◦ Principles
◦ Practices

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 23
Basics
◦ Goals – Produce high quality software. XP does this
through short development cycles.
◦ Activities
 Listening - Programmers must listen to customers &
understand the business processes.
 Designing – Software must be designed as components
without complexity or dependencies between components.
 Coding – Is the meat of the methodology. It is the most
important part according to XP advocates.
 Testing

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 24
Core Values
 Simplicity – Reduce complexity, extra features &
waste. “Find the simplest thing that could possibly
work.”
 Communication – All the team members know
what is expected of them & what others are
working on.
 Feedback – The team must get impressions &
suitability early. It’s about “failing fast”.
 Courage – The team has to be willing to put its
work out there for others to see. Use pair
programming & share code.
 Respect – The team is accountable to each other
for results.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 25
Basics
◦ Principles
 Assume Simplicity – This is about treating every problem
as if its solution were extremely simple.
 Embrace Change – Do not work against change, embrace it.
◦ Practices (4 areas)
 Fine Scale Feedback
 Continuous Process
 Shared Understanding
 Programmer Welfare

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 26
Core Practices - Fine Scale Feedback

 Paired Programming – Two programmers work
together at one workstation. One programmer
writes while the other reviews & thinks
strategically. Pairs are not fixed & change often.
 The Planning Game – XP’s main planning process.

Occurs once per iteration (typically once per week)
◦ Incudes two parts: Release Planning & Iteration Planning.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 27
Fine Scale Feedback- Release Planning

 Focused on determining which requirements are included in which
near-term release & when they should be delivered.
 Customer & developer are part of this.
 Includes three (3) phases:
◦ Exploration Phase – Customer provides a short list of high-value
requirements for the system that are written as User Stories.
◦ Commitment Phase – Business & developers commit to the functionality
to include & next release date.
◦ Steering Phase – Plan can be adjusted, new requirements added,
existing requirements changed or removed.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 28
Fine Scale Feedback - Iteration

Planning
 Focused on planning the tasks & activities of the
developers.
 Customer is NOT part of this.
 Includes three (3) phases:
◦ Exploration Phase – The requirements are translated to specific
tasks & recorded on task cards.
◦ Commitment Phase – The tasks are assigned to programmers &
the task durations estimated.
◦ Steering Phase – Tasks are performed & the results then
matched with the original User Story.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 29
Core Practices - Fine Scale Feedback

 Test Driven Development – Tests are written
before code is written. Tests are automated.
◦ Write Unit tests.
◦ Fail tests. Programmers verify the tests fail.
◦ Write code. Programmers write minimal amount of code
to pass tests.
◦ Pass tests. Code is tested to ensure passage.
◦ Refactor. Remove any code smells from the code.
 Whole Team – The customer does not always pay
the bill, but always uses the system. Customer
must be on hand at all times to answer questions.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 30
XP Core Practices – Continuous

Process
 Continuous Integration – XP employs continuous
integration & requires the use of a repository
loading it every few hours. Integration tests are
run automatically.
 Design Improvement – Only code what is needed
today. When problems occur refactor code to make
it simpler & more generic.
 Small Releases – Frequent small releases to test
are encouraged. Quality is maintained through
continuous integration.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 31
Core Practices – Shared Understanding

 Coding Standards – An agreed upon set of rules that the entire
team follows for a consistent style & format. XP advocates
self-documenting code that reduces the need for code
comments.
 Collective Code Ownership – Any pair of developers can make
changes to any code & everyone is responsible for all code.
 Simple Design – “Simplest” is best approach to software
design.
 System Metaphor – It is a story that everyone can understand
about how the system works. It creates a naming convention
that allows customers to guess what class/methods do.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 32
Core Practices - Programmer

Welfare
 Sustainable Pace – Programmers should not work
more than 40 hours per week & no two weeks in
a row should have overtime.
 A key enabler of this concept is frequent code-

merge & always executable & test covered high
quality code.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 33
1. Envision - 2. Speculate – Stories 3. Explore - Developers use Paired

Are generated
conversations Programming to develop
With the customer. code.
Refactor Test
5. Close - Customer
Continuous
Acceptance testing
integration
Code
4. Adapt
Integration
Check-In
Local
Source
Control
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 34
 Teams work in Sprints of

2 to 6 weeks. Extreme Programming
 Teams do NOT allow  Teams work in iterations
changes into their of 1 to 2 weeks.
sprints.  So long as work has not
started on a feature it
 Scrum teams control the may be changed or
order of work, but are replaced.
informed by the PO.  XP teams work on a strict
 Scrum doesn’t prescribe priority order as defined
any engineering practices by the customer.
 XP prescribes TDD,
automated testing, pair
Scrum programming, simple
design
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 35
 Created by
◦ Peter Coad – A leader in the Object Oriented
Programming Movement.
◦ Jeff De Luca – Co-wrote book with P. Coad. IBM Project
Manager. Then founder of Nebulon Corp. in Australia.
 Reference books
◦ Java Modeling Color with UML (Last Chapter) 1999
◦ A Practical Guide to Feature-Driven Development 2002
 Origins
◦ Singapore Bank where Peter & Jeff worked together.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 36
Develop Build a Design

Plan by Build by
an overall feature by
feature feature
model list feature

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 37
 1. Develop Overall Model – The team holds a

kickoff and walks through the scope of the
system including all of its context.
◦ Detailed domain models are created for each modeling
area by small teams and presented for peer review.
◦ One of the proposed models is selected to become area
domain model.
◦ Domain area models are progressively merged into an
overall model.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 38
 2. Build Feature List – Knowledge from initial

modeling is used to identify the list of features by
functionally decomposing the domain into subject
areas.
◦ Subject areas each contain business activities.
◦ Steps within each business activity form the basis for
a categorized feature list.
◦ Features in this respect are small pieces of client-
valued functions expressed in the form
“<action><result><object>”
◦ Features should not take more than two weeks to
complete.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 39
 3. Plan by Feature – In this step, a development plan is

created where ownership of features, or feature sets are
assigned as classes to specific programmers.
 4. Design by Feature – The Chief Programmer selects a

small group of features to be developed in the next two
weeks.
◦ A Design Package is produced for each feature.
◦ Detailed Sequence Diagrams for each feature are produced.
◦ Class & Method Prologues are written.
◦ The Design Inspection is held.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 40
 5. Build by Feature
◦ The class owners develop the code for their classes.
◦ Unit tests are conducted on the code.
◦ Code inspection is conducted.
◦ The feature is promoted to the main build.
 Return to step 3 and repeat the process.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 41
 Domain Object Modeling – The team explores & explains the

domain of the problem.
 Developing by Feature – Break the functions down into two-week
or shorter chunks & calls them features.
 Individual Class Ownership – Areas of code have a single owner
(different from XP).
 Feature Teams – Small dynamically formed teams that vet designs
& allow multiple designs to be evaluated.
 Inspections – Reviews that help ensure good-quality design & code.
 Configuration Management – Labeling code, tracking changes, &
managing source code.
 Regular Builds – Make sure new code integrates with existing.
 Visibility of Progress & Results – Track progress based on
completed work.

_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Slide 42
Scrum FDD
 No formal process.
 No model  Five specific steps.
requirements.  Creates overall model
 Product Backlog 1st thing that is not
 Release plan provides working software.
initial view of when  Feature List
PBIs delivered.  Plan by feature
 Entire process is
iterative  Only the last three (3)
steps are iterative.
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
Review Questions:
1. Which of the following statements BEST describes the relationship between Agile
Development and the PMBOK Guide?
A. The PMBOK Guide represents PMI's methodology for executing projects.
While Agile Development represents a software development framework.
B. Agile Development represents the newest way to execute a project while
the PMBOK Guide represents the old way of executing a project.
C. The PMBOK Guide represents the overall framework for executing
projects and Agile Development represents a set of specific
methodologies used in project execution.
D. Agile Development represents the overall framework for executing
projects and the PMBOK Guide represents a set of specific practices used
in large scale projects.
2. Which of the following thought leaders is considered the father of the linear
development methodology known as "Waterfall"?
A. Alistair Cockburn
B. Winston Royce
C. Lyssa Adkins
D. Ken Schwaber
3. Which of the following terms refers to a staging and scheduling strategy in which
the various parts of the system are developed at different times or rated and
integrated as they are completed?
A. Iterative development
B. Incremental development
C. Staged development
D. Agile development
4. Which of the following terms represents a scheduling strategy where time is set
aside to revise and improve parts of the system?
A. Iterative development
B. Incremental development
C. Staged development
D. Agile development
5. When comparing traditional linear development to agile, which of the following
statements is most likely to be true?
A. Agile development makes extensive use of best resourcing to ensure
optimal productivity while traditional development uses WIP.
B. Both traditional development and Agile make use of best resourcing to
ensure optimal productivity.
C. Both traditional development and Agile make extensive use of WIP to
ensure optimal productivity.
D. Agile development makes extensive use of WIP while traditional
development uses best resourcing to ensure optimal productivity.
6. Within the Agile Manifesto, which of the following is valued more than processes
and tools?
A. Individuals and interactions
B. Customer collaboration
C. Responding to change
D. Working software
7. Within the Agile Manifesto, which of the following is valued more than contract
negotiations?
D. Working software
8. Within the Agile Manifesto, which of the following is valued more than following a
plan?
D. Working software
9. Within the Agile Manifesto, which of the following is valued more than
comprehensive documentation?
D. Working software
10. Which of the following Agile principles found in the Agile Manifesto is considered
MOST important?
A. Welcoming changing requirements, even late in develop.
B. Working software is the primary measure of progress.
C. Simplicity -- the art of maximizing the amount of work not done.
D. Satisfying the customer through early and continuous delivery of valuable
software.
11. Which of the following principles found in the Agile Manifesto focuses the team
on the importance of adaptation?
A. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
B. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
C. Business people and developers must work together daily throughout the
project.
D. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
12. Within the Agile Manifesto, which of the following principles focuses the team on
the importance of iterations?
A. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
B. Deliver working software frequently, from a couple of weeks to a couple of
project.
D. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
13. Which of the following principles found in the Agile Manifesto focuses the team
on the terms co-location, osmotic communication and information radiators?
A. Simplicity - the art of maximizing the amount of work not done - is
essential.
B. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
project.
D. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
14. Which of the following principles found in the Agile Manifesto focuses teams on a
pace often referred to as the Heartbeat of Agility?
A. Continuous attention to technical excellence and good design enhances
agility.
B. Agile processes promote sustainable development. The sponsors,
indefinitely.
C. Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
D. Deliver working software frequently, from a couple of weeks to a couple of
15. Which of the following principles from the Agile Manifesto calls on the team to
complete an introspection step as part of their process?
A. At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.
B. Continuous attention to technical excellence and good design enhances
agility.
C. Agile processes promote sustainable development. The sponsors,
indefinitely.
D. Business people and developers must work together daily throughout the
project.
16. A common term used by agilists to describe the cadence or pace created in Agile
Development is__________.
A. The Agile Cadence
B. Agile Throughput
C. The Heartbeat of Agility
D. The Agile Rhythm
17. Which of the following statements concerning the Heartbeat of Agility is NOT
true?
A. The notion of a consistent cadence or pace is absolutely critical to Agile
Development.
B. The Heartbeat of Agility is all about establishing a rhythm that is
comfortable and sustainable by the team.
C. The Heartbeat of Agility establishes a rhythm that often differs from what
the Team experiences in the real world.
D. The Heartbeat of Agility establishes a pace with slow periods throughout
most of the project.
18. An Agile Coach is explaining to a new Scrum Master that they believe the Team
has NOT been doing Scrum correctly as they are experiencing slow periods of
production throughout most of the project only to be forced into a mad dash at
the end of each Sprint in hopes of delivering business results. Typically, the
team has failed to meet the deadline, is burnt out, and has left their customer
frustrated. Which term BEST describes what the team has failed to establish?
A. Clear team expectations
B. The Heartbeat of Agility
C. Proper Scrum training
D. Well defined spike management
19. According to one recent study, what percentage of the average software
development project's features are never used?
A. 55%
B. 45%
C. 35%
D. 25%
20. Which of the following represents a way Agile Development helps to prevent the
customer from having to sacrifice quality in order to hit a targeted delivery date?
A. Agile methods require the customer to prioritize the project requirements
from most important to least.
B. Agile methods iterate the project to prevent mistakes.
C. Agile methods require the customer to continue the project until the
backlog is delivered.
D. Agile methods force the customer to not require unused features be
delivered.
21. Which of the following statements concerning Agile Development is NOT true?
A. Agile Development increases the visibility a customer has on a project.
B. Agile Development puts the customer in a position to see constraints
before they cause failure.
C. Agile Development ensures the customer receives something of value by
the deadline.
D. Agile Development gives the customer their most important features
earlier in the process.
22. In 1986 Hitotaka Takeuchi and Ikujiro Nonaka published an article that appeared
in the Harvard Business Review entitled The New Product Development Game
which became the basis for which Agile Method?
A. Feature-Driven Development
B. Extreme Programming
C. Dynamic Systems Method
D. Scrum
23. Scrum is based on which of the following aspects of Industrial Process Theory?
A. Self-organization and emergence
B. Convergence and self-organization
C. Emergence and dynamic evolution
D. Dynamic evolution and Convergence
24. Which of the following concepts represents the idea that information,
requirements and facts will be seen over time as the project progresses?
A. Convergence
B. Emergence
C. Self-organization
D. Dynamic evolution
25. Which of the following concepts represents the idea that the Development Team
will decide what work needs to be accomplished and who will do the work to
deliver the desired business results?
A. Convergence
B. Emergence
D. Dynamic evolution
26. According to Jeff Sutherland and Ken Schwaber, traditional project management
is based on the concept of a defined process. This concept is most effective
when used in what kind of organization?
A. A projectized organization
B. A matrix organization
C. A functional organization
D. A manufacturing organization
27. Which of the following terms represents a process in which goods that have
economic value and are indistinguishable in terms of attributes (uniqueness or
brand) end up becoming simple commodities in the eyes of the market or
consumers?
A. Standardization
B. Commoditization
C. Convergence
D. Optimization
28. When describing the various types of processes a project might use which of the
following statements is MOST true?
A. Projects have the greatest chance of success when empirical processes
are used.
B. Projects have the least chance of success when empirical processes are
used.
C. Projects have the greatest chance of success when defined processes are
used.
D. Projects have the least chance of success when defined processes are
used.
29. Which of the following is NOT a key driver for empirical processes?
A. Visibility
B. Inspection
C. Adaption
D. Flexibility
30. When describing an empirical process, which of the three major drivers defines
the step where the team brings the process back into conformance once an
unacceptable variance is found?
A. Visibility
B. Inspection
C. Adaptation
D. Conformation
31. Which of the following Scrum roles represents the person who is responsible for
representing the interests of all stakeholders, obtaining project funding, defining
the initial requirements, defining the project ROI, and the key project objectives?
A. Product owner
B. Key stakeholder
C. Project sponsor
D. Customer
32. Within Scrum, where are the product features maintained and appear in ranked
order from most important to least?
A. The product scope statement
B. The product backlog
C. The project charter
D. The requirements matrix
33. Which of the following statements concerning the Product Backlog is NOT true?
A. A Product Backlog is never complete.
B. The Product Backlog evolves as the product and the environment in which
it will be used evolves.
C. The Product Backlog lists all features, functions, requirements,
enhancements, and fixes that constitute the changes to be made to the
product.
D. The Product Owner may decide to "lock down" the Product Backlog at any
time.
34. Which of the following statements concerning the Product Backlog is NOT true?
A. Higher ranked backlog items are usually more clearly and completely
defined than lower ranked items.
B. Any backlog item that can be "done" within one sprint is deemed "Ready"
for selection in Sprint Planning.
C. The product owner is responsible for all estimates of items appearing on
the product backlog.
D. The Scrum Team defines when refinement is done for all backlog items.
35. What primary Scrum role is described as self-managing, self-organizing, and

cross functional?
A. The product owner
B. The development team
C. The Scrum team
D. The Scrum master
36. What is the recommended size of the Scrum Development Team?

A. 6 +/- 3
B. 5 +/- 3
C. 3 +/- 4
D. 4 +/- 4
37. Which of the following statements about the Scrum Master is NOT true?
A. The Scrum Master is responsible for the Scrum process.
B. The Scrum Master is responsible for implementing Scrum so it fits with
culture.
C. The Scrum Master acts as a facilitator.
D. The Scrum Master acts as the project manager for the project.
38. Which one of the following represents one of the key expected behaviors of the
Development Team represented by the acronym CFORCE?
A. Convicted
B. Focused
C. Opportunistic
D. Courteous
39. Which of the following represents one of the key expected behaviors of the
Development Team NOT represented by the acronym CFORCE?
A. Extreme
B. Courageous
C. Reasoned
D. Committed
40. You are acting as a Scrum Master for a new project within your organization.
There currently isn't any documentation for the initiative. Which of the following
documents is required before the team can begin work according to the rules of
Scrum?
A. A business case
B. A needs analysis
C. User stories
D. A project vision
41. Which of the following items is NOT one of the five core elements found in a
project vision document?
A. The business case
B. The project justification
C. Success criteria
D. Constraints and assumptions
42. According to Moore, which of the following is a common way to validate a project
Vision?
A. The PDCA Test
B. The ROAD Test
C. An Elevator Test
D. An Ishikawa Test
43. You are asked to explain the project initiation process when using Scrum to a
coworker. As part of the discussion you explain two documents are required.
What are those two documents?
A. A business case and user stories
B. A burndown chart and user story log
C. A kanban board and a business case
D. A product vision and product backlog
44. Which of the following terms represents a self-contained unit of work agreed
upon by the developers and the stakeholders?
A. User Stories
B. Themes
C. Epics
D. Releases
45. Which of the following terms represents a group of related user stories that
contribute to a common goal or are related in some obvious way?
A. User Stories
B. Themes
C. Epics
D. Releases
46. Which of the following terms are made up of multiple user stories, but also
sometimes resemble stories in the sense that they may appear as a larger story
or comprise a complete workflow for a user and cut across all or some of the
three business dimensions?
A. User Stories
B. Themes
C. Epics
D. Releases
47. Which of the following terms represents a grouping of functionality that is most
often seen when teams are implementing SAFe as they are often used to
enhance business value of the FULL solution set or bring a range of technologies
together?
A. Epics
B. Themes
C. Sprints
D. Rocks
48. Which of the following terms represents pieces of functionality used as

placeholders when there is an absence of information and act as a signpost
signifying the team does have information about a feature or requirement?
A. Epics
B. Themes
C. Sprints
D. Rocks
49. When discussing sprints, which of the following statements is NOT true?
A. The original Rules of Scrum stated that each Sprint was 30 days in length.
B. The Development Team must decide the length of each sprint during the
Sprint Planning Meeting.
C. Over the years, Scrum has adopted the practices from other Agile
methodologies and the common practice is to see sprints of between two
and six weeks in length.
D. Each sprint must be the exact same fixed length.
50. Which of the following may explain why releases become necessary?
A. The organization that has set specific windows where new code can be
put into the production system.
B. It is either impractical or ill advised to put the features completed from a
single sprint into production because the Scrum Master determines it to be
so.
C. Releases are never necessary.
D. Releases are required on every Scrum project.
51. What is the first official meeting defined in the Scrum Guide?
A. The project kickoff
B. The release planning meeting
C. The sprint planning meeting
D. The sprint retrospective
52. What officially signifies the start of each sprint?

A. The product owner announces the sprint initiation.
B. It is noted by the calendar.
C. The Sprint Planning Meeting.
D. It varies from one Scrum project to the next.
53. Which of the following is NOT a core purpose of the Release Planning Meeting?
A. The Development Team uses the meeting to examine the backlog items to
determine how they need to be grouped together to produce releases.
B. The Development Team uses the meeting to determine how long each
sprint will be.
C. The Development Team uses the meeting to determine how the Sprints
will be grouped into Releases.
D. The Development Team uses the meeting to create estimates for the
significant User Stories.
54. The process of defining Backlog items in greater detail is called __________.
A. Grooming
B. Defining
C. Decomposition
D. Consecration
55. When defining a User Story, which of the following rules apply?
A. Each User Story must be completed within one release.
B. Each User Story must provide monetary value to the business.
C. Each User Story must be completed within one sprint.
D. Each User Story represents a single work package.
56. Which of the following is NOT a key question asked during the Daily Scrum?
A. What did they accomplish yesterday?
B. What are the User Story durations?
C. What are they going to accomplish today?
D. What impediments do they have?
57. What is the role of the Product Owner in the Daily Scrum?
A. The PO leads the Daily Scrum.
B. The PO does not attend the Daily Scrum.
C. The PO answers the key questions.
D. The PO acts as an observer in the Daily Scrum.
58. As the Development Team completes the work of a Sprint within the Scrum
framework what is the primary responsibility of the PO?
A. Defend the team and secure project funding.
B. Groom the backlog and remove impediments.
C. Groom the backlog and define the next sprint.
D. Remove impediments and define the next sprint.
59. You are working on a software development project within your organization
serving the role of Scrum Master. The team is in the middle of its fourth two-
week iteration when the Product Owner, who is also the company CEO has just
come to you demanding a critical piece of functionality be added to the current
Sprint. What should you do?
A. Immediately call the team together to discuss the issue.
B. Add the functionality to the sprint backlog.
C. Remind the PO that in agreeing to use Scrum they committed to not
changing the features the team worked on once a Sprint began. Then ask
that they add the feature to the Product Backlog and prioritize it highly.
D. Freeze the project until the issue is resolved.
60. May the Development Team ever alter the features being completed in the
current Sprint?
A. Yes, whenever a member of the team believes it is warranted.
B. No, changing the work of an in-progress Sprint is never allowed.
C. Yes, when new information is learned, or the team finds they have extra
time and the entire team agrees.
D. No, only the Product Owner may change the work of an in-progress
Sprint.
61. You are the Scrum Master for a mid-sized project that has just completed its third
two-week Sprint. What should the Team do next?
A. Plan and conduct the Sprint Review.
B. Plan and conduct the Sprint Retrospective.
C. Review the Product Backlog before beginning the next Sprint.
D. Initiative a Release Planning Meeting.
62. When a team conducts a Sprint Retrospective what is the role of the Product
Owner?
A. The Product Owner leads the Sprint Retrospective.
B. The Product Owner acts as a team member in the Sprint Retrospective.
C. The Product Owner coordinates the objectives of the Sprint Retrospective
with the Scrum Master.
D. The Product Owner does not participate in the Sprint Retrospective.
63. A member of the business organization has just returned from a basic Agile
training course and wants you and the rest of the Development Team to use an
iteration zero in an upcoming Scrum project. Which of the following is NOT a
reason for this recommendation?
A. The team believes a more formal architecture plan is needed.
B. The team believes the project requires an iteration or milestone plan.
C. The team believes the project is extremely complex requiring more
traditional planning.
D. The team believes the advanced planning will allow it to move quickly
moves into more standard Scrum sprints.
64. Which of the following is NOT one areas of focus for Extreme Programming?
A. Goals
B. Testing
C. Activities
D. Values
65. Which of the following is NOT a core activity used in Extreme Programming used
to meet its stated goal?
A. Listening - Programmers must listen to customers and understand the
business processes.
B. Designing - Software must be designed as components without complexity
or dependencies between components.
C. Testing - The team must test a functionality.
D. Deployment - The team must implement the product or service of the
project.
66. Which of the following is a core value of the Extreme Programming

methodology?
A. Guidance
B. Commitment
C. Simplicity
D. Dedication
67. Which of the following is NOT a core value of the Extreme Programming
framework?
A. Curious
B. Feedback
C. Communication
D. Respect
68. Which of Extreme Programming practices does NOT belong in the Fine Scale
Feedback group?
A. The Planning Game
B. Design Improvement
C. Test-Driven Development
D. Whole Team
69. What Extreme Programming practice calls for a meeting that occurs once per
iteration and likely occurs once per week? This practice is focused on
determining which requirements are included in which near-term release and
when specifically they should be delivered.
A. Paired Programming
B. The Planning Game
C. The Whole Team
D. Test-Driven Development
70. The team is using Extreme Programming to complete the project, the business
and developers are meeting to commit to the functionality to include within the
next release and what the release date will be. In what phase of the Planning
Game are you?
A. Exploration
B. Planning
C. Commitment
D. Steering
71. In the XP practice group known as Shared Understanding which of the following
is not a core practice?
A. Coding Standards
B. Simple Design
C. Collective Code Ownership
D. Complete Metaphor
72. In discussions with another developer on an XP project team your remind them
of YAGNI. What are you suggesting?
A. System designs are usually best when they are kept simple.
B. Good design requires a strong overall view of the project.
C. Good architecture is layered in its approach.
D. Systems thinking is critical to project success.
73. When the creators of Extreme Programming discuss the importance of a
sustainable pace to what are they referring?
A. Programmers are not permitted to work more than 40 hours per week on
average and no two weeks in a row have over time.
B. Programmers are not permitted to work more than 40 hours per week on
average and no more than one week per month has overtime.
C. Programmers are not permitted to work more than 50 hours per week on
average and no more than two weeks per month have overtime.
D. Programmers are not permitted to work more than 50 hours per week on
average and no more than two weeks in a row have over time.
74. Which of the following is NOT one of the basic steps found in the Extreme
Programming process?
A. Envision
B. Speculate
C. Create
D. Adapt
75. Which of the following is NOT one of the basic steps found in the Feature-Driven
Development process?
A. Develop Overall Architecture
B. Build Feature List
C. Plan By Feature
D. Build By Feature
76. Feature-Driven Development defines six milestones per feature. During which
activity are the first three milestones completed?
A. Build Feature List
B. Plan By Feature
C. Design By Feature
D. Build By Feature
77. FDD is unique because at the point coding begins a feature is already ____
complete.
A. 36%
B. 38%
C. 42%
D. 44%
78. Which of the following statements concerning domain models is NOT true?
A. Domain models reflect our understanding of real world entities and their
relationships and responsibilities.
B. Domain models help resolve ambiguities in both the requirements and the
design intent.
C. Domain models are typically developed by the Product Owner.
D. Domain models reflect our understanding of real world entities and their
relationships and responsibilities.
79. In which FDD role does the person work as a member of a three to six member
team who designs, codes, tests and documents the features required on the
projects?
A. Domain Experts
B. Class Owners
C. Chief Programmers
D. Development Manager
80. In which FDD role are the users, sponsors, and business analysts who have the
specific knowledge relied upon to deliver and correct the system?
A. Domain Experts
B. Class Owners
C. Chief Programmers
D. Development Manager
81. Which of the following is NOT a secondary role found in Feature-Driven

Development?
A. Toolsmith
B. Build Engineer
C. Language Guru
D. Product Manager
82. Within the process of Domain Object Modeling, which class category color
represents a moment in time or an interval of time usually associated with some
business process?
A. Yellow
B. Blue
C. Green
D. Pink
83. Which of the following is a core aspect of Industrial Process Theory used as a
basis for Scrum?
A. Divergence
B. Capitalization
D. Duality
84. Which of the following terms represents repeatable processes that lead to
commoditization and in projects can cause rework?
A. Agile processes
B. Manufacturing processes
C. Empirical processes
D. Defined processes
85. Your organization is using Scrum to manage a software development project

when a number of stakeholders bring to the team's attention a number of missing
requirements. Who is responsible for prioritizing these new requirements?
A. The Team
B. The Stakeholders
C. The Product Owner
D. The ScrumMaster
86. When using Scrum, who is responsible to attend all Scrum meetings on time and
be prepared?
A. The Scrum Team
B. The Product Owner
C. The ScrumMaster
D. The Key Stakeholders
87. When using Scrum, who is responsible for regularly demonstrating working
product at the Sprint Review?
A. The Scrum Team
C. The ScrumMaster
D. The Key Stakeholders
88. When using Scrum, who is responsible to assist the Product Owner with
analyzing and decomposing Product Backlog items?
A. The Product Owner
B. The Scrum Team
C. The Development Team
D. The ScrumMaster
89. When using Scrum, what is the difference between the Development Team and
the Scrum Team?
A. They are the same thing.
B. The Development Team are the people who do the work of the project
while the Scrum Team includes the Development Team, the PO & the
ScrumMaster.
C. The Scrum Team are the people who do the work of the project while the
Dev Team includes the Scrum Team, the PO & the ScrumMaster.
D. The Scrum Team represents the group of people who manage the
organization's Scrum process and the Development Team does the
project work.
90. In Scrum, who provides daily status updates to the Scrum Master at the Daily
Scrum?
A. Everyone
B. The Development Team
C. The Scrum Team
D. No One
91. In Scrum, who is responsible for avoiding distracting the Team after the Team
has committed to the Sprint Goal?
A. No one
C. The ScrumMaster
D. Everyone
92. In Scrum, who observes end-to-end flow of product delivery and takes action to
maximize the delivery of value?
A. No one
C. The Scrum Master
D. Everyone
93. In Scrum, who assigns work to individual team members?
A. No one
C. The ScrumMaster
D. Everyone
94. In Scrum, who helps those outside the Development Team understand which of
their interactions with the Team are helpful and which are not, and helps
everyone change these interactions to maximize the value created by the team?
A. No one
C. The Scrum Master
D. Everyone
95. In Scrum, who attends Sprint Planning meetings when the Team requests their
expertise?
A. Business Stakeholders
C. The ScrumMaster
D. Everyone
96. In Scrum, who is the sole person responsible for managing the Product Backlog?
A. Business Stakeholders
C. The ScrumMaster
D. Everyone
97. What is the desired iteration length for a project using Extreme Programming?
A. One to two weeks
B. Two to six weeks
C. 30 days
D. As short as possible
98. Which of the following is NOT a core activity used in the production of XP's
goals?
A. Listening
B. Designing
C. Developing
D. Testing
99. Which of the following is NOT a core value of Extreme Programming?
A. Simplicity
B. Speed
C. Courage
D. Respect
100. Which of the following XP core values represents the Team's willingness to put
its work out there for others to see?
A. Respect
B. Feedback
C. Communication
D. Courage
101. Which of the following is NOT one of the areas of practice for Extreme
Programming?
A. Fine Scale Feedback
B. Assume Simplicity
C. Continuous Process
D. Shared Understanding
102. Which of the following is part of XP's Planning Game?

A. Sprint Planning
B. Iteration Grooming
C. Release Planning
D. Iteration Forecasting
103. In Extreme Programming, which of the following is focused on determining which

requirements are included in which near-term release and when they should be
delivered?
A. Sprint Planning
B. Release Planning
C. Iteration Planning
D. Iteration Forecasting
104. Which of the following statements BEST describes XP's notion of Test Driven
Development?
A. Tests are constantly integrating into the development process.
B. Tests are written, and applied before any code is written.
C. Tests are required for all code.
D. Tests are developed with input from all stakeholders.
105. Which of the following statements BEST describes XP's notion of the Whole
Team?
A. Project sponsors must be present for all key meetings.
B. The customer must be present for all key meetings.
C. The customer must be on hand at all times to answer questions.
D. The customer and sponsors must be on hand at all times to answer
questions.
106. Within XP, which of the following is NOT a core practice found in the Continuous
Process area?
A. Continuous Integration
B. Design Improvement
C. Small Releases
D. Test Driven Development
107. Within XP, which of the following is NOT a core practice found in the Shared
Understanding area?
A. Small Releases
B. Coding Standards
C. Simple Design
D. System Metaphor
108. In which FDD step does the team hold a kickoff and walk through the scope of
the system?
A. Develop an overall model
B. Build a feature list
C. Plan by feature
D. Design by feature
109. In FDD, which of the following terms is the process by which the team explores
and explains the domain of the problem?
A. Domain Area Modeling
B. Designing by Feature
C. Domain Object Modeling
D. Configuration Management
110. In which FDD step does the team use knowledge from the initial model to identify
the list of features by functionally decomposing the domain into subject areas?
A. Domain Area Modeling
B. Designing by Feature
C. Domain Object Modeling
D. Build Feature List
111. Which of the following FDD concepts is used to reference the process of labeling
code, tracking changes, and managing source code?
A. Inspections
B. Regular builds
C. Configuration management
D. Domain modeling
112. In FDD who vets designs and allows multiple designs to be evaluated?
A. Feature teams
B. The sponsor
C. The project manager
D. The development team
113. When comparing Scrum to FDD which of the following statements is true?
A. Both Scrum and FDD makes use of a ranked product backlog.
B. In Scrum the entire process is iterative. In FDD only the last three steps
are iterative.
C. FDD does not have a formal process for development whereas Scrum
does.
D. Neither Scrum nor FDD have formal model requirements.
114. When comparing Scrum to XP which of the following statements is true?

A. In formal Scrum sprints are 30 days in length and in XP iterations are one-
to-two weeks in length.
B. In neither Scrum nor XP does the team allow changes to their iteration.
C. Scrum and XP require the Product Owner to define the order of work to be
completed.
D. Neither XP nor Scrum prescribe specific engineering practices.
Answer Key:
1. C
LGd course manual p. 23 - The relationship between Agile Development and the
PMBOK Guide has traditionally been contentious. Many agilists try to argue
Agile Development and the PMBOK Guide are at odds. However, nothing could
be further from the truth. The PMBOK Guide represents generally accepted
principles and practices. It does NOT represent a methodology that can be
followed step-by-step. Many agilists also claim that their particular concepts are
a framework representing a loose scaffolding. However, most thinkers agree
Agile represents an aggregation of methodologies.
2. B
LGd course manual p. 25 - Dr. Winston W. Royce is often falsely credited with
developing the waterfall methodology based on a he wrote in 1970. However, if
one actually reads his paper they find he actually argued there were significant
risks in the linear process and proposed an iterative anc incremental approach
with at least two loops. He also argued for prototyping.
3. B
LGd course manual p.25 - Alistair Cockburn defines Incremental development as
a staging and scheduling strategy in which the various parts of the system are
developed at different times or rated and integrated as they are completed. This
means that the features or requirements do not have to be completed as part of a
single release. When a team uses incremental delivery they are able to deliver
features or requirement in a wide range of orders defined by the team. This
fundamentally changes how projects are executed. Suddenly, it what is
delivered at any point in the project. This notion is somewhat similar to the ideas
surrounding Object Oriented Programming where features and requirements are
delivered as discrete objects independent of others.
4. A
LGd course manual p. 26 - Iterative development is a rework scheduling strategy
in which time is set aside to revise and improve parts of the system. The
concepts of Iterative Development creates loops in the process of executing a
project that allow the team to change their process to improve execution and
delivery. In a single looped linear process, the team is stuck with the process
with which they start the project. This is a key advantage to seasoned,
experienced teams. Those teams have completed multiple projects together and
hopefully those experiences provide insights on the current effort. Agile projects
get lots and lots of chances to deliver because they use lots of short iterations.
Each one requires a short cycle of reflection to determine the best way to
improve the process and deliver better results.
5. D
LGd course manual p. 26 - Agile Development makes extensive use of WIP or
Work In Progress. Although there is no rule or requirement to do so, most
traditionally managed projects use a concept called Best Resourcing. In Best
Resourcing whichever resource possesses the highest skill level is assigned to
execute the task. WIP argues that we want to limit the amount of Work In
Progress occurring at any single point. The principle can be thought of like a
water main. The objective of the Water Department is to ensure the maximum
amount of water is constantly available to the end users when they turn on their
faucets. Contrary to what you might think, the best way to ensure high water
pressure is to ensure the mains are less than 100% full. Remember, the mission
is to get each drop to the customer as quickly as possible. If you ask your
friendly neighborhood civil engineer, they will confirm that the water will travel the
fastest when the pipe is less that 100% full. We do the same thing with our
project tasks when using WIP.
6. A
LGd course manual p. 28 & the Agile Manifesto at http://agilemanifesto.org. This
is perhaps the most important and highlights a common complaint about many
Project Managers. According to many involved in Agile Development, traditional
Project Managers often lack technical skills dealing with the product or service of
the project. This causes them to rely far too much on process and tools to fix
problems when they arise. The key is to always remember that projects are
about creating business value. The processes, tools and techniques we choose
to use to create that value are simply means to an end. Without the end they
have no value.
7. B
LGd course manual p. 29 & the Agile Manifesto at http://agilemanifesto.org. The
second value statement is that we value customer collaboration over contract
negotiations. This value statement highlights the importance of the Development
Team working directly and daily with the Business Stakeholders to deliver value
to the business. Rarely does the Development Team understand the business
need as well as the customer. Furthermore, the Customer is the final arbiter of
whether or not the Team has delivered the right product or service. Therefore, to
succeed the team must constantly talk to the stakeholders. In most cases, this
means DAILY! Contracts are important, and many project require them.
However, when the Team gets caught up in the legalize of what a contract says
they often loose site of truly meeting the customer's needs. At the end of the
day, meet the customer's needs.
8. C
third value statement is we value responding to change over following a plan.
This statement often causes an immediately negative knee-jerk reaction from
traditionally trained project managers. "Ah ha!" They exclaim. "Here it is. Agile
Development leads to chaos because it doesn't allow for planning or plans. We
can't live this way. We have to be able to tell people what's coming next."
Unfortunately, this is a complete misunderstanding of what the statement says
and how most Agile Methodologies work. Agile projects absolutely have plans
and processes. However, these processes and plans are set up in such as way
that they can quickly evolve and change as the team learns new information. It is
this ability that significantly differentiates Agile Development from other methods
for managing projects. Do not misread this value. It is not a license for a no
planning free-for-all. Agile requires plans and processes. In many cases,
activities are planned to the daily level, a much smaller unit than many traditional
projects use.
9. D
final value statement is that the Agilist values working software over
comprehensive documentation. This statement takes us back to the importance
of delivering real value to the organization as opposed to simply producing a lot
of paper to show that people worked hard. People working hard does nothing for
the business. It is all about providing value.
10. D
LGd course manual p. 29 & the Agile Manifesto at http://agilemanifesto.org. Our
highest priority is to satisfy the customer through early and continuous delivery of
valuable software. This statement says it all. The highest priority, the most
important this is delivering value to the customer. In the early days of Agile the
community was almost entirely software developers so naturally the product was
software. Today, Agile has extended to many different industries so it often
makes sense to replace "valuable software" with "valuable product, service or
result."
11. A
LGd course manual p. 30 & the Agile Manifesto at http://agilemanifesto.org.
Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage. We made all the way
to the second principle before things blew up. I hear project managers constantly
complain about scope change. It is almost a daily occurrence. "We would have
succeeded, if it wasn't for the customer making all those last minute scope
changes." This statement ignores the fact that it is the customer's right to
demand scope changes so long as they accept the impacts. The problem is that
too many team uses processes that make change difficult at best. This is a real
key to Agile Development's success. It make change easy, or at least easier,
even late in the process.
12. B
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale. Remember, Agile
Development is focuses on being iterative. This means loops of repeated
processes. The large number of loops affords the team the opportunity to learn
from the past. As the team executes more and more loops, they are able alter
the processes to better deliver. However, the key is that at the end of each
iteration the team must deliver working product, service or result. With a
timescale of only a few weeks to a few months the team is limited in how much
functionality they can produce. This means the team must produce a small
amount of functionality that has value to the customer, present it to them, and
allow the customer to comment on that functionality. The team then adapts to
the feedback, makes changes and moves to the next iteration. A common
phrase used to highlight this process is, "fail fast."
13. D
most efficient and effective method of conveying information to and within a
development team is face-to-face conversation. Here is a news flash. E-mail is a
terrible vehicle for most communication needs! Since its inception, Agile
Development has understood this and pushed for better ways of sharing
information. Broadcasting status reports via email or attempting to collect
requirements electronically are examples of using e-mail poorly, but there are
many more. Agile Development pushes teams to work closely and be co-
located. If you are not familiar with the term CO-LOCATED it is important that
you learn it. It means all the members of a group are physically sitting in the
same location. This is why you can often quickly pick out and organization that is
using Agile Development when the Development Team is all physically located in
a single conference room or central area. Being co-located affords the team a
number of advantages. First, team members can quickly turn and talk to
compatriots when they have issues. Second, information quickly gets dispersed
using OSMOTIC COMMUNICATION. This is where information is absorbed by
team members simply by being in the room when it is shared. Finally,
information moves between parties much more quickly through the use of
INFORMATION RADIATORS when the team is in a single location. We will
discuss this last term in a later section of the course.
14. B
Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely. Eventually,
there had to be a bit of marketing right? Well, here it is. Agile Development
promotes sustainable development. What the heck is that, and why should you
care? First, it is more than just marketing, although there is a bit of that here.
The real issue is something many resources have experienced over the years. If
you have ever been part of a project that starts out slow where many team
members have nothing to do until the end of the project when everything
becomes a crisis and a mad dash to the finish line. During these late periods,
team members are expected to work significant overtime and often their personal
life struggles to deliver the project. This cycle repeats itself time and time again
until the resources eventually burn out and leave the organization. Agilists argue
that this pace is not only unsustainable, but also unnecessary. A better approach
they contend, is to use Agile processes that increase the daily productivity
throughout the entire lifecycle of the project thereby reducing or completely
eliminating the mad dash crisis at the end. This pace is often referred to as the
HEARTBEAT OF AGILITY and will be discussed in a few moments.
15. A
LGd course manual p. 32 & the Agile Manifesto at http://agilemanifesto.org. At
regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly. Introspection is a key aspect of any Agile
team. Unlike linear approaches to project execution where the Team typically
does a single release, Agile Development cycles repeatedly. This gives the
customer lots and lots of opportunities to comment on the work product. It also
provides the Team many opportunities to learn. With every loop, the Team has a
chance to execute the basic process. At the end of that process most Agile
Methodologies provide some kind of reflection process where the Team is tasked
with examining their performance in the cycle and determining the best way to
improve before moving on to the next iteration. This reflection period is
absolutely critical. It recognizes that the Team is never perfect, and there are
always improvements to be made. It move the concept of continuous
improvement from some abstract theory we say is important into something we at
regular intervals focus on and actually do something about.
16. C
LGd course manual p. 33 - The notion of a cadence is absolutely critical to an
Agile team. It is all about establishing a rhythm that is comfortable and
sustainable by the Team. This rhythm differs from what many teams experience
in the real world where they often experience slow periods of production
throughout most of the project only to be forced into a mad dash at the end in
hopes of delivering business results. Typically, the team fails to meet the
deadline, is burnt out, and has left a frustrated customer. Agile processes
attempt to solve this problem by increasing the daily productivity of the team.
The goal is to have a higher rate of daily productivity and avoid the massive
spikes experienced by the team. This notion does not argue there are not
spikes, instead it is about creating much smaller, regular spikes that are within
the realm of sustainability.
17. D
LGd course manual p. 33 - The Heartbeat of Agility represents a key aspect of
developing an Agile Cadence or pace. The notion of a cadence is absolutely
critical to an Agile team. It is all about establishing a rhythm that is comfortable
and sustainable by the Team. This rhythm differs from what many teams
experience in the real world where they often experience slow periods of
the end in hopes of delivering business results. Typically, the team fails to meet
the deadline, is burnt out, and has left a frustrated customer. Agile processes
18. B
LGd course manual p. 33 - The Heartbeat of Agility represents a key aspect of
developing an Agile Cadence or pace. The notion of a cadence is absolutely
critical to an Agile team. It is all about establishing a rhythm that is comfortable
and sustainable by the Team. This rhythm differs from what many teams
experience in the real world where they often experience slow periods of
the end in hopes of delivering business results. Typically, the team fails to meet
the deadline, is burnt out, and has left a frustrated customer. Agile processes
19. B
LGd course manual p. 34 - Chaos Chronicles, only about 36% of all features are
regularly used. Another 19% of a software project's features are rarely used, and
a full 45% of a software applications features are never used. So why does this
matter? It matters because far to often project teams force stakeholders to wait
for the important, must used features because they are trying to produce features
that will never be used.
20. A
LGd course manual p. 34 - Most Agile methodologies require the customer or
key stakeholders to prioritize the requirements from most important to least. The
Team then makes every effort to deliver the features in the defined order. At the
end of the project when the Team is at the deadline there will still likely be a
number of features or requirements that are incomplete. The difference is that
these are the less important ones. This puts the customer in a position of great
power. Now the customer can decide whether or not they want the team to
continue the project to deliver these minor features. In a linear process, the
customer is stuck. They have to continue the project because if they don't they
get nothing of value. In Agile they have the most important items and get to
decide how much the lessor items are really worth to them. Secondly, Agile
Development gives the customer these most important features earlier in the
process. This means they are able to begin using these mission critical features
as soon as they are done without waiting for lessor features. Finally, Agile
Development forces business stakeholders to make hard decisions like spend
more money and time or not. It forces a hard discussion around those never
used features in a highly visible way. As a result it becomes far more difficult to
sneak a feature or requirement into the process at the end.
21. C
LGd course manual p. 34 - Be carefule in reading the choices. Although Agile
Development does dramatically increase the likelihood the customer will get
something of value by the deadline, nothing can ensure this fact.
22. D
LGd course manual p. 35 - Scrum was first defined as "a flexible, holistic product
development strategy where a development team works as a unit to reach a
common goal" as opposed to a "traditional approach" (read a linear approach
such as Waterfall) in January of 1986 by Hitotaka Takeuchi and Ikujiro Nonaka in
the New Product Development Game published in the Harvard Business Review.
This article described a new approach to commercial product development that
they argued would increase both speed and flexibility based upon their
examination of numerous case studies in manufacturing, photocopier and the
printer industries. They called this the holistic or rugby approach. The idea was
to create a single, small cross functional team that possessed all, or at least
most, of the skills required to complete the project and this team would work on
the project across multiple overlapping phases constantly passing work back and
forth until complete.
23. A
LGd course manual p.35 - Scrum is based on two aspects of industrial process
theory self-organization and emergence. Self-organization is the idea that the
Development Team will decide what work needs to be accomplished and who
will do the work to deliver the desired business results. Emergence is the idea
that information, requirements and facts will emerge as the project progresses.
The key is that the team uses processes, tools, and techniques capable of
harnessing this new information for the betterment of the organization.
24. B
LGd course manual p. 35 - Emergence is the idea that information, requirements
and facts will emerge as the project progresses. The key is that the team uses
processes, tools, and techniques capable of harnessing new information as it
becomes available for the betterment of the project.
25. C
LGd course manual p. 35 - Self-organization is the idea that the Development
Team will decide what work needs to be accomplished and who will do the work
to deliver the desired business results.
26. D
LGd course manual p. 35 - The creators of Scrum argue that traditional linear
approaches for projects such as Waterfall are based on the concepts of defined
processes. Defined processes are repeatable processes such as in
manufacturing.
27. B
LGd course manual p. 36 - Commoditization is defined as the process in which
goods that have economic value and are indistinguishable in terms of attributes
(uniqueness or brand) end up becoming simple commodities in the eyes of the
market or consumers. This means or widgets become easy to obtains for the
consumer because many different organizations have made them uniform,
plentiful and affordable.
28. A
LGd course manual p. 36 - A defined process is perfectly tailored to operational
management because we want people to follow the exact same steps day after
day. Projects or new initiatives are a very different animal. They are all about
creating something we haven't had before. They are about creating something
new and in some way different. By this definition, the processes we used to
execute the last project won't necessarily work with next. Success relies on
flexibility, and flexibility requires a different way of doing things. Projects have
the greatest chance of success when empirical processes are used.
29. D
LGd course manual p. 36 - Empirical processes focus on creating a situation with
the highest using three primary drivers: visibility, inspection and adaptation.
30. C
LGd course manual p. 36 - If one or more of the processes are determined out of
control the processes change. Once you can see the drivers in a process and
have taken the time to examine those variables to ensure you know which
variables are in control and which ones are not, the only thing left is to fix those
processes that are not performing as expected. This step is called adaptation.
31. A
LGd course manual p. 37 - The PO is the individual responsible for representing
the interests of all stakeholders, obtaining funding, defining the initial
requirements, defining the return on investment or ROI, and the project
objectives. They are the primary owner of the Product Backload, a document
where the User Stories, features or requirements of the project are listed in rank
order from most important to least important from the perspective of the
business.
32. B
The Scrum Guide p. 12 - "The Product Backlog is an ordered list of everything
that might be needed in the product and is the single source of requirements for
any changes to be made to the product. The Product Owner is responsible for
the Product Backlog, including its content, availability, and ordering."
33. D
The Scrum Guide p. 12 - "The Product Backlog is an ordered list of everything
that might be needed in the product and is the single source of requirements for
any changes to be made to the product. The Product Owner is responsible for
the Product Backlog, including its content, availability, and ordering. A Product
Backlog is never complete. The earliest development of it only lays out the
initially known and best-understood requirements. The Product Backlog evolves
as the product and the environment in which it will be used evolves. The Product
Backlog is dynamic; it constantly changes to identify what the product needs to
be appropriate, competitive, and useful. As long as a product exists, its Product
Backlog also exists. The Product Backlog lists all features, functions,
requirements, enhancements, and fixes that constitute the changes to be made
to the product in future releases. Product Backlog items have the attributes of a
description, order, estimate and value."
34. C
The Scrum Guide p. 13 - The Development Team is responsible for all estimates.
The Product Owner may influence the Development Team by helping it
understand and select trade-offs, but the people who will perform the work make
the final estimate.
35. B
LGd course manual p. 37 - The Development Team is self-managing, self-
organizing, and cross functional. The team does not have a project manager or
functional leader who directs the team's efforts. The Development Team is also
small. According to the rules of Scrum, the team size is six plus or minus three.
This puts the optimal team size somewhere between three and nine individuals.
36. A
LGd course manual p. 37 - The Development Team is self-managing, self-
organizing, and cross functional. The team does not have a project manager or
functional leader who directs the team's efforts. The Development Team is also
small. According to the rules of Scrum, the team size is six plus or minus three.
This puts the optimal team size somewhere between three and nine individuals.
37. D
LGd course manual p. 38 - The Scrum Master is responsible for the Scrum
process, teaching Scrum to everyone, implementing Scrum so it fits with culture,
and ensuring that everyone follows Scrum's rules & practices. The closest
approximation to in a linear project is the Project Manager, but there are some
key differences, at least from the perspective of the Agilist. Most Agilists believe
that traditional project managers are only part of hierarchical organizations with
the project manager at the top. All the resources report to the PM. Additionally,
this person serves as an administrator directing the team, but having no technical
skills or knowledge of the project. This is a huge over simplification of the role,
but makes for a nice comparison. A Scrum Master serves as a facilitator.
Remember, a Scrum Development Team is self-managing. The expectation is
that the Scrum Master role is to only help the team, to ask probative questions, to
ensure the team knows the Scrum process and follows it. Development Team
members report to each other and not the Scrum Master so the Scrum Master
has no formal authority to make anyone do anything.
38. B
LGd course manual p. 38 - Often Agilists use an acronym to describe the
expected behavior of the Development Team. It is CFORCE. The C stands for
Committed. An Agile Development Team must be committed to the Team's
goals and to the other members of the Team. F stands for focused. This criteria
goes back to an earlier point. A Development Team must be focused on one and
only one project. O stands for open. Each member of the team must be open to
receive and provide honest criticism intended to improve the project and the
team. Team members must always assume positive intend of their compatriots.
R stands for respected and respectful. This requirement is also tied to how team
members treat each other. It is expected that each team member is a respected
part of the organization and that they respect all the other members of the team.
Team members must give respect in order to receive it. The C stands for
courageous. The team must take risks, find innovative solutions, and focus on
finding the best solutions to meet the needs of the business. Finally, we have the
E, which stands for extreme. Scrum calls on the Development Team to be
zealous in the pursuit of the mission.
39. C
LGd course manual p. 38 - Often Agilists use an acronym to describe the
expected behavior of the Development Team. It is CFORCE. The C stands for
Committed. An Agile Development Team must be committed to the Team's
goals and to the other members of the Team. F stands for focused. This criteria
goes back to an earlier point. A Development Team must be focused on one and
only one project. O stands for open. Each member of the team must be open to
receive and provide honest criticism intended to improve the project and the
team. Team members must always assume positive intend of their compatriots.
R stands for respected and respectful. This requirement is also tied to how team
members treat each other. It is expected that each team member is a respected
part of the organization and that they respect all the other members of the team.
Team members must give respect in order to receive it. The C stands for
courageous. The team must take risks, find innovative solutions, and focus on
finding the best solutions to meet the needs of the business. Finally, we have the
E, which stands for extreme. Scrum calls on the Development Team to be
zealous in the pursuit of the mission.
40. D
LGd course manual p. 38 - Most people are familiar with a project vision by
another name, the Project Charter. Many Agilists would contend that the two
documents are not the same thing, but this has more to do with many project
managers failing to create proper charters than the comparison. The Vision sets
the direction of the project and guides the Scrum Team. In 2004, Schwaber
described the Vision this way, "The minimum plan necessary to start a Scrum
project consists of a vision and a Product Backlog. The vision describes why the
project is being undertaken and what the desired end state is.: (Schwaber 2004,
p.68)
41. A
LGd course manual p. 39 - A well-formed Vision is a single page document that
answers a number of questions. These questions cover five major areas: The
Business Need, The Project Justification, The Success Criteria, The Project's
Prioritization, and any Constraints or Assumptions. A Business Case offers
much of the same information as it explains why the business needs the product
or service of the project.
42. C
LGd course manual p. 40 - A common way to validate your Vision is to answer
the elevator test. Can you explain the product, service or result of the project in
the time it takes to ride up in an elevator? (Moore 2006 p. 152).
43. D
LGd course manual p. 39-40 - The two documents necessary required to
implement Scrum. The first of these documents in called the Product or Project
Vision. The Vision sets the direction of the project and guides the Scrum Team.
In 2004, Schwaber described the Vision this way, "The minimum plan necessary
to start a Scrum project consists of a vision and a Product Backlog. The vision
describes why the project is being undertaken and what the desired end state is.:
(Schwaber 2004, p.68). The second document in the list of four is a Ranked
Product Backlog. More often than not the literature talks about just the Product
Backlog. A Product Backlog is a listing of the User Stories, features or
requirements.
44. A
LGd course manual p. 40 - A story is a self-contained unit of work agreed upon
by the developers and the stakeholders. Stories are the heart of Scrum, and the
building blocks of the sprint. Additionally, each story must provide functionality
that has real value to the business. A User Story is different from a feature
however as a feature represents a distinct element of functionality that provides
capability to the business while a User Story is a small aspect of a feature that is
used to get feedback from stakeholders and find out if you are doing anything
wrong.
45. B
LGd course manual p. 40 - Themes may be thought of as groups of related
stories. Often the stories all contribute to a common goal or are related in some
obvious way, such as focusing on a single customer. Sometimes stories within a
theme may be dependent on each other, and then do not necessarily
encapsulate a specific work flow or be delivered together.
46. C
LGd course manual p. 40 - Epics resemble themes in the sense that they are
made up of multiple stories. Sometimes they also resemble stories in the sense
that may appear as a big story. Unlike themes, epics often comprise a complete
workflow for a user and they typically cut across all or some of the three business
dimensions (time, scope and organizations). Another important difference is
while the stories that comprise an epic may be completed independently, their
business value isn't realized until the entire epic is complete. This means that it
rarely makes sense to deliver an epic until all of the underlying stories are
complete.
47. A
LGd course manual p. 41 - Epics are most often seen when teams are
implementing SAFe as they are often used to enhance business value of the
FULL solution set or bring a range of technologies together. They are often key
economic drivers for the portfolio.
48. D
LGd course manual p. 41 - Rocks are pieces of functionality used as
placeholders when there is an absence of information. The rock acts as a
signpost signifying the team does have information about a feature or
requirement.
49. B
A short iteration of fixed time where features are produced that have tangible
value to the customer. The original Rules of Scrum stated that each Sprint was
30 days in length. However, over the years Scrum has adopted the practices
from other Agile methodologies and the common practice is to see sprints of
between two and six weeks in length. The key is that each sprint must be the
exact same fixed length, and each MUST produce fully tested functionality that
has real value to the customer.
50. A
LGd course manual p. 41 - A release is a group of related sprints. Releases
become necessary for a variety of reasons. The Rules of Scrum require every
sprint to provide fully tested, production ready features. However, there are
many situations where it is either impractical or ill advised to put the features
completed from a single sprint into production. Imagine an organization that has
set release windows where new code can be put into the production system. In
these situations, the Development Team simply places the results from sprints
"on the shelf" until all the releases that are part of the release are complete and
then the entire group of features is place into production together.
51. B
LGd course manual p. 42 - Every project begins the same way. Just imagine
someone in the organization has a problem so they complete a single page
document that starts the ball rolling. This document is a Vision. Some type of
governance decides the idea has merit so they assign a team to do some initial
work. The Development Team conducts an initial kickoff meeting with the
Product Owner and key stakeholders to develop an initial Ranked Product
Backlog. Once the Development Team has the initial Backlog they enter the
Release Planning Meeting. Although the Kickoff Meeting is a common solution
for project initiation the Release Planning Meeting is the first official meeting
listed in the Scrum Guide.
52. C
LGd course manual p. 42 - The Sprint Planning Meeting represents the first step
of the process that gets repeated with each sprint. The purpose of the Sprint
Planning Meeting is to plan the work of the current Sprint, and it officially kicks off
the sprint. The meeting is broken into two parts.
53. D
LGd course manual p. 42 - The Release Planning Meeting serves several
purposes. The Development Team first uses the meeting to examine the
backlog items to determine how they need to be grouped together to produce
releases. Additionally, the team needs to determine how long each sprint needs
to be. Remember, each User Story must fit into a single sprint. So the Team is
tasked with getting a sprint length that is as short as possible, but long enough to
deliver fully tested, production ready results that have real value to the business.
To do this, the Team must somehow determine estimates for each PBI. There
are a number of techniques commonly used for this purpose that are discussed
later in this book. The estimates are used by the Development Team to ensure
each sprint is approximately the same size. Once the Development Team has
determined how long the sprints will be and how the sprints will be grouped into
releases, then team is done with the Release Planning Meeting. Approximately
once a quarter the team must revisit the Release Planning Meeting.
54. A
LGd course manual p. 42 - The process of gaining more detail about a feature or
backlog item is called Backlog Grooming. This is process where the Product
Backlog Items are defined in enough detail that the Development Team can build
the feature.
55. C
LGd course manual p. 42 - No User Story could be larger than a single sprint.
56. B
LGd course manual p. 44 - Each day begins the same way with a meeting called
the Daily Scrum. This is a ten to fifteen minute meeting that provides the Team
with basic project status and communication. Each day the Development Team
stands around the Scrum or Team Board and answers three questions:
What did they accomplish yesterday?
What are they going to accomplish today?
What impediments do they have?
57. D
LGd course manual p. 44 - Each day begins the same way with a meeting called
the Daily Scrum. This is a ten to fifteen minute meeting that provides the Team
with basic project status and communication. Each day the Development Team
stands around the Scrum or Team Board and answers three questions. Each
member of the Development Team reports their results to the other members of
the Development Team and NOT to the Scrum Master or Product Owner who are
also present. The Scrum Master is tasked to act as a facilitator and the PO is
only an observer.
58. B
LGd course manual p. 44 - While the Development Team works to produce the
day’s results, the Product Owner works on grooming yet undefined User Stories
for future sprints while also working with the Scrum Master to remove
impediments.
59. C
LGd course manual p. 44 - No one from the business may add a feature to a
sprint once work has commenced, but may add, delete or change items on the
Product Backlog at their discretion. The Development Team occasionally has to
take User Stories out of the current sprint as new information is learned and may
at their discretion pull up a new item if the situation warrants.
60. C
LGd course manual p. 44 - No one from the business may add a feature to a
sprint once work has commenced, but may add, delete or change items on the
Product Backlog at their discretion. The Development Team occasionally has to
take User Stories out of the current sprint as new information is learned and may
at their discretion pull up a new item if the situation warrants.
61. A
LGd course manual p. 44 - On the last day of each sprint two meetings are
conducted. First, the Team conducts a Sprint Review. This one hour to 90
minute meeting allows the Product Owner to present the results of the sprint to
the customers. This is all about showing working product to the people who will
really use it. The Development Team wants the product owner to take this
responsibility because it both provides a connection from them to the users and
helps to ensure their engagement throughout the sprint. The Team is allowed a
few hours to prepare for this meeting. Once the Sprint Review is complete, the
Development Team conducts a Sprint Retrospective. If the Sprint Review is all
about the product of the project, the Sprint Retrospective is all about the process.
62. D
LGd course manual p. 44 - Once the Sprint Review is complete, the
Development Team conducts a Sprint Retrospective. If the Sprint Review is all
about the product of the project, the Sprint Retrospective is all about the process.
The Product Owner is not allowed to attend the Retrospective and the Scrum
Master is only present as a facilitator. This meeting provides the Development
Team the opportunity to review the process and find the best way to improve the
process. The team uses a wide range of games and tools to answer the
question, "If tomorrow we were 1,000% more efficient what we do to get there?"
It is singularly focused on the process the Development Team is using to achieve
their results.
63. C
LGd course manual p. 45 - Another practice sometimes used by Scrum teams is
Iteration 0. This is NOT part of Scrum found in the Scrum Guide. Remember the
basic rule we established for Scrum that said every single sprint would be the
same length of time and must produce functionality that has real value to the
business? Iteration 0 violates both those rules. The goal of Iteration 0 is to
produce two items that do not initially have value to the business. These are the
core architecture and feature list. It is not unusual for this work to take
significantly longer than a single sprint, and as such it violates the Rules of
Scrum requiring and out. If a team has decided to use Iteration 0 because they
believe the project needs a more formal architectural plan and/or work on its
feature list it is important that the team also provides an iteration or milestone
plan to ensure the team quickly moves into more standard Scrum sprints.
64. B
LGd course manual p. 46-47 - The five areas of focus within Extreme
Programming include: Goals, Activities, Values, Principles and Practices.
65. D
LGd course manual p. 46 - Extreme Programming defines four core activities
necessary to meet its stated goal. These include:
Listening - Programmers must listen to customers and understand the business
processes.
Designing - Software must be designed as components without complexity or
dependencies between components.
Coding - Is the meat of the methodology. It is the most important part according
to XP advocates.
Testing - The team must test a functionality.
66. C
LGd course manual p. 46 - Values represent what the team hold highest. When
discussing Extreme Programming, here are its core values: Simplicity,
Communication, Feedback, Courage, and Respect.
67. A
68. B
LGd course manual p. 47 - The first grouping of practices is called Fine Scale
Feedback. It is the notion of providing rapid feedback to each individual
developer in a fashion they can actually act upon it in a timely manner. The four
practices tied to Fine-Scale Feedback include: Paired Programming, The
Planning Game, Test-Driven Development, Whole Team.
69. B
LGd course manual p. 47 - The Planning Game represents the main planning
process used in Extreme Programming. Like the Sprint Planning Meeting in
Scrum, The Planning Game is a meeting that occurs once per iteration. In most
XP environments, this means once a week. There are two parts to the Game,
Release Planning and Iteration Planning. Release planning is focused on
when specifically they should be delivered. Both the customer and developer are
part of this process. It includes three phases.
70. C
part of this process. It includes three phases. In the Commitment Phase, the
business and developers commit to the functionality to include and next release
date.
71. D
LGd course manual p. 49 - Shared Understanding represents the set of practices
that ensure all the members of the team have the same information about the
project and its product. It requires more than just access to information though
as you will see from its four practices: Coding Standards, Collective Code
Ownership, Simple Design, and System Metaphor.
72. A
LGd course manual p. 49 - "Simplest" is best approach to software design.
Often, software fails because of the layers of complexity that constantly get
added until the application collapses under its own weight. XP attempts to peel
back the layers of the onion to achieve a design that is more robust and long
lasting. A common XP expression used along with Simple Design is the acronym
YAGNI which stands for "You Aren't Gonna Need It." This expression means
that something is not needed, and it will complicate things. Therefore, the best
solution is to throw it out.
73. A
LGd course manual p. 49 - The last practice found in Extreme Programming is
part of a group called Programmer Welfare. It is the practice of a Sustainable
Pace where programmers are not required or even allowed to more than 40
hours per week on average and no two weeks in a row have overtime. The idea
is based on the concept that programming is highly technical, detailed work and
that fresh programmers produce better code. A key enabler of this concept is
frequent code merges of code that are always executable. This code must
constantly be tested to ensure it is of a high quality.
74. C
LGd course manual p. 50 - Like most methodologies, Extreme Programming has
a five-step process. These steps include: Envision, speculate, Explore, Adapt,
and Close.
75. A
LGd course manual p. 51 - FDD is a model-driven, short-iteration methodology
that has five basic processes or activities. In FDD the first two activities are used
to generate an overall model shape. Then, the final three processes or activities
are iterated for each feature. The five processes or activities include: Develop
the Overall Model, Build Feature List, Plan By Feature, Design By Feature and
Build By Feature.
76. C
LGd course manual p. 52 - Since features are small, completing a feature is a
relatively small task. For accurate state reporting and keeping track of the
software development project it is important to mark the progress made on each
feature. Feature-Driven Development therefore defines six milestones per feature
that are to be completed sequentially. The first three milestones are completed
during the Design By Feature activity, the last three are completed during the
Build By Feature activity. To help with tracking progress, a percentage complete
is assigned to each milestone. At the point that coding begins a feature is
already 44% complete (Domain Walkthrough 1%, Design 40% and Design
Inspection 3% = 44%). The code is then worth 45%. Code Inspection provides
another 10%, and finally Promoting the Feature to Build adds 1%.
77. D
The first three milestones are completed during the Design By Feature activity,
the last three are completed during the Build By Feature activity. To help with
tracking progress, a percentage complete is assigned to each milestone. At the
point that coding begins a feature is already 44% complete (Domain Walkthrough
1%, Design 40% and Design Inspection 3% = 44%). The code is then worth
45%. Code Inspection provides another 10%, and finally Promoting the Feature
to Build adds 1%.
78. C
LGd course manual p. 53 - Domain models reflect our understanding of real
world entities and their relationships and responsibilities. Key to remember is that
effective Domain Modeling may only occur in the context of the system-level
requirements that are often captured as Use Cases or User Stories. Domain
Modeling is used to support the analysis of Epics, Backlog refinement at the
program and team levels, design workshops at different levels, and the
refinement of the Product Vision and Roadmap.
79. B
LGd course manual p. 53 - FDD has six primary roles, five support roles and
three additional roles. FDD, like all Agile Methodologies argues people are the
most important aspect when you consider the key drivers of people, process, and
technology. The primary roles include: Project Manager, Chief Architect,
Development Manager, Chief Programmer(s), Class Owners, Domain Experts.
The Class Owners are the developers who work as members of those three to
six member teams led by the Chief Programmers who design, code, test and
document the features required on the project. They are called Class Owners
because that is exactly who they are. FDD ensures every single class (defined
as a breakout of code) is owned by one and only one person. If anything is
wrong with it they are responsible.
80. A
LGd course manual p. 53 - FDD has six primary roles, five support roles and
three additional roles. FDD, like all Agile Methodologies argues people are the
most important aspect when you consider the key drivers of people, process, and
technology. The primary roles include: Project Manager, Chief Architect,
Development Manager, Chief Programmer(s), Class Owners, Domain Experts.
The Domain Experts are users, sponsors, and business analysts who have the
specific knowledge the Class Owners rely upon to deliver the correct system.
81. D
LGd course manual p. 54 - In addition to the primary roles, Feature Driven
Development relies on five supporting roles to succeed. These roles are not
considered primary to the team delivering the required features, but they are
important roles to the project's success. These roles include: Release Manager,
Language Guru, Build Engineer, Toolsmith, and the System Administrator.
82. D
LGd course manual p. 55 - The Domain Object Modeling is the process of
building Class Diagrams depicting the significant types of objects within a
problem domain and the relationships between them. The first published
description of FDD appear as part of a concept called UML in Color. This is the
same as plain UML, but the classes are color-encoded. This is done to allow for
quick understanding of the dynamics of the problem domain. Each of the class
categories are represented by a different color that has specific meaning: Yellow
- A role being played by a person or an organization; Blue - A catalogue-like
description of an object, but it is not considered the object itself; Green - A party
(individual), place, or thing. The green class usually has some identifying
attributes, such as a serial number or person's name associated with it; Pink - A
moment in time or an interval of time usually associated with some business
process.
83. C
LGd course manual p. 35 - Scrum is based on two aspects of industrial process
theory self-organization and emergence. Self-organization is the idea that the
Development Team will decide what work needs to be accomplished and who
will do the work to deliver the desired business results. Emergence is the idea
that information, requirements and facts will emerge as the project progresses.
The key is that the team uses processes, tools, and techniques capable of
harnessing this new information for the betterment of the organization.
84. D
LGd course manual p. 35 - The creators of Scrum argue that traditional linear
approaches for projects such as Waterfall are based on the concepts of defined
processes. Defined processes are repeatable processes such as in
manufacturing. Imagine working at the Acme Widget factory. In order to
produce widgets of a consistent level of quality it is imperative that our machines
stamp and assemble each widget the same way. The more consistently we can
stamp the widgets the less variance we see in the finished product. As we move
forward we also try to increase the rate of production.
85. C
LGd course manual p. 37 - The PO is the individual responsible for representing
the interests of all stakeholders, obtaining funding, defining the initial
requirements, defining the return on investment or ROI, and the project
objectives. They are the primary owner of the Product Backload, a document
where the User Stories, features or requirements of the project are listed in rank
order from most important to least important from the perspective of the
business.
86. A
LGd course manual p.37 - Throughout much of the literature and in this book a
fourth role is added to the list that is not officially part of Scrum, but often
unwittingly included. It is The Team. The Team is different from the
Development Team because it includes all three Scrum roles. It is defined as
everyone involved in delivering the project. It is the Product Owner, the Scrum
Master and the Development Team together. As we go through the rest of this
discussion it is important that you can differentiate the Team from the
Development Team.
87. A
LGd course manual p. 44 - On the last day of each sprint two meetings are
conducted. First, the Team conducts a Sprint Review. This one hour to 90
minute meeting allows the Product Owner to present the results of the sprint to
the customers. This is all about showing working product to the people who will
really use it. The Development Team wants the product owner to take this
responsibility because it both provides a connection from them to the users and
helps to ensure their engagement throughout the sprint. The Team is allowed a
few hours to prepare for this meeting.
88. D
LGd course manual p. 38 - The Scrum Master is responsible for the Scrum
process, teaching Scrum to everyone, implementing Scrum so it fits with culture,
and ensuring that everyone follows Scrum's rules & practices. The closest
approximation to in a linear project is the Project Manager, but there are some
key differences, at least from the perspective of the Agilist.
89. B
LGd course manual p. 38 - Everyone involved in the project fits into one of these
three roles. For many, this is a bit disconcerting. What do you do if you are a
business analyst or quality assurance person how do you fit in when there are
only three roles and you aren't one of them? In most situations, these additional
roles are included as part of the Development Team. They represent other
resources needed to complete the work of the project. However, occasionally
they also might fit in to the organization as resources used by the Product Owner
to define the requirements of the project.
90. D
LGd course manual p. 44 - The focus is supposed to be on the second and third
questions as the first is historical and there is no chance to impact it. Each
member of the Development Team reports their results to the other members of
the Development Team and NOT to the Scrum Master or Product Owner who are
also present. The Scrum Master is tasked to act as a facilitator and the PO is
only an observer.
91. D
LGd course manual p. 47
92. D
LGd course manual p. 47 - Although all three Scrum roles are critical to project
success, they are not all created equal. Significantly more is offered and
expected from the Development Team. Often Agilists use an acronym to
describe the expected behavior of the Development Team. It is CFORCE. The
C stands for Committed. An Agile Development Team must be committed to the
Team's goals and to the other members of the Team. F stands for focused. This
criteria goes back to an earlier point. A Development Team must be focused on
one and only one project. O stands for open. Each member of the team must be
open to receive and provide honest criticism intended to improve the project and
the team. Team members must always assume positive intend of their
compatriots. R stands for respected and respectful. This requirement is also tied
to how team members treat each other. It is expected that each team member is
a respected part of the organization and that they respect all the other members
of the team. Team members must give respect in order to receive it. The C
stands for courageous. The team must take risks, find innovative solutions, and
focus on finding the best solutions to meet the needs of the business. Finally, we
have the E, which stands for extreme. Scrum calls on the Development Team to
be zealous in the pursuit of the mission.
93. A
LGd course manual p. 46
94. C
LGd course manual p. 38 - A Scrum Master serves as a facilitator. Remember, a
Scrum Development Team is self-managing. The expectation is that the Scrum
Master role is to only help the team, to ask probative questions, to ensure the
team knows the Scrum process and follows it. Development Team members
report to each other and not the Scrum Master so the Scrum Master has no
formal authority to make anyone do anything.
95. A
LGd course manual p.42 - The next step in the process is the Sprint Planning
Meeting represents the first step of the process that gets repeated with each
sprint. The purpose of the Sprint Planning Meeting is to plan the work of the
current Sprint, and it officially kicks off the sprint. The meeting is broken into two
parts. When necessary information is NOT present specific business
stakeholders are asked to attend.
96. B
LGd course manual p. 40 - A Product Backlog is a listing of the User Stories,
features or requirements. These items are often referred to as Product Backlog
Items or PBIs. The key is the "ranked" portion. It is a key aspect of using the
Product Backlog. Ranking the backlog requires the business to prioritize the
items in the Backlog from most important to the business to the least important.
Sometimes the Backlog is further defined into groups of User Stories that belong
together. The Development Team uses the Backlog to define which features to
deliver when. Each of the items on the Backlog items relatively independent of
each other. Additionally, the items on the Backlog may be reprioritized at any
time.
97. A
LGd course manual p. 50 - Scrum teams work in timeboxes called Sprints that
are two to six weeks in length. Extreme Programming uses timeboxes called
Iterations that are one to two weeks in length. A two week Sprint is the most
common in Scrum and a one week Iteration is most common in XP.
98. C
LGd course manual p. 46 - Extreme Programming defines four core activities
necessary to meet its stated goal. These include: Listening - Programmers must
listen to customers and understand the business processes; Designing -
Software must be designed as components without complexity or dependencies
between components; Coding - Is the meat of the methodology. It is the most
important part according to XP advocates; and Testing - The team must test a
functionality.
99. B
100. D
LGd course manual p. 46 - Courage - The team has to be willing to put its work
out there for others to see. It must also use pair programming and shared code.
These two principles will be discussed later.
101. B
LGd course manual p. 47 - Extreme Programming's 12 practices are grouped
into four practice areas. These practice areas provide the toolset used by teams
implementing XP and the groupings include: Fine Scale Feedback, Continuous
Process, Shared Understanding and Programmer Welfare. Most of the rest of
this section focuses on these 12 practices. Assuming simplicity is one of two
core principles that drive XP and NOT an area of practice.
102. C
part of this process.
103. B
part of this process.
104. B
LGd course manual p. 48 - In TDD, the tests are written before any code is
written and those tests are automated. Typically, the TDD process contains five
steps: The developer who will eventually write the code writes the unit tests. This
is unlike most testing doctrines where someone other than the developer writes
the tests often at the same time or after the developer begins writing the code;
The developer runs the test to ensure the test fails as not code has been written
so a passed test without any code would mean a bad test; The developer writes
the minimum amount of code possible that allows the test to be passed; The
developer reruns the test to ensure passage; And the developer then refactors
the code removing any codes smells from the code. We will talk extensively
about what this means later in the course.
105. C
LGd course manual p. 48 - The final practice found in Fine-Scale Feedback is the
Whole Team. This is a basic requirement seen in many Agile methodologies.
The premise is that although the customer does not always pay for the project,
they are always the people who use the product, service or result of the project.
As a result, the customer must always be on hand to answer questions from the
developers.
106. D
LGd course manual p. 48 - Test Driven Development is a practice found in the
Fine Scaled Feedback area of Extreme Programming.
107. A
LGd course manual p. 49 - The four practices found in Shared Understanding
include: Coding standards; Collective code ownership; Simple design; And
system metaphor.
108. A
LGd course manual p. 51 - Develop Overall Model - The team holds a kickoff and
high-level walkthrough the scope of the system. This includes all of its context.
Next, detailed Domain Models are created for each modeling area by small
teams and then presented for peer review. One of the proposed models, or a
combination of them, is selected to become the model for each domain area.
These Domain Area Models are progressively merged into a single overall
model.
109. C
LGd course manual p. 52 - Domain Object Modeling - The team explores and
explains the domain of the problem. That probably doesn't mean very much to
you at this point so let's spend a few minutes discussing Domain Modeling.
Domain Modeling is a way to describe and model real world things and the
relationships between them. This is collectively called the "Problem Domain
Space." Domain Modeling is used by lots of Agile techniques including FDD and
SAFe. It is considered one of the key models used in software engineering and
there is a saying, "if you only model one thing in Agile, model the domain."
110. D
LGd course manual p. 51 - Build Feature List - Knowledge and information from
the initial modeling effort is used to identify the list of features by functionally
decomposing the domain into subject areas. Each subject area contains
business activities with steps that form the basis for a categorized feature list.
Think of these "features" as small pieces of client-valued functionality expressed
in the form "<action><result><object>". This is a IT specific way of writing
features that might have little meaning if you do not come from a software
development background. Don't worry, you do not need to be a software
developer to pass the PMI-ACP Exam. These features need to be small enough
that they can be completed in not more than two weeks. Once the team has
completed this activity they have their overall model and are ready to proceed
into the activities used to actually produce the features of the project.
111. C
LGd course manual p. 53 - Configuration Management - Labeling code, tracking
changes, & managing source code.
112. A
LGd course manual p. 54 - The Class Owners are the developers who work as
members of those three to six member teams led by the Chief Programmers who
design, code, test and document the features required on the project. They are
called Class Owners because that is exactly who they are. FDD ensures every
single class (defined as a breakout of code) is owned by one and only one
person. If anything is wrong with it they are responsible. A Class Owner often
cannot do this work alone so must be the leader of a team called a Feature
Team.
113. B
LGd course manual p. 56 - Scrum does not require a specific model whereas
FDD requires a Domain Model be created first before any software is produced.
Thirdly, Scrum works from a ranked Product Backlog that is owned by the
Product Owner. The Development Team works from the Backlog informed by
the PO. FDD works from its Feature List strictly based on the priority list. Next,
Scrum uses a Release Plan to provide its initial view of when the Product
Backlog Items will be delivered. Feature-Driven Development plans strictly by
feature order. Finally, the entire process of Scrum is iterative. In FDD only the
last three steps are iterative. The first two steps only occur once.
114. A
LGd course manual p. 56 - Scrum does not require a specific model whereas
FDD requires a Domain Model be created first before any software is produced.
Thirdly, Scrum works from a ranked Product Backlog that is owned by the
Product Owner. The Development Team works from the Backlog informed by
the PO. FDD works from its Feature List strictly based on the priority list. Next,
Scrum uses a Release Plan to provide its initial view of when the Product
Backlog Items will be delivered. Feature-Driven Development plans strictly by
feature order. Finally, the entire process of Scrum is iterative. In FDD only the
last three steps are iterative. The first two steps only occur once.

ACP Workbook 3

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ACP Workbook 3

Загружено:

Авторское право:

Доступные форматы

Agile Certified Practitioner (ACP) Exam Prep

Chapter 03 - Agile Principles & Mindset

 PMBOK Guide is a framework.

 Agile represents a family of methodologies.

 Agile methodologies fit within the PMBOK

v. 6.0- © Copyright and all rights reserved –

Agile is Iterative & Incremental

 Iterative development – is a rework

v. 6.0- © Copyright and all rights reserved –

The Beginning of Agile

v. 6.0- © Copyright and all rights reserved –

Agile Development Values…

 Customer Collaboration OVER Contract

 Responding to Change OVER Following a Plan

 Working Software OVER Comprehensive

v. 6.0- © Copyright and all rights reserved –

The 12 Principles of Agile Software

v. 6.0- © Copyright and all rights reserved –

v. 6.0- © Copyright and all rights reserved –

v. 6.0- © Copyright and all rights reserved –

 16 different methodologies are “Agile”

 Based on industrial process theory

v.6.0 Copyright - Looking Glass

The Scrum Roles

 The Development Team – Develops the functionality.

 Scrum Master – Responsible for the Scrum process,

v. 6.0- © Copyright and all rights reserved –

Required to begin any

Never longer than a

Project Scope Statement Project Success Criteria

 Includes 5 key pieces

assumptions. Sponsor Approval:

v. 6.0- © Copyright and all rights reserved –

v. 6.0- © Copyright and all rights reserved –

PBI To Do In Validat Impede Done

PBI 1 Task Task Task

Tech Tech Tech Tech

PBI To Do In Progress Validate Impeded Done

PBI Task Task Task

PBI Task Task

v. 6.0- © Copyright and all rights reserved –

 Iterations of 1 to 2 weeks in length.

 Created by Kent Beck @ Chrysler with Ward

 12 practices grouped into four (4) areas.

v. 6.0- © Copyright and all rights reserved –

v. 6.0- © Copyright and all rights reserved –

v. 6.0- © Copyright and all rights reserved –

v. 6.0- © Copyright and all rights reserved –

Core Practices - Fine Scale Feedback

 The Planning Game – XP’s main planning process.

v. 6.0- © Copyright and all rights reserved –

Fine Scale Feedback- Release Planning

v. 6.0- © Copyright and all rights reserved –

Fine Scale Feedback - Iteration

v. 6.0- © Copyright and all rights reserved –

Core Practices - Fine Scale Feedback

XP Core Practices – Continuous

v. 6.0- © Copyright and all rights reserved –

Core Practices – Shared Understanding

v. 6.0- © Copyright and all rights reserved –

Core Practices - Programmer

 A key enabler of this concept is frequent code-

v. 6.0- © Copyright and all rights reserved –

1. Envision - 2. Speculate – Stories 3. Explore - Developers use Paired