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. 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 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.
