My Notes and Glossary

PMI-ACP Notes and Glossary

Most of these notes are copied form sources I used for my studying.

1. Three pillars of scrum methodology

1. 1. Transparency a common understanding of what done means in a scrum project

1. 2. Inspection reviewing the project to determine the completeness of the project; finding root cause of variances from the project goals

1. 3. Adaptation making adjustments to the scrum process to mitigate problems or bad trends

2. FDD feature driven development single owner for each section of code

3. Crystal family of methodologies depend on the criticality of defects and the size of the team

3. 1. Customized methodologies coded by color names

3. 2. Methodologies are appropriate for different criticalities and team Sizes

3. 3. Criticality is about the impact of a product defect design       

4. Refactoring is expected as part of every user story in every Sprint

5. Risk is the opposite of value. We can have risk register in agile

6. When we multiply the ranked probability and ranked impact of a given risk, the result is the "risk severity" of that threat. This calculation doesn't provide any information about the cost of the risk since the inputs don't include a monetary value.

7. Moscow In the MoSCoW prioritization scheme, the highest-priority, most fundamental requirements are "must haves." The next category, "should have," refers to requirements that enable the system to work properly; if we omit those features, the workarounds will be costly or cumbersome. This is the correct answer. The third category, "could have," covers any useful additions that add tangible value to the system but aren't required.

8. Requirements prioritization model: 

8. 1. benefit, penalty, cost, risk

8. 2. Uses a scale of 1 to 9

9. Fixed price vs t and m in agile projects contacts; standard graduated fixed price.

9. 1. Graduated Fixed Price. In this type of contract, hourly rates for the supplier differ based on delivery timing. If the team finishes early, the customer pays a higher rate for the fewer hours. If the team finishes late, the customer gets to pay a lower rate for more hours

9. 2. When using fixed-price work packages we break the work down into small components that are contracted at a fixed price. This reduces the scope and cost involved in each piece of work being estimated. The work can be estimated at the work package level, which allows the supplier to update costs as new details emerge. The customer can then reprioritize work packages based on these evolving costs.

10. Agile triple constraint, fixed cost and time, variable scope

11. Continuous integration requires upfront writing automated tests. Continuous integration is the practice of regularly incorporating new code into the code base and checking to make sure the system still works properly. This helps reveal whether there are any problems in the code so they can be addressed immediately.

12. XP core values are simplicity, communication, feedback, courage, respect/Humility

12. 1. Communication among team and project stakeholders

12. 2. Simplicity easier to explore an idea by drawing a diagram instead of writing lines of code

12. 3. Feedback communicating ideas through diagrams to quickly gain feedback

12. 4. Courage make decisions and changes by discarding or refactoring

12. 5. Humility humility to recognize that we don't know everything

12. 7. Respect is exhibited in the peer review process by understanding that others work differently, and embracing those differences.

12. 8. Retrospectives involve respect and courage

13. Only the XP methodology specifically includes the roles of programmer and tester separately. The Scrum methodology does not include the role of coach or programmer. 

14. 7 Principles of Lean Software Development

14. 1. Principle 1: Eliminate Waste.

14. 2. Principle 2: Build Quality In.

14. 3. Principle 3: Create Knowledge.

14. 4. Principle 4: Defer Commitment.

14. 5. Principle 5: Deliver Fast.

14. 6. Principle 6: Respect People.

14. 7. Principle 7: Optimize the Whole

15. A core concept of the lean approach--"building in" quality throughout the development process. Lean optimizes the whole, not the pieces; defers decisions rather than making them quickly; and focuses on eliminating waste, not analyzing and documenting it. (Although root cause analysis could be a helpful tool in reducing waste)

16. The most similar roles are called Scrum Master and development team.

17. Project elevator statement vs project charter

18. User persona vs snapshot

18. 1. Personas are used to focus on the features that users find valuable

19. In agile projects the team is accountable for issues not an individual. Issues should be shared with the team

