For PMP Exam 35 PDU Course on Udemy. Not for free distribution.

© PMPWITHRAY

Important Terms for PMP Exam (Drag & Drop/Fill-in/Scenario Questions)

1. Antipattern
2. Backlog Grooming
3. Cadence
4. Chicken & Pigs
5. Dropped Baton
6. Fail-Fast
7. Hofstadter’s Law
8. Parkinson’s Law
9. Bike-shed Effect
10. Peter Principle
11. Sand-Bagging
12. Self-Protection
13. Student Syndrome
14. Refactoring
15. Scrum of Scrums
16. Scrumban
17. Snackwell Effect
18. Swarming
19. Technical Debt
20. Test Driven Development
21. User Persona

Antipattern
An antipattern is a seemingly obvious but wrong answer to a common problem. It’s an ineffective
solution, often with negative consequences. A simple example is Death by Planning, the belief that
more planning will lead to less risk and hence a better or more predictable project outcome.

Agile teams may do specific exercises to identify antipatterns or “bad habits” in their work. Agile
Coaches or Scrum Masters may also do work with teams to de-bug embedded antipatterns.

The antonym of an antipattern is a design pattern, a straightforward, effective solution to a

prevalent problem.

Backlog Grooming
Backlog grooming occurs at the end of a sprint, when the team meets to make sure the backlog is
ready for the next sprint. The team may remove user stories that aren’t relevant, create new stories,
reassess priority, or split user stories into smaller tasks. Backlog grooming is both an ongoing
process and the name for the meeting where this action occurs (a backlog grooming meeting). This
is also known as backlog refinement.

Once the team finishes a sprint, a backlog grooming meeting is scheduled. Backlog grooming is
meant to ensure the backlog only contains items that are relevant and that meet objectives.

Cadence
Cadence describes the flow or rhythm of events or tasks in a project. It establishes a pattern that the
team can follow to understand what they are doing and when it will be completed.
 For PMP Exam 35 PDU Course on Udemy. Not for free distribution. © PMPWITHRAY

Agile teams strive to achieve a cadence during their project. For example, in Scrum, fixed-length
iterations, called sprints, last one to two weeks and allow the team to ship software on a regular
cadence. In Kanban, the cadence is the continuous flow of work.

Chicken and Pigs

The terms “Chicken” and “Pig” come from “The Chicken and Pig Story” by Ken Schwaber, a
software developer who helped formulate the initial version of Scrum. Most often used in Scrum, a
“Chicken” refers to someone who is involved in the project, but is not accountable for any specific
deliverable (such as a stakeholder or manager). On the other hand, a “Pig” is someone who is
committed and directly accountable for deliverables.

Chickens and Pigs are used to define participants and roles in Scrum. “Pig” roles are usually the
actual team members, the Scrum Master, or the Project Owner. “Chicken” roles are managers or
stakeholders.

Dropped Baton
Delivering a project can be a bit like a relay race. Each stage from design and planning to
completion needs to be handed over without breaking stride. And to pursue that analogy, it’s often
linked to deliverables (batons) being passed from one stage to another seamlessly across teams.
Similar to ‘batons’ being passed over from one team to another in a relay race. A ‘dropped baton’
happens when there is a gap in the handover during transitioning from one stage to another.
Ideally, in a project there should not be any ‘dropped batons’ within teams or between phases.

Fail-Fast
Fail-fast is the process of starting work on a task or project, obtaining immediate feedback, and
then determining whether to continue working on that task or take a different approach—that is,
adapt. If a project is not working, it is best to determine that early on in the process rather than
waiting until too much money and time has invested.

A team starts a new project or task, obtains feedback early on, and then conducts an analysis to
determine whether the project will be functional or successful. If a task or project is moving in the
wrong direction, team members are encouraged to stop work as soon as possible.

Hofstadter's law
Hofstadter's law states that a project always takes longer than expected, even when the law is
taken into account. Simply put, time estimates for how long a project will take to complete always
fall short of the actual time required to complete it.

The law holds true even when the time allotment is increased to compensate for the human
tendency toward underestimation. In other words, the law still proves true even when you factor in
the possibility that you may need more time to complete the project. Hofstadter's law is frequently
evoked in the context of IT and software development. It is particularly relevant to time
management, productivity, project management and DevOps.

