PMP Drag Drop Terms Flashcards
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.
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. Overinflating 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 ba
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.”
