PMP® EXAM PREP

BOOTCAMP
(2021 UPDATE)
Session 5
Instructor: Barb Waters, MBA, PMP

If you are watching on replay, this slide deck

PMP® Exam Prep
may have been modified to correct typos or This course will assist learners in preparing
to make minor adjustments. If you notice a for PMI’s PMP Exam (2021 Update)
difference it is intentional and not an
indication of exam changes.
AGILE VALUE PROPOSITION
Visibility Adaptability

Agile

Traditional

Business Value Risk

TRADITIONAL
PROJECT LIFE
CYCLE Starting the
project
Organizing and
preparing
Closing the
project

Traditional project
management Cost and
Staffing Level
can also be called:

• Waterfall
• Plan-driven
Project charter Accepted deliverables
• Predictive
Project management plan Archived project documents

Time
 Planning Planning Planning

Carrying out Carrying out Carrying out

AGILE
the work the work the work

PROJECT
LIFE CYCLE
Starting Closing
the project the project

Agile is iterative and adaptive.

There are multiple planning
phases.

Time
 PROBLEMS WITH EXCESSIVE PLANNING

• Team lacks information

• Execute toward the wrong goals
• Value isn’t maximized
• Decreased customer satisfaction
• Rework
 DELIVER VALUE EARLY

Over time, things change

• Threats can appear
• Opportunities can fade Agile is characterized by frequent, short iterations
• Benefits can decrease
Deliver before things change

Business value is recognized sooner

 TRADITIONAL VS. AGILE
Predictive Agile
• Waterfall methodology • Incremental
• Fully plan driven (predictive) • Adaptive
• Phases are sequential with handoffs • Iterative
from one phase to the next • Empirical
• Good for well known products
• Defined and linear Feedback

Feedback
Requirement
Cycle

Design

Development Cycle

Testing Cycle
Deployment
Feedback
 HYBRID APPROACHES
• A combination of Traditional and Agile approaches, usually determined by the
type of project work
• May be appropriate when customers or vendors work together but favor
different methodologies

Agile
Agile Traditional
Traditional

Agile Traditional
Traditional Agile
AGILE CHARACTERISTIC: INCREMENTAL

Requirements Requirements Requirements Requirements

Design Design Design Design

Development Development Development Development

Testing Testing Testing Testing

Delivery Delivery Delivery Delivery

AGILE CHARACTERISTIC:
ITERATIVE
• Opportunity to make changes
• Add features with each iteration
 CHARACTERISTICS OF PROJECT LIFE CYCLES

Approach Scope Activities Delivery Goal

Traditional Well-known Performed once for the Once at the end Manage schedule and
entire project budget

Iterative Evolving Iterated until correct Once at the end Correctness of

deliverable
Incremental Evolving Performed once for each Frequently Speed
increment

Agile Evolving Iterated until correct Frequently Customer satisfaction via

frequent delivery and
feedback
 EMPIRICAL

Empiricism is a fact-based, evidence-based approach that removes subjectivity from the

process.
• Based on observation and evidence
• Not theoretical

“If we continue working at this pace we “We have delivered a minimum viable
should finish on time and deliver a product with the following working
valuable product.” features.”
 THE AGILE MANIFESTO
In 2001, seventeen software developers met at a resort in Snowbird, Utah to
discuss existing software development methods, among others Jeff Sutherland,
Ken Schwaber, Jim Highsmith, Alistair Cockburn, and Bob Martin. Together they
published the Manifesto for Agile Software Development.

The Four Values of the Agile Manifesto

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

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan There is value in these items, but we value the
items in red more.

© 2001, the Agile Manifesto authors

 THE 12 CLARIFYING PRINCIPLES
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. Businesspeople 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, developer, 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 adjust its behavior
accordingly.
AGILE TEAM
CHARACTERISTICS

• People over processes

• The team decides on the processes and
tools
• High-performing teams = project success
• “Being” agile vs. “doing” agile
 ORGANIZATIONAL AGILITY
• Is your organization agile, or ready for agile?
• Perform assessments
• An Organizational Transformation Checklist, by Agile Alliance
https://www.agilealliance.org/wp-content/uploads/2016/02/An_Organizational_Transformation_Checklist.pdf