Hofstadter’s law is sort of an inverse of Parkinson’s Law as discussed below.

One needs to have a good balance between Hofstadter’s Law and Parkinson’s Law to arrive at
accurate estimates in project management.
 For PMP Exam 35 PDU Course on Udemy. Not for free distribution. © PMPWITHRAY

Parkinson’s Law
Parkinson’s Law states that work expands to fill the time allotted for its completion.

Time management is all psychological. We naturally pace ourselves to finish a project in the nick of
time. The same task can take one hour or one week depending on how much time we give ourselves
to complete it. Ever pull off a big presentation where your only prep was during your commute on
the way over? The law is true!

In order to maximize efficiency of your projects, you need to be aware of this law while building
estimates for cost or schedule.

Parkinson’s Law of Triviality/Bike-Shedding/Bike-shed Effect

The law of triviality is an argument that people within an organization commonly or typically give
disproportionate weight to trivial issues. Parkinson provides the example of a fictional committee
whose job was to approve the plans for a nuclear power plant spending the majority of its time on
discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the
staff bicycle shed, while neglecting the proposed design of the plant itself, which is far more
important and a far more difficult and complex task.

The law has been applied to software development and other activities. The terms bicycle-shed
effect, bike-shed effect, and bike-shedding were coined based on Parkinson's example; it was
popularised in the Berkeley Software Distribution community by the Danish software developer
Poul-Henning Kamp in 1993 and, due to that, has since become popular within the field of software
development generally.

Peter Principle
The Peter principle is a concept in management developed by Laurence J. Peter, which observes
that people in a hierarchy tend to rise to "a level of respective incompetence": employees are
promoted based on their success in previous jobs until they reach a level at which they are no longer
competent, as skills in one job do not necessarily translate to another.

The concept was explained in the 1969 book The Peter Principle (William Morrow and Company) by
Laurence Peter and Raymond Hull. Peter and Hull intended the book to be satire, but it became
popular as it was seen to make a serious point about the shortcomings of how people are promoted
within hierarchical organizations. The Peter Principle has since been the subject of much
commentary and research.

Sand-bagging
Sandbagging is a term used to describe the act (and sometimes art) of under promising and over
delivering. If someone is sandbagging they set expectations for a certain level of delivery or
performance they know they can hit with ease. Then, when it comes time to deliver on the promise,
they crush their targets.

This is a common anti-pattern with Objectives and Key Results. Teams, especially those not fully
sold on the goal-setting framework, define success targets for themselves they know they can hit.
This way work can continue, more or less, as usual and the discomfort of change or a new way of
working can be avoided.

In line with this principle, project teams often tend to build extra buffer on estimates. Eg. Over-
inflating cost or schedule estimates and then closing them within normal targets, but thus showing
to management that they have ‘over delivered’…which is clearly not the case.
 For PMP Exam 35 PDU Course on Udemy. Not for free distribution. © PMPWITHRAY

As the project manager, you need to be cautious of this principle, and set targets & timelines which
are stretched enough to challenge your team, however being realistic.

Self-Protection
Self-protection is the tendency of team members to protect themselves or their image while
committing to some deliverable. It’s comes as an offshoot of the sand-bagging principle (discussed
above) where people always want to be in the good books of their manager/client. So, while
committing to timelines and cost estimates, they will often build unnecessary buffers which might
over-inflate your project cost or duration.

On similar lines, self-protection in conflict management means the ways team members often try
to justify how they are right and the other party is wrong. Self-protection makes them to say or do
things which cannot hurt them now or in future. This comes from the very basic instinct of human
being which involves protecting itself from any potential threats in future.

Student Syndrome
Student syndrome refers to planned procrastination, when, for example, a student will only start to
apply themselves to an assignment at the last possible moment before its deadline. This eliminates
any potential safety margins and puts the person under stress and pressure. According to one
academic source, it is done in order to induce a level of urgency high enough to ensure the proper
amount of effort is put into the task.

The term is used to describe this form of procrastination in general, and not only by students. For
example, in the field of software engineering: "This initial research investigates three behavioural
issues which may affect team member productivity in both a traditional waterfall project and in a
Scrum project: the management of stress, the use of slack and the student syndrome."

Refactoring
Refactoring code means to improve, clarify, and streamline the internal structure of existing code
without affecting its external behaviour. Refactoring does not include rewriting code or fixing bugs.
The noun “refactoring” refers to specific, finite methods for refactoring code, such as using Extract
Method to clarify the purpose of a piece of code.

Refactoring is used in Agile to maintain code clarity and extensibility between sprint iterations.

Scrum of Scrums
A Scrum of Scrums meeting is a scaling mechanism used to manage large projects involving Scrum
multiple teams. A Scrum of Scrums is held to facilitate communication between teams that may
have dependencies on one another. One member from each team attends the Scrum of Scrums to
speak for the team—this could be the Scrum Master but may be any team member who can
effectively relay information and handle questions or concerns for the team.

If a Scrum team is working on a large project that involve dependencies, risks, or issues that could
impact another team team’s sprint, a Scrum of Scrums is scheduled as a communication forum for
discussing or resolving these issues.

Scrumban
Scrumban is a hybrid of Scrum and Kanban used to accomplish tasks and produce deliverables.
 For PMP Exam 35 PDU Course on Udemy. Not for free distribution. © PMPWITHRAY

Scrumban is used when a Scrum team wants to apply some Kanban methodology into their process
by focusing in on work-in-progress and continuous improvement. Or, a Kanban team may want to
apply some Scrum structure into their process, such as daily standups or roles.

Snackwell Effect
The SnackWell effect is a phenomenon whereby dieters will eat more low-calorie cookies, such as
SnackWells, than they otherwise would for normal cookies. Also known as moral license, it is also
described as a term for the way people go overboard once they are given a free pass or the
tendency of people to overconsume when eating more of low-fat food due to the belief that it is not
fattening.

In project management, Snackwell Effect needs to be kept in mind while assigning delegation
authorities as part of project governance. Eg. If you agree that your team leader can approve any
orders <$5,000 without your alignment, it might happen that the team leader will exhibit Snackwell
Effect and keep on approving unnecessary orders just because they are <$5,000. This may have a
significant impact on your project in long term.

Swarming
Swarming is when team members with appropriate skills work together to complete a task that a
team member is having trouble completing on his or her own.

Swarming is used to quickly bring a task or work item to completion before moving on to the next in
order to keep workflow and delivery on track. Kanban teams in particular use swarming to ensure
continuous workflow and maintain Work-in-Progress (WIP) limits.

Technical Debt
Technical debt refers to the obligation a development team incurs when they use a short-term,
expedient approach to developing a software package without considering the long-term
consequences. Technical debt increases project cost and complexity due to inefficiencies,
inaccuracies, and other issues introduced into the software package. Poor management,
incompetency, timeline pressure, or inadvertent mistakes can all contribute to technical debt.

Technical debt is used as a motivation for the team to focus on quality and added value during
development. This can translate into diligently and consistently refactoring and reviewing code,
running automated unit tests, and integrating code on a consistent basis. Pair programming is often
helpful in guarding against technical debt. Creating an environment where team members are
encouraged to increase relevant knowledge and experience also helps prevent technical debt.

Test-Driven Development
Test-Driven Development is the practice of designing and building tests for functional, working
code, and then building code that will pass those tests.

TDD helps increase the team’s understanding of the code’s purpose and how it should work before
beginning development. The team then writes code that meets the test criteria. Teams using TDD
create more streamlined and higher quality code that meets test and acceptance criteria.

User Persona
A User Persona is a detailed hypothetical description or biography of a typical end-user who will be
using the product. Personas usually take the form of a written document, complete with stock
 For PMP Exam 35 PDU Course on Udemy. Not for free distribution. © PMPWITHRAY

photo, name, profession, style of living, and other details pertinent to their being categorized as an
end-user.

Agile designers and developers use personas as a guide toward developing a product that fit the
needs of a specific type of end-user, or multiple types of end-users. The team may use personas to
decide whether to add specific features, interactions, or visual cues to the product.