Mitigate is the right option. This is a mitigate strategy as by taking this step team is trying to lessen the probability of risk.
This is not ‘avoid’-since team is not trying to steer clear of the risk. If team has decided not to release the product as a risk response, that could have been categorized as avoid
This is not ‘contain’- because team is working on mitigation plan rather than having contingency plan , if team decided to keep some developers on standby for next 3 months to take care of any escape defect, that would have been the contain strategy
This not ‘evade’- since this implies that team does nothing about it and expecting to be lucky which not the case here is.

Both of them does not represent the same meaning, ideal time is the time required to do the work in ideal condition.

Technical debt is not an XP practice. Technical debt is total sum of less than perfect design and implementation decisions in the product, technical debt needs to be monitored and controlled.

Sit together-XP advocates an open space big enough for the whole team

Slack- XP recommends that in any plan it is better to include some minor tasks that can be dropped if you get behind. You can always add more stories later and deliver more than you promised.

Energized- Work only as many hours as you can be productive and only as many hours as you can sustain.

Help team work with the rest of the org. A project manager in an XP team ensures that the team works well with the rest of the organization. A PM is more focused in managing external stakeholders.

Technical debt is the total amount of less-than-perfect Design and implementation decisions in your project
Team should strive to have minimum technical debts, and team should reduce technical debt by adapting refactoring practice of XP.

Triangulating

It is Sprint retrospective as at the end of sprint cycle, all the team members are required to look back and gauge the previous sprints.

Team is the correct option since it’s the product development team that decides what could be achieved by the next sprint. PO gives the priority, team decides the capacity.

Principle, since leaders does not manage teams by allocating tasks to the teams. In high-performance teams, “the leaders managed the principles, and the principles managed the team.” Carl Larson and Frank LaFasto ,

Teams performance is based on how the well agile values and principles are followed.

Higher, Lower. Since, “Higher the technical debt means lower the intrinsic quality.” Intrinsic quality is an internal quality of the product, having good design and implementation improves the intrinsic quality and reduces the technical debts.

Acceptance test driven development.   ATDD is the technique based on the test driven approach where the team discusses the acceptance criteria with the Business so that a detailed set of tests are designed in advance and is accepted by the business and stakeholders. The ATDD cycle starts from story discussions and then team distill this, followed by development and demo of item as mentioned in acceptance before marking this as DONE.

Pull system. The statement talks about the definition of Pull system , In scrum we implement a pull system by creating sprint backlogs and preparing the task board using it, so the pull system implementation in scrum is done using sprint backlog , task board and daily stand-up.

Artifacts. This is the definition of artifacts, and in scrum we have 3 artefact which includes Product Backlog, Sprint Backlog and Increment of Product

Definition of Done, the team makes it into congruence with the Product Owner, and definition of done is used to keep the meaning of ‘done’ consistent and unambiguous to all.

Small is not a characteristic of the product backlog; it’s a characteristic of a good user story. Roman Pichler and Mike Cohn coined the acronym DEEP to summarize several important characteristics of good product backlogs: Detailed appropriately, Emergent, Estimated, and Prioritized. DEEP criteria are useful for determining if a product backlog has been structured in a good way.

Showing dependencies of one task on others is not a characteristic of an agile plan. Since in agile we focus on creating a pull system rather than push system and we start with a top level plan first.

Agile team follows Qualitative Risk analysis. Quantitative risk analysis usually involves calculation of risk impact in monetary terms like Expected Monitory Value

Burnup chart. A graph that shows the progress of work toward a goal line associated with a value on the vertical axis. As work is completed over time (the horizontal axis), the progress line moves up (burns up) to be nearer to the goal line.

Of the listed options, option D is the correct one. Whenever a project needs many people, the guideline is to form multiple scrum teams sprinting individually that do daily scrum followed by a daily or weekly Scrum of Scrums at which one member from each scrum team meet to synchronize their work for any dependencies.

Burndown Chart

INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)

Sprint : Short  Sprint Cycles. Having shorter sprint would enable teams to deliver early and cycle of such deliveries would make it continuous delivery to the customer. Sprint planning is there irrespective of the sprint period. 2 weeks is early against 8 weeks