• Seven Questions to Determine if Your Organization is Agile Ready, by the Project Management Institute
https://www.pmi.org/learning/library/determine-organization-agile-scrum-ready-6129
 AGILE METHODOLOGIES

There are over a dozen agile methodologies

No single right way
Can be tailored once a team is experienced
Most common
• Scrum (really a framework)
• Extreme Programming (XP)
• Lean product development
• Kanban
• Feature-driven development (FDD)
• Dynamic Systems Development Method (DSDM)
• Crystal
SCRUM GUIDE

https://www.scrumguides.org/
 Framework rather than a methodology
Scrum is Agile
Agile is not only Scrum
Employs various techniques
High-performing cross functional teams
Iterative, incremental approach
Iterations are known as “sprints”

The term “scrum” comes from rugby.

A scrum (short for scrummage) is a method of restarting play. The
players pack closely together with their heads down and attempt to
gain possession of the ball.
 TEAM GROUND RULES
Code of Conduct
• What is acceptable?
• What is not acceptable?
• Communication expectations
• Attendance expectations
• Performance expectations
• Decreases misunderstandings
• Improves performance outcomes

Team Charter
• Shared values
• Guidelines for communication
• Tools to be used
• Process for decision-making
• Process for problem-solving
• Meeting calendar and procedures
• Governance
 </>

Includes:
Developers
Developers
Scrum Master
Product Owner

Scrum Master Product Owner

Develops product vision
Product Owner
Serves as voice of the stakeholders (liaison)
Collects and prioritizes requirements
Controls budget
Oversees return on investment
Determines value of features
Validates product quality

Stakeholders
 • Also know as the “Development Team”
• Not necessarily a technical role
</> • Self-organized
• Build the product increments during each sprint
• Estimate the work
• Decide what can be done during each sprint
• Cross-functional
• Every necessary skillset is represented
Servant leader to the developers
Ensures adherence to Scrum framework
Facilitates meetings
Removes impediments (roadblocks, blockers)
Serves as a buffer to prevent interruptions
Provides essential resources
• Tools
• Resources
• Rewards
• Encouragement
Coaches team members
Assists product owner with managing backlog
Serves as Scrum “ambassador” to the organization
SERVANT LEADERSHIP:
CORE DUTIES
• Serve as a buffer to prevent interruptions
• Remove roadblocks
• Communicate the product vision
• Provide essential resources
• Tools
• Resources
• Rewards
• Encouragement
Team Characteristics Individual characteristics
• Individuals take ownership of work • Emotionally intelligent

• Members are empowered to make their own decisions • Works with integrity
• Sense of responsibility
• Open and frequent communication encouraged
• Self-confident
• Balance between collaboration and cooperation
• Comfortable asking for help
 SAFE ENVIRONMENT
• Truthful
• Honest
• Accountable
• Respectful
• Authentic
We are in this together,
and it is okay to fail. • Competent
 TEAMS
• Alternate spellings
• Colocation
• Collocation
• Face-to-face interaction
Team
33 ft/10m • “Virtual” co-location uses tools to overcome distance
• Videoconferencing
• Skype
• Live chat
Too much distance • Instant messaging
• Web-based tools
A “distributed” team has one or more team
• Agile software
members located outside of the team’s location
Short, simple descriptions of a feature
Told from the user’s perspective
When large or complex, can be called “epics”

Sentence structure:
“As a role, I want functionality, so that business benefit.”

Example:
“As a customer, I want my credit card information to be
stored, so that I save time when checking out.”
Keep them simple
• Gather feedback
• Experiment
• Use storyboards
• Use annotations
• Provide explanations

Depict user stories visually

• Wireframes
• Form of modeling
• Better solution understanding
• Provide format for feedback
• Ensure stakeholders on same page
• Provide blueprints for design visuals
• Provide technical requirements understanding
 INVEST CRITERIA

Independent - developed in any order

Negotiable - discussions with product owner
Valuable - justify the work
Estimatable - quantify the effort
Small – reliable estimates of 4-40 hours of work
Testable – measure progress and acceptance