20. Remember the future: for risk identification

21. Review risk before prioritization

22. Risks are entered in the backlog based on expected monetary value.

23. Limiting WIP is to maximize throughput of work

24. The Kano Model (pronounced “Kah-no”) is an approach to prioritizing features on a product roadmap based on the degree to which they are likely to satisfy customers.

24. 1. Delighters exciters

24. 2. Satisfiers are the types of items that provide value to the customer but aren't as exciting or novel as Delighters/Exciters.

24. 3. Dissatisfiers

24. 4. Indifferent

25. Exploratory Testing is widely used in Agile models and is all about discovery, investigation, and learning. It emphasizes personal freedom and responsibility of the individual tester. Exploratory testing should be used in additional to functional testing. Exploratory testing is not instead of functional testing, nor is it focused on functional details in user stories. It should also not be avoided.

26. Smoke Testing is a software testing process that determines whether the deployed software build is stable or not. Smoke testing is a confirmation for QA team to proceed with further software testing. It consists of a minimal set of tests run on each build to test software functionalities. Smoke testing is also known as "Build Verification Testing" or “Confidence Testing.” It is a mini and rapid regression test of major functionality. It is a simple test that shows the product is ready for testing.

27. Gulf of evaluation The difference between what is said and what is understood. Intangible projects often experience this gulf. What does done looks like?

28. Acceptance TDD vs Standard TDD

28. 1. Analogous to test-driven development, Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality.  The collaborative discussions that occur to generate the acceptance test is often referred to as the three amigos, representing the three perspectives of customer (what problem are we trying to solve?), development (how might we solve this problem?), and testing (what about…). These acceptance tests represent the user’s point of view and act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended. In some cases the team automates the acceptance tests.

29. Red Zone”—an environment where turf is guarded and defensiveness abounds. The individuals who work in Red Zone organizations are short on trust, optimism and goodwill, what I call “Green Zone” qualities. When a project fails in a Red Zone workplace, people turn to shame and blame—focusing not on what went wrong, but on who did wrong.

30. Compliance work can be completed with each iteration, after product development, or both ways, with some of the work completed along the way and some done at the end. Compliance work does not have to be done using traditional methods, it does not have to be done only with each iteration, and it can be performed in a hybrid model.

31. There is no single best method for prioritizing agile work. Prioritization should be done by the Product Owner and development team and could use any method the team chooses.

32. CFD Cumulative Flow Diagram. A shallow area on a CFD indicates that the area is likely a bottleneck

33. In Test-Driven Development's defects are caught early. Test-Driven Development is not faster than standard development (as both development and unit tests must be completed), it does not cause extra work for the QA team

34. Acceptance Test Driven Development (ATDD) involves team members with different perspectives. ATDD has testers focused on exploratory testing primarily using automated scripts. Testing is only done further done the cycle when the item is done.

35. Personas are used to focus on the features that users will find valuable, as they describe the user in more detail.

36. Technical Debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it's the result of prioritizing speedy delivery over perfect code.

37. Swarming: Swarming occurs when as many team members as possible work simultaneously on the same priority item. And they work on just that one item until it is done

38. Value of empirical learning in Agile: Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans. Scrum also places great emphasis on mind-set and cultural shift to achieve business and organizational Agility.

39. Scrum has three roles: product owner, scrum master and the development team members.

40. The Five Scrum Events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, The Sprint.

41. Three Sprint artifacts: sprint backlog, product backlog, product increment

42. Level of mastery: novice, advanced beginner, competent, proficient, and expert

42. 1. You can start making decision at Proficient level. At the proficient level of mastering a skill, your decision making is still analytical, but you are becoming more comfortable relying on a gut feel rather than a rule. During the advanced beginner stage, you are beginning to understand the context of the rules and during the competent stage, you are deciding which rules are best for the situation. Becoming an expert means decisions are intuitive and spontaneous.