Daily scrum meeting is the place where team collaborate and synchronize their work.

It never gets frozen. One of the attributes of a Product Backlog is that it is EMERGENT (from the acronym DEEP). It keeps evolving as time progresses.

PO is solely responsible for change management at any stage. The team should provide inputs to the PO like impact analysis on the basis of which the PO needs to make a decision on the priority of the change.

C, The value stream map is a Lean tool that practitioners use to analyse the value stream.

A, In lean agile the testing is done to improve the process and quality. The testing activity should discover the causes of errors and eliminate them. Root-cause analysis is part of the testing’s portfolio of work. In lean we work with a principle-build quality so that the process should ensure we develop quality products, testing alone cannot ensure that we deliver good quality products to the user.

A, The term “product champion” to describe someone who makes the decisions about which products to create or enhance. Product companies may use the term “program manager” or “product manager.” IT organizations may call this role the “sponsor.”
Practical experience from the field suggests that the product champion role comprises a team of product managers, business stakeholders, business analysts, and client-facing personnel who are committed to providing the required service levels of feedback and validation so that the development organization can move quickly.

B, A diagram used by Kanban is the cumulative flow diagram (CFD), which describes the overall flow through the Kanban system; it provides a measurement for every significant step in the workflow.

A, Business value delivered chart. The entire enterprise (business, management, and development teams) needs the line of sight to velocity (points/time) dashboard-type view of work management which in other terms is a business value delivered chart.

C, Always Remember principle of last responsible moment; in agile we do things at last responsible moment. The stories should have details and acceptance criteria attached before they get developed not before they get estimated.

C, Scrum has 3 artifacts which include Product Backlog, Sprint Backlog and Increment of Product, so increment is the right answer.

B, This question is about identification of Extreme Character, we should identify them since it leads to identification of some of the important user stories which we may miss if we do not identify them

D, Now if you are using some electronic software for writing user stories you keep them forever, this can also work as a knowledge transferable tool. However, generally, in agile we prefer working software against documentation and since we have working software which is accepted by the PO / Customer we should not care about what was written on the card. So once story is done we should look to working software for details not to the user story card.

D, A primary goal of Lean is to optimize the whole with speed and sustainability. This can be summarized as “fast-flexible-flow,” which is the fundamental phrase used in Womack & Jones

Yes we calculate cost and time budget at release level based on estimated size and velocity. Product Owner is the one who owns the release plan.

A, since team is keeping some contingency reserve to take care of unexpected tasks it falls in Contain. In contain, we plan contingency reserve to take care of risk.

D, In XP all testing are automated, the only manual testing, an XP team may perform is the Exploratory testing.

Whole team is responsible for managing risk. This must have made you wonder then how come Project manager role. It is important here to note that here we are not talking about agile and XP does recognize the role of Project Manager. The overall risk management responsibility can be assigned to Project Manager.

Intrinsic quality is required to deliver continuous value to the customer, it’s an internal quality of product which is not visible to the end user but needed to make product adaptable for future need.

In scrum Product Owner is authorized and responsible to identify what all need to be built, so team member should notify this to PO and PO should take call on this.

B, Conflicts are unavoidable in the project environment.Conflict resolution must not focus on personalities and past events. The people who are in conflict are first responsible for resolving it.

The best architectures, requirements, and designs emerge from self-organization teams.

Option D refers to the “servant leader”, which is an expected leadership style from Scrum master

The product backlog helps both the team and the product owner understand the priorities required to deliver business value.

All of the listed work falls under the responsibility of the tester except D-writing acceptance criteria for user stories falls under customer roles.

A, This falls under Project manager’s role, he need to be creative in packaging the project’s information for presentation to executives and peers.
Planning in XP is an activity, not a phase. Project managers are responsible for keeping plans synchronized with reality.

D, This is a definition of refactoring

C, by doing test first development we control Scope creep. By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding.

B, These are the steps of synchronous continuous integration