I N V E S T
THE AGILE INVERTED TRIANGLE

AGILE

Cost Time

Scope
Prioritized list of everything that is needed Backlog Product
in the product increment
Single source of product requirements A
Always changing F
Items are added, dropped, and
C
reprioritized based on value
The product is built incrementally based J
on work selected from the backlog
D
H
 SPRINT BACKLOG
Sprint Backlog
Belongs to the developers
Developers

}
Subset of the product backlog
A
Goal for the current sprint
Highly detailed and visible F
C </>
J
D
H
C The result of the latest sprint
J Demo during sprint review

D Must meet the “definition of done”

established during planning
H
 METAPHOR
• Shared technical vision
• How the system should work
• Common vocabulary
• All stakeholders understand

“This music app will be like a

mind-reader. It will know which
song you would like to listen to
without having to ask you.”

“This exercise bike will make

you feel like you are in your
own private fitness studio.”
Short iterations Visibility
• Visibility and transparency
• Frequent meetings and demonstrations

Improved communication
• Ongoing dialogue
• Continuous feedback
• Change requests Agile
• Issues
Traditional
ENGAGING
STAKEHOLDERS

Keeping stakeholders committed

requires:

• Senior management support

• Training key stakeholders on
technologies and processes
• Flexibility
• Accept customer
representatives

Engagement critical in every phase

DIFFICULT
STAKEHOLDERS
%*#&!
May impede the project
Require special handling
• Shield the team
• Emotional intelligence skills
• Interpersonal skills
• Escalate
Scrum Master or
Establish a process during planning Project Manager
EDUCATING AND
ENGAGING
STAKEHOLDERS
Stakeholders may:
• Not understand Agile
• Not understand their role
• Be overwhelmed with work
• Disengage or not participate if not accountable

Stakeholder levels of commitment:

• Committed
• Reluctant to commit
• Enthusiastic only at beginning (short iterations help
with this)
• Quick reminder of stakeholder needs
• Composite
• Represents majority of actual users
• Not a replacement for stakeholders
• Focus on value and priorities

Mario is an employee of ABC Company. He must use his ID

badge to access his work computer. For security reasons, the
computer automatically logs users out after 5 minutes of
inactivity. Mario would like to remain logged in while he is
sitting at his desk.
PERSONAS: BEST
PRACTICES
Best practices:
• Based on reality
• Specific
• Have defined goals
• Include negative personas
• The end user you are not designing for
• Ex: the user who always cancels after the free trial
Ideally 3 or less, or the product may become confusing
Stakeholders are not “managed”
• Collaboration
• Servant leadership/stewardship
• Not top-down

 ✓
MANAGING
STAKEHOLDER
EXPECTATIONS
• Scope is evolving
• Need shared vision
• Definition of Done
• Tools for shared vision
 PROJECT REQUIREMENTS

How the customer How the project leader How the analyst How the programmer What the beta testers How the business
explained it understood it designed it wrote it received consultant described it

How the project was What operations How the customer was How it was supported What marketing What the customer
documented installed billed advertised really needed
PRODUCT VISION
Why you’re building a product
Benefits of product
Since scope is evolving it is important to
share an understanding of what is being
created
Definition of Done (DoD)
“Gulf of evaluation”
CREATING THE
PRODUCT VISION
? ?
• Interview stakeholders
• Focus on how a product adds value
? ?
• Motivates the developers
• Shouldn’t take longer than an elevator ride (2 min)
• Helps to create the charter

For: Customer

Who: Need or problem

Our: Product or service

Provides: Unique features or

benefits
As opposed to: Competitor product

We: Differentiator

For customers who need immediate answers to their questions, our client
support includes 24/7 live coverage.
Unlike the average company’s 24-hour email response, we are always
here to take your call.
 PRODUCT VISION BOX

Front of the box

• Product name
• Relevant graphic Click and View
• Key benefits Movies on Demand

Back of the box

• Detailed product description • Largest library of titles
• Product functional requirements
• Suggested titles by user profile
• Pause subscription feature
 TWEET

• Stakeholders describe objective using a

limited number of characters
• 280 characters or less
• High-level understanding of project
• Helps to create the charter
 RELATIVE PRIORITIZATION AND SCOPE CHANGES