43. Soliciting feedback from stakeholders and review frequently to enhance value are part of “Avoiding potential downsides”

44. Systems thinking: One part of systems thinking includes classifying projects in term of their complexity in two areas; project requirements and the technological approach.

45. Value driven delivery is an overarching principle for an agile project.

46. MMf Marketable Features: Minimally Marketable Features. A small, self-contained feature that can be developed quickly and that delivers significant value to the user.

47. Defects that make it through all check-points to production are called escaped defects. This is the most costly type of defect since there will be a significant amount of rework, testing, retesting, and discovering any dependent code and going through the same process.

48. Common cause, special cause defect variation

48. 1. When the agile team has determined the difference is a common cause variance, the team lead should accept that there will be small differences and move onto the next task. Trying to rectify a common cause variance is a form of micromanaging the project instead of focusing on true roadblocks.

48. 2. The differences in productivity between high-performing and low-performing teams would be a special cause variation. The difference in productivity is not just some minor, random variation that may favor low-performing teams sometimes and high-performing teams other times. Instead, there is a fundamental difference between the teams. 

49. Visibility is defined as The concept that each team member's work and progress should be transparent to all stakeholders

50. Functional

50. 1. A lightweight non-functional UI design that shows the customer the vital elements and how they will interact before coding., non functional, prototype, model

51. Round Robin value: Presenting issues one at a time allows for discussion in the moment in addition to keeping the entire team engaged. When the list of failure points is complete and agreed upon, the team can prioritize the list and incorporate the fixes in the upcoming iterations.

52. Triple nickels: Brainstorming game, where participants sit in a circle and pass on a piece of paper with feedback to each other

53. Plus/delta exercise for retrospective

54. Providing caves and quite time for collocated team

55. Verification: A test of a system to prove that it meets all its specified requirements at a particular stage of its development.

56. Validation: An activity that ensures that an end product stakeholder’s true needs and expectations are met.

57. Adaptive leadership: Directing, Coaching, Supporting, Delegating. Early in a team’s formation, the leader directly helps with project activities and lays out a picture of what needs to be accomplished. The leader may also ask a lot of questions to ensure the team has an understanding of the team’s direction. While in the coaching phase, the leader mainly resolves conflicts so relationships are not damaged. During the supporting phase, the leader is still needed for conflict resolution in addition to challenging the team with high-level goals. The delegating stage is rarely achieved because teams are empowered.

58. A risk-adjusted backlog does not really produce a precise dollar value for either the list of work to be done or the risks or threats involved in the development. Instead, the exercise is used to facilitate discussions between the business and agile team about how to sequence the work items. Expected monetary value (EVM), risk probability and risk impact are all factors considered when calculating risk dollars.

59. What are some differences between Scrum and XP? 

59. 1. Scrum teams typically work in iterations (called sprints) that are from two weeks to one month long. XP teams typically work in iterations that are one or two weeks long.

59. 2. Scrum teams do not allow changes into their sprints. XP teams are much more tolerant to change within their iterations, though their iterations are much shorter than Scrum teams' iterations.

59. 3. Scrum doesn’t prescribe any engineering practices; XP does.

60. 3 Main Scrum Players

60. 1. Product owner – holds the vision for the product

60. 2. Scrum Master – helps the team best use Scrum to build the product

60. 3. Development team – builds the product

61. Four basic subdivisions of Value driven delivery?

61. 1. I Incremental Development

61. 2. II Risk control

61. 3. III Prioritization

61. 4. IV Define Positive Value

62. The term "Carver", according to the terminologies of Agile is best defined as a  The criticality, accessibility and vulnerability of the objective aspect and mission of a project are the right choice.

63. Problem Detection and Resolution aspect of agile project

64. Introspective: an ad hoc meeting by the Agile team to review on the team practices or teamwork during the sprint, often called for when something went wrong

65. Types of testing

65. 1. Unit testing

65. 2. Exploratory testing

65. 3. Usability testing

66. Spike solution (Exploratory work): Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate.

67. A risk-based spike is a timeboxed effort in which the team investigates, and tries to reduce or eliminate, an issue or threat to the project.

68. Team Development Stage  Suggested Leadership Style

68. 1. Forming                 Directive

68. 2. Storming                Coaching

68. 3. Norming                Supportive

68. 4. Performing            Participative/delegating

68. 5. Adaptive leadership, where leaders modify their style based on the stage of group development, tells us that teams in the “storming” phase need supportive leadership (Coaching), which involves high levels of direction and high levels of support.

69. This scenario describes a team that is entering the Storming stage of development. The most appropriate leadership style for that stage is Coaching, which involves giving the team a high level of both support and guidance.

70. Collaboration vs negotiations when there is a disagreement

71. agile teams only demonstrate work that is fully completed. If the work has not been completed, the team will usually include it as the first thing to be done when planning the next iteration.

72. Planning poker and wideband Delphi are methods for collaborative estimation that allow several team members to work together to come up with an estimate.

73. Kanban related

73. 1. Value stream map

73. 2. Task board

73. 3. Kanban board

73. 4. Cumulative flow diagram

74. The “caves and commons” office layout, in which developers or pairs have semi-private spaces adjacent to a shared meeting space, is effective because it limits interruption while still allowing for osmotic communication (where team members learn important project information from overheard conversations).

75. There is an upper limit on the number of people who can be on a Scrum team—it typically can support a maximum of nine people (but some teams make it work with up to twelve).

76. Ideal time: approach to estimating size of stories/requirements This means working together to figure out how much time it would take for a team member to work on each item in an “ideal” situation: he or she has everything needed to complete the work, there are no interruptions, and no other external factors or issues that could get in the way of completing the work. Unlike relative size techniques (like assigning story points to each item), ideal time is the team’s best estimate of the absolute time required.

77. Sprint Goal/Vision: When a Scrum team plans the next sprint, one thing that they do is craft a sprint goal. This is their objective for the sprint that they’ll meet by completing the work in the sprint backlog and delivering the increment. The sprint goal is how they stablish a shared, high-level vision of what they will accomplish for their stakeholders by delivering the increment.

78. Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators. Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.

78. 1. https://www.mountaingoatsoftware.com/agile/planning-poker

79. Ground rule/working agreements: Agile teams work to define their working agreements when they start working together. That way, all team members know what to expect when they’re working with the group.

80. Intraspective: "Intraspective" is simply another term for "retrospective." These meetings provide an opportunity for the members of the development team to inspect and improve their practices, processes, and teamwork. While this might include considering what we have learned from feedback and learning cycles, that isn't the goal of the meeting.

81. Tacit knowledge or implicit knowledge—as opposed to formal, codified or explicit knowledge—is knowledge that is difficult to express or extract, and thus more difficult to transfer to others by means of writing it down or verbalizing it. The unwritten information collectively known by the group. This can include personal wisdom, experience, insight, and intuition (How to restart a server, How to turn on the lights) . There are three core types of knowledge: explicit (documented information), implicit (applied information), and tacit (understood information).

82. The flow of useful information within a shared team space is referred to as “osmotic communication.”

83. cycle time = WIP / throughput. So if throughput goes up while cycle time (the ratio between WIP and throughput) remains the same, we can deduce that the team's WIP must have also increased.

84. James Shore’s assessment focused on XP practices provides a quiz and scoring model for team self-assessment

85. affinity estimating is used to compare the size of new and old estimates to ensure that the measuring unit (such as story points) hasn't drifted over the course of the project.

86. Which activities might your team use to generate insights during a retrospective?

86. 1.  A. Brainstorming; Five Whys; Prioritize with Dots

86. 2.  B. ESVP; Timeline; Appreciations

86. 3.  C. Check-In; Working Agreements; Like to Like

86. 4.  D. Mad, Sad, Glad; Locate Strengths; Team Radar

86. 5. Retrospective activities to generate insights might include brainstorming, Five Whys, and Prioritize with Dots. The other activities listed are used in other steps of a retrospective.

87. Alistair Cockburn made the analogy to Aikido

87. 1. Shu: In the Shu state, the Scrum Master is the master of the process, of the Scrum framework. She is good at going through motions: setting up and facilitating events, helping her team achieve a stable state, helping the team find its velocity, and guiding continuous improvement through the process of retrospective. In this state, the focus is more on how to achieve something without worrying too much about underlying theories of practice.

88. 1. Ha: When the Scrum Master and her team achieve the Ha state, they are doing more than executing steps to follow a prescribed way of working. According to Jeff Sutherland, the team can “get software done at the end of the Sprint and has a good Product owner with a ready backlog at the beginning of the Sprint, has data that clearly show at least a doubling of productivity, and has strong management support.”

89. 1. Ri: At this stage, a Scrum Master can step back and let the team, a well-functioning and productive organism, perform at their best. The Scrum Master is never in the spotlight and is never a puppeteer. The Scrum Master instinctively and seamlessly adapts to the environment and team needs as frequently as needed.

90. Lyssa Adkin's four guidelines for one-on-one coaching are "meet them a half-step ahead," "guarantee safety," "partner with managers," and "create positive regard."

91. Agile team members use quizzes and diagnostic tools to perform a self-assessment, which involves analyzing and improving the team’s practices and processes. This exercise might lead to developing goals and guidelines that would be revisited in the next self-assessment, but those elements aren't required to conduct the assessment itself.

92. In systems thinking, a project's "complexity" refers to its level of uncertainty. Agile works well in a moderately complex (uncertain) project environment. A project environment that is anarchic or chaotic has too much complexity to be manageable by agile or any other approach. A project in a stable, certain environment ("low complexity") can successfully use either an agile or a non-agile approach

93. Lead time

94. 
    

94. 1. Kanban lead time is the time between a request being made and a task being released. It’s the total time the client is waiting for a task to be delivered. Lead time is frequently used by Kanban teams to evaluate customer satisfaction. Lead time refers to how long it takes a deliverable to go through the entire process, from eliciting the requirements to deployment.

94. 2. Kanban cycle time is calculating the actual work-in-progress time. It tracks how long a task stays in the different process stages.

95. Process Cycle Efficiency, also known as “Flow Efficiency” or “Value Add Ratio,” is a measurement of the amount of value-add time in any process, relative to lead time (the time between the initiation and completion of a production process). The higher the ratio, the more efficient your process. This metric quantifies waste throughout a system of delivery.

95. 1. Process Cycle Efficiency = Value-Added Time / Lead Time

96. Story mapping consists of ordering user stories along two independent dimensions. The “map” arranges user activities along the horizontal axis in rough order of priority (or “the order in which you would describe activities to explain the behavior of the system”). Down the vertical axis, it represents increasing sophistication of the implementation. Given a story map so arranged, the first horizontal row represents a “walking skeleton“, a barebones but usable version of the product. Working through successive rows fleshes out the product with additional functionality.

97. Problem-solving process involves three steps: gather data, generate insights, and decide what to do.

98. James Shore’s assessment focused on XP practices provides a quiz and scoring model for team self-assessment.

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

99. 1. Individuals and interactions over processes and tools

99. 2. Working software over comprehensive documentation

99. 3. Customer collaboration over contract negotiation

99. 4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

100.             Principles Behind the Agile Manifesto. We follow these principles:

a.                   • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

b.                   • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

c.                    • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

d.                   • Business people and developers must work together daily throughout the project.

e.                   • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

f.                     • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

g.                    • Working software is the primary measure of progress.

h.                   • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

i.                     • Continuous attention to technical excellence and good design enhances agility.

j.                     • Simplicity—the art of maximizing the amount of work not done— is essential.

k.                    • The best architectures, requirements, and designs emerge from self-organizing teams.

l.                     • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

101.             Industrial work relies on defined processes. Knowledge work relies on empirical processes•

102.             Brainstorming Methods

a.                   Quiet writing

b.                   Round robin

c.                    Free for all

103.             Collaboration Games. Also known as innovation games

a.                   Remember the future

b.                   Prune the product tree

c.                    Speed boat

d.                   Buy a feature

e.                   Bang for the buck

104.             Active Listening: Hearing what someone is really trying to say

a.                   Level 1 internal listening

b.                   Level 2 focus listening

c.                    Level 3 global listening

105.             A defined process defines all steps in advance

106.             Requirements prototype

107.             Value stream mapping

a.                   Total cycle time

108.             Premortem session

109.             Types of prioritization

110.             Cycle time of iterations

111.             Defect cycle time

112.             Trend, Variance analysis for iteration times

113.             Agile discovery

114.             Earned Value Management

115.             Two to Two voting system

116.             Decision making

a.                   Simple voting

b.                   Thumbs up

c.                    Jim Highsmith Decision

117.             Fist of five: Voting technique. The number of fingers shown indicates degree of support

118.             Leas’s levels of conflict

119.             Cockburn’s success and failure modes

120.             Pull system

121.             Burn up vs burn down chart

122.             12 point method

123.             Tabaka Self-Assessment Model for assessing team performance

124.             Identify Themes is focused on recurring patterns of strengths

125.              Color code dots are about energy during an iteration and team radar is performance against previous process improvement goals.

126.             Requirements hierarchy typically includes epics, features, user stories, and tasks. Subtasks are not included.

127.             Typically user stories that are beyond 3 to 5 days of work are too large and should be broken down further.

128.             Good user stories use the INVEST mnemonic, which is Independent, Negotiable, Valuable, Estimable, Small, and Testable.

129.             Wideband Delphi is a group-based estimation technique for determining how much work is involved and how long it will take to complete. Individuals within a team anonymously provide estimation for each feature, and the initial estimates are plotted on a chart. The team then discusses the factors that influenced their estimates and proceed to a second round of estimation. This process is repeated until the estimates of individuals are close to each other and a consensus for the final estimate can be reached. Planning poker is one example of a Wideband Delphi technique (. It is also important to note that it is the individual input collected by a mechanism that avoids the group thinking. Then the individual inputs are used for a group decision.

130.             Level of conflict Level 

a.                   1: Problem to Solve. ...

b.                   Level 2: Disagreement. ...

c.                    Level 3: Contest. ...

d.                   Level 4: Crusade. ...

e.                   Level 5: World War

131.             If the team needs to show reservation and the wide spectrum of feelings use Highsmith's Decision Spectrum. Simple Voting and Fist-of-Five voting does not allow for discussion of reservations.

132.              Coaching is the core role of an agile leader. The other activities may take place, but are not as common as coaching. A coach does not necessarily perform training and evaluating. Mentoring is more of an occasional need.

133.             Feedback is not the primary purpose of a daily standup. Retrospectives, continuous integration, and pair programming are all inclusive of feedback.

134.             Kenneth needs to know the financial return on the whole project to distribute the return across features and come up with the risk-adjusted backlog.

135.             In systems thinking. Agile projects have complex technology and complex requirements, but not technology or requirements that are approaching chaos. The other choices are not accurate for the most successful agile projects. The most successful are in the middle of the complexity standards, neither high nor low.

136.              Embellishment, something that teams have added on but does not produce much value

137.             The most appropriate response is to report this behavior to PMI. Those with a PMI-ACP certification should adhere to PMI ethics standards. This involves reporting information to PMI as the first step for investigation, not investigating alone or discussing with a sponsor.

138.             An effective way to reach consensus on acceptance criteria is to use negotiation. A common way for teams to negotiate this is to have “give and take” where the current iteration’s definition of “done” includes some of the work, but agrees to include the rest of the work in a future iteration.