C, Team is responsible for creating and enforcing the ground rules, scrum master should ensure that team does it.

The first responsibility of doing this work goes to the team, since the team is self managed and manager role should be played by team itself. The team does this in retrospective meeting.

D, Acceptance test criteria should be written at the last responsible moment, this is not the right time for writing them. While velocity, product backlog and release length are essential input for release planning.

B, since it’s good to plan at least 5 adaption points in a release, we analyze the performance at the end of iteration so we should have some minimum number of iterations which helps us in adapting based on the discovery we make at iteration end.

C, 3 to 12 months are the best out of provided options especially for new development project; release planning is also referred as long term planning and quarterly planning in many cases.

C, It is always recommended to refactor the code if it is more than complex, but doing this may require a good amount of time so it’s better to get this work first added in product backlog and then accomplish it. If you can do it without impacting the current sprint goal you can take the approach suggested in option A.

The option C is a technical product backlog item where we need to plan a good amount of work to migrate to a new database version. Option A is pointing towards a risk and not the product backlog item and remaining option B and D are potentially sprint backlog item.

C, Rest of the options are characteristic of a defined process. We apply empirical process control where underlying mechanisms are not well defined.

D, Out of the given options technical debt has very less to do with timeboxing. Establishes a WIP Limit, Forces Prioritization and Demonstrates Progress are advantages of time boxing

B, Iteration review is a step where stakeholders look at the progress by looking at working software.

Following are the four values of Agile Manifesto

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile methods offer several benefits including faster time to market, more business value and improved stakeholder satisfaction. For planning, agile does not recommend heavy upfront planning. Instead, it recommends an initial high-level plan which is re-visited on several occasions throughout the project.

The principles behind Agile Manifesto states that “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Answer ‘a’ is incorrect since embracing change will not curb uncontrolled changes. Answer ‘b’ and ‘d’ are again not reasons why Agile insists on embracing changing requirements.

Agile Manifesto values include the following:
Individuals and interaction over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The agile principles state without ambiguity that business people and developers must work together daily throughout the project. Answer ‘b’ says ‘regularly’ which may not be ‘daily’.
Agile developers adopt practices such as on-site customer and active stakeholder participation which enable stakeholders to be actively involved with software development.

Fixed scope is not in line with the agile principles. One of the core principle of agile is to welcome changing requirements even late in development cycle for customer’s competitive advantage. The rest of the options are in line with Agile principles.

The #5 principle of Agile Manifesto says: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Option A is wrong because of the use of well-managed; it should state self-organizing. Option B is incorrect since complete team is responsible for product quality, Option D is wrong because agile team focuses on delivering value not full scope.

Agile Manifesto values customer collaboration more than contract negotiation.
Agile Manifesto values include the following:
Individuals and interaction over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile methods work well where there is uncertainty in the environment and the results are driven by people rather than process. Heavy-weight methods canvass formality and discipline in order to work the intricacies of the project. In opposition, agile methods favor creativity, improvisation, and nimbleness to negotiate with project hazards. In addition, agile methods welcome change and alternately adapt to the new conditions. Heavy methods are more pessimistic at handling change and try to get all things worked out in the first instance.

This principle talks about value of empowering the team that far outstrips the benefits derived from processes and tools. We must constantly be aware that it is our people who actually do all the value added work, and respect for people is a comforting and fundamental principle of Lean and Agile.

Agile Manifesto speaks about “Working software over comprehensive documentation”.
Agile Manifesto values include the following:
Individuals and interaction over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Delivering comprehensive documentation will not deliver business value without working software. Historically, in software development, it’s been a priority to exhaustively document everything: requirements, design, test suites, correct usage, and so on. But that’s expensive; so expensive that often the software itself suffers from the effort devoted to documentation. So we don’t write documentation just because; we write documentation rather we do it when it has value and is required.

Responding to change over following a plan – Agile Manifesto.
The principle doesn’t devalue planning—just sticking to the plan. Planning is valuable in itself, and because the plan helps us recognize when things have changed; it helps us understand the implications of change, how we need to adjust, and the likely cost. The important thing is that, as we make plans, we understand that the plan may have to change. Planning is an ongoing time-boxed activity.