Product
New features can be inserted into the priority list

}
Backlog
• Developers estimate the effort
A
• Product owner decides priority Minimum viable
F product (MVP)
All work should be included C
• Bug fixes J
B
• Changes Feature D falls below the
D
Allowable budget or
allowable budget schedule
• Single, prioritized list H
 MINIMUM VIABLE PRODUCT (MVP)

Also known as minimum marketable feature (MMF)

• Complete enough to be useful
• Small enough that it is not the entire project scope
• Early release of MVP allows for rapid feedback and
changes
• Additional functionality can be included in future
releases
 PRIORITY MATRIX
Urgency
Can be tailored
• Value Low High
• Cost

High
• Risk
• Complexity/releasability

Importance
Low
 Category User Stories

Must have Must have Included with the release

o
Not critical but still
Should have
Should have important

Useful and would add

Could have Could have
value
o Excluded from this
Won’t have
release
Won’t have/would like to have
Would like to have Retained for the future
• Participants use money to “buy a feature”

• Features with the most money are the highest

priority

• Feature prices may be set based on story

points, hours of effort, or complexity
 User Story 1
…
• Each stakeholder has 100 points to spend
on requirements
50 points
• The points can be allocated in any way Most important

• Requirements are prioritized by points User Story 2 User Story 2 User Story 2
… … …

10 points 10 points 10 points

The 100-point method was developed by Dean Leffingwell and Don Widrig for use cases.
Follows brainstorming
Each person can vote for 20% of the choices
Results show which features are valued by the
most stakeholders

Example:
20 items must be prioritized
Each person gets 4 votes
 REQUIREMENTS PRIORITIZATION MODEL

Evaluates each feature based Weight 2 1 1 .5

on multiple criteria Relative Relative Total Value Relative Cost % Relative Risk % Priority
Benefit Penalty Value % Cost Risk
Customer ratings
Feature 1 5 3 13 16.8 2 9 1 5.8 1.345
• Benefit of having feature
Feature 2 5 5 15 19.5 3 13.6 2 11.8 .957
• Penalty for not having it
Feature 3 4 9 17 22.1 4 18.2 4 23.5 .708
Developer ratings Feature 4 6 2 14 18.2 4 18.2 3 17.6 .646
• Cost of feature Feature 5 7 4 18 23.4 9 40.9 7 41.2 .365
• Risks Totals 27 23 77 100 22 100 17 100
Weighted Formula

The requirements prioritization model was developed by Karl Wiegers.

Story points
• Relative estimation
• Arbitrary measure
• Usually used by scrum teams
• Express effort required to implement a
story
• 3 items taken into consideration: level of
complexity, level of unknowns, effort to
implement.
• Collaboration activities
• Brainstorming activities
• Drawing
• Storytelling
 STORY POINTS
Relative sizing 3 5 8
• We aren’t good at absolute estimates 13
• We are better at relative estimates
Not tied to days, hours, or dates
• Removes pressure or emotion
Based on quantity of work, not speed
Unique to a team
• Not comparable to the work of other teams While story points is the most
• Removes competition between teams commonly used metric, teams may
choose any unit to represent work.
Reference for future estimates
Reserves and buffers are not necessary
Sequence of numbers
• Used for estimating story sizes
• Each number is the sum of the two preceding
numbers
• 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on
1 2 3 5 8 13 AFFINITY
ESTIMATES
Quick and easy method
Group User Stories
• Follows estimating
• Similar sizes are grouped together

Prevents story point inflation

Quick and easy technique
Absolute value not considered L
T-shirt sizing
M
Similar to Fibonacci
• Sizes instead of numbers S
3 Uses Fibonacci sequence
5
8 Each player receives a deck of cards
13
• Facilitator reads a user story
• On the count of 3, everyone shows their estimate
• Purpose is to build consensus
• close to consensus, move on and round to higher
number
• Scattered estimates, discuss and estimate again
• Estimates are approximates
Product Vision

Product Roadmap

Release Planning

Iteration Planning

Daily
Planning
 STORY MAP: THE BACKBONE