Collaboration, responding to change, working software and individuals and interactions are on the higher side of the customer value chain. Processes and tools, comprehensive documentation, contract negotiation and following a plan are on the lower side of the customer value chain.

Answers ‘c’ and ‘d’ are part of agile principles but they are not concerned with directly delivering value to customer. Both ‘a’ and ‘b’ certainly address customer satisfaction but, the highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Agile projects are built around motivated individuals and the team organize themselves without the command and control structure. The rest of the options are not correct since agile teams are highly disciplined, there is more planning in agile projects than the traditional projects and also the teams are motivated and empowered which enables them to deliver at sustainable pace.

Customer collaboration over contract negotiation – Agile Manifesto
Agile Manifesto values include the following:
Individuals and interaction over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Though Agile Manifesto states that it values responding to change over following a plan, it should not be constructed as there is no need for planning on agile projects. In fact, Agile projects do overall more planning than the traditional ones.

The best architectures, requirements and designs emerge from self-organizing teams. The emergent properties for a complex project are best generated from self-organizing teams in which the interactions are high and processes are low.

In agile processes, there is a strong taste of minimalism. Include only what everybody needs rather than what anybody needs.
There is a point in time when any additional effort put into work product will increase its cost without increasing its value. It’s easy to continue developing a product beyond some point. A Standish Group survey in 2009 stated that over 70% of functionality is never or rarely used. Not doing that work is a great opportunity to do more valuable work.

Lean manufacturing represents a fundamental paradigm shift from traditional batch and queue mass production to production systems based on product aligned single-piece flow, pull production.

“Lean” is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.
Lean manufacturing is a management philosophy derived mostly from the Toyota Production System (TPS).
The original main 7 types of waste from TPS are Transportation, Inventory, Motion, Waiting, Over-production, Over-processing, Defects.

Of the options presented the best tool to show work in progress is a task board. The user story backlog shows what work is still remaining to be done on the project. The product roadmap shows when work is planned to be completed. Work breakdown structures are not commonly used on agile projects.

Creating more than what is needed is over production type of waste

The correct answer is “It is a sign of the work being done and should be limited to boost performance.” A Kanban board shows work in progress (WIP), which represents work started but not completed. Therefore, the WIP should be limited and carefully managed to maximize performance. More WIP does not equal more output; in fact, it is quite often the opposite. Also, WIP is any work that is in progress, regardless of what stage the work is at, so the answer options that limit it to work waiting for quality assurance or user acceptance are wrong.

The Waste type is “Extra Motion”. If excessive or unnecessary emails and document get forwarded multiple times sometimes with large attachments due to multiple distribution groups, it constitutes waste of type motion. Do not confuse with “Extra Transportation” which refers to unnecessary motion or movement of raw materials or goods such, as work-in-process (WIP) being transported from one operation to another.

Five (5) Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem

The word kaizen means “continuous improvement.” It is a system of continuous improvement in quality, technology, processes, company culture, productivity, safety, and leadership. It comes from the Japanese words (“kai”) which means “change” or “to correct” and (“zen”) which means “good.”

The only option here that is a step in value stream analysis is “Create a value stream map of the current process, identifying steps, queues, delays, and information flows.” None of the other options are valid steps in value stream mapping.

Taxes are not one of the seven wastes. Taxes are regulatory obligation and could not be considered as waste.
The 7 types of wastes are Transportation, Inventory, Motion, Waiting, Over-production, Over-processing, Defects.

PDCA (plan–do–check–act or plan–do–check–adjust) is an iterative four-step management method used in business for the control and continuous improvement of processes and products.
PDCA was made popular by Dr W. Edwards Deming, who is considered by many to be the father of modern quality control.

Jidoka is a Japanese term used for autonomation means “intelligent automation” or “humanized automation.” In practice, it means that an automated process is sufficiently “aware” of itself so that it will detect when the desired quality is produced, detect process malfunctions, detect product defects, stop itself and alert the operator. A future goal of autonomation is self-correction.