User’s perspective
Activities required to use the product Features Backbone

Ordered chronologically
Activities may be re-arranged or new

User Stories
activities may be added
Example:
• Search for a class
• Register for the class
• Submit payment
Story map with timing of
deliverables 1st release

Considers priorities against

development team velocity
Subject to change as backlog is
2nd release
refined
With each release the product
becomes more robust 3rd release
 ADAPTING THE PLAN

• Road trip
• Itinerary
• Fully plan-driven vs adaptive planning
• Threats
• Accidents, weather, mechanical issues
• Opportunities Lightweight plans promote adaptability
• Value-added activities
• All stakeholders participate
• Not scope creep
 SCHEDULE BUFFERS
Not recommended
• May appear that team is padding the schedule
Variance
+/- 40

+/- 25%
+/- 10%
+/- 5%
• If used, buffer the number of sprints needed rather than
Time
individual task estimates
Exceptions
• When customer insists on a firm estimate
• Must account for contingencies
• When team velocity is undetermined
• When there are regular interruptions
Estimate in ranges
Barry Boehm’s Estimate Convergence Graph
Iteration 1 Iteration 3 Release

Iteration 2 Iteration 4
With each release, product
becomes more robust
 THE SCRUM FRAMEWORK
Inputs from Executives, Team, Stakeholders,
Customers, and Users

Burndown/up
charts

Daily Scrum
meeting

Every
24 hours

Scrum
Product Owner The Developers 1-4 week
Master Sprint Review
sprint
Task
A breakout
Team selects as
F
many items as it
R can commit Sprint end date and
Sprint Finished work
C to deliver by Team deliverable
end of sprint Backlog do not change
J
B
Product Backlog Sprint planning meeting Sprint Retrospective
PARKINSON’S
LAW
Work expands to fill the available
time
Similar to Student Syndrome

Effort
• Leave work until the last
possible moment
Timeboxing can help

Time allowed
 TIMEBOXING

• Iteration is timeboxed
• Ex: 2 weeks
User story #1
• User stories are estimated
• Planned into the iteration
• If it doesn’t fit it has to wait
User
• Tool for completing work story #2

User User
story #3 story #4
 SPRINT PLANNING
Participants
Product Backlog
• Scrum Team
• Product Owner A
• Developers
• Scrum Master F
Actions C
• Product owner presents the updated
backlog J
• Team members pull from the product
D
backlog
• Team commits to a set of deliverables H
for the sprint
• Establish “Definition of Done”
Typically 2 hours per week of sprint
 DECOMPOSING THE WORK

• Only decompose the work for this

Sprint Backlog Tasks
iteration.

}
A
“Just in Time” (JIT) F

H
 TEAM VELOCITY
Velocity:
• Actual amount of development work
completed per a certain amount of time or
time-box
• Usually measured using a sprint as the time-
box
• Used to estimate how quickly a certain
amount of work can be completed
• Expressed as points (typically)
• Useful for forecasting
Use historical velocity data and take an average
If first time:
• Historical value from other projects
• Run a few iterations for a baseline
 VELOCITY VS CAPACITY
Velocity is based on story points achieved Capacity is based on team’s availability to do
historically the work
Occurs during the sprint
Participants
• Developers
• Scrum Master
• Product Owner may observe
Three main questions
• What have I done since the last stand-up?
• What do I plan on doing today?
• Do I have any roadblocks or impediments?
Typically 15 minutes or less
Reserve off-topic subjects for a separate discussion
 SCRUM OF SCRUMS

Used to scale Agile

• When teams are >12 members Team B Team C
Team A
• Each team selects an ambassador
Report on
• Completions
• Next steps
• Impediments Ambassador Ambassador Ambassador
Resolve coordination challenges between
teams
Scrum of scrums has its own backlog of these There is also a scrum of
items scrum of scrums!

May meet a few times per week

SPRINT REVIEW
Occurs at the end of a sprint
Participants
• Developers
• Scrum Master
• Product Owner
• Stakeholders (potentially)
Developers demo the product to Product Owner and
possibly stakeholders
Product Owner inspects deliverables
Elicit feedback and foster collaboration
Team and Product Owner adapt product backlog if
necessary
REVIEWS AND
FEEDBACK
Plan
Product feedback loops
• Based on Deming cycle of Plan, Do, Check, Act
• Plan = plan created
• Do = plan implemented or executed Do Check
• Check = measure performance
• Act = take action, change course, adapt based on
learnings

Act
 SPRINT RETROSPECTIVE

Participants
• The Scrum Team
• Developers
• Scrum Master
• Product Owner
Evaluate the last sprint
• People </>
• Processes
• Tools
Plan improvements for next iteration
Typically .75 hours per week of sprint
 BACKLOG REFINEMENT

New features can be inserted into the

}
priority list
A
• Developers estimate the effort
• Product owner decides priority F Minimum
viable product
All work should be included C (MVP)
• Bug fixes
J
• Changes
B
• Single, prioritized list D
Feature D falls below Allowable budget or
the allowable budget H schedule
 AGILE TOOLS

• Simple
• Low tech - Estimate new user stories
B, D, H
• High touch
- Discuss with product owner
• Visible Prioritize changes for next sprint
• White boards
- Prepare for demo
• Sticky notes - Update on resources
• Charts
• “Information Radiators”
• Large charts clearly displayed
 PROBLEMS WITH HIGH TECH TOOLS

• Alters perception of data accuracy

“If the system sophisticated the data must
be good”
• Logins and passwords reduce stakeholder
access
• Fewer users have access to update the plan
• Creates delays in receiving latest information
• Complexity reduces understanding
 KANBAN BOARDS

• Generic Agile term is “Task Board”

• Kanban boards show Work in Progress $
(WIP)
• Limiting WIP increases productivity
• WIP limits cap the number of items in
each column
• Reduce Inventory
• Reduce bottlenecks
• Improve rate of throughput
• Control workloads of team members Metered entry
• Goals:
• Consistently sized tasks
• Couple of days duration each
• Assign to skills
• Reduce idleness
• Protect quality of work
PRODUCT QUALITY
• Verification
• Is the right product being built?
• High-level activity
• Meets customer needs

• Validation
• Is the product being built right?
• Granular activity
• Consistency and standards
• Walkthroughs, inspections, testing
• Should accompany a user story

• Helps to translate the story into tasks

Helps to avoid stalling at 95% (just one
more thing)
Also known as “done done”
Use a separate DoD for each level of the
project work
Makes progress easier to assess
Prevents disagreements and scope creep
Differences Acceptance Criteria Definition of Done
Scope Specific (user story) Applies to all work

Purpose Meet user needs Team’s shared vision

Features Functional features for users Includes non-functional and quality

requirements

Similarities • agreed to as a team

• updated as new learnings come to light
• testable
• clear
• concise
PERFORMANCE
TRACKING:
BURN CHARTS
360

270
Burndown and burnup
charts Story 180
Points
“Information Radiators”
90
• Generic term for a highly
visible information display 0
0 1 2 3 4 5 6
• Graphs, charts, data
Sprints
dashboard
• Communication tool
Help organizations manage risks and resources

Firm fixed-price contracts are not

suitable for Agile projects
• Modified fixed price contracts
• Flexibility to make changes
Changes for free
• Customer must be highly involved with the project
• Reprioritize backlog
• Cancel the contract for a % of remaining work
Customized contracts
• Combination of different contracts
 A $5,000
Helps with accurate estimates
Fewer unknowns F $3,500
Reduces need for contingency funds
C $10,000
Allows for progressive elaboration
• Re-estimate based on new information
J $7,500
• Evaluate new risks

D $2,500

H $5,000 Can re-estimate later

 GRADUATED FIXED PRICE CONTRACT

Financial incentive to finish early Early

$165/hour
• Fewer hours
• Higher rate
• Paid sooner
On Time
Late $140/hour
• More hours
• Lower rate
Late
$115/hour

Graduated fixed price contracts

were introduced by Thorup and Jensen
 DAILY BOOTCAMP SURVEY

Please share your thoughts.

At the end of each Bootcamp session please let us know how we are doing. Your feedback helps us to offer the best possible
Bootcamp experience.

Thank you for attending Session 5!