Features
Features:

Product Tour >

Edraw AI >

Paid Plans:

Individuals >

Business >

Eduaction >
Resources
Blog

History

How-tos & Tips

Discovery

Biography

Business Analysis

Examples

AI concept Map

Free AI Mind Map Generator

Onenote Mind Map

Bcg Matrix Examples

Nike Marketing Strategy

Unilever SWOT Analysis

Make Mind Maps in Google Docs

Guide

FAQs

What's New

Resource Center
Templates
All Templates

Brain Storming Templates

Strategy and Planning Templates

Project Management Templates

Product Management Templates

Human Resources Templates

Agile Workflow Templates

Marketing Templates

Education Templates

Fun and Games Templates

User Gallery
Download
Pricing
Enterprise

MindMap Gallery Summary of all agile test points for PMP project management exam

Summary of all agile test points for PMP project management exam

Summary of all agile test points for the PMP project management exam. 1. Our most important goal is to satisfy customers by delivering valuable software early and continuously. 2. Face changes in requirements with joy, even in the late stages of development; for customers For competitive advantage, agile processes control change.

Edited at 2022-11-08 10:58:19

PlotWizard

Recent works View more works>>

Summary of all agile test points for PMP project management exam

PlotWizard

Recent works View more works>>

Recommended to you
Outline

agile

Agile Overview

Agile Manifesto

Individuals and interactions trump processes and tools

Working software trumps complete documentation

Customer collaboration trumps contract negotiation

Dealing with change is better than following a plan

Twelve principles of agile

1. Our most important goal is to satisfy our customers through early and continuous delivery of valuable software

early continuous value driven delivery Customer satisfaction

2. Face demand changes with joy, even in the late stages of development; for the competitive advantage of customers, agile processes control changes

embrace change Improve customers' competitive advantage

3. Deliver working software frequently, a few weeks or a month or two apart, tending to take shorter cycles

Frequent delivery short cycle

4. Business people and developers must cooperate with each other, every day of the project is no exception

Business and development collaborate with each other Every day

5. Stimulate the fighting spirit of individuals and build projects with them as the core; provide the necessary environment and support, supplemented by trust, to achieve the goal

provide environment support team Add trust to the team

6. Regardless of whether inside or outside the team, the best and most efficient way to convey information is face-to-face conversation.

Face-to-face communication works best You can also use virtual communication [fish tank window, remote pairing]

7. Working software is the primary measure of progress

Metrics based on working software

8. The agile process advocates sustainable development; responsible persons, developers and users must be able to work together to maintain a stable and continuous pace.

sustainable development Steady pace

9. Agile capabilities are enhanced by relentless pursuit of technical excellence and good design

Refactor

10. Based on simplicity, it is the art of trying to reduce unnecessary workload

concise Focus on goals

11. The best architectures, requirements, and designs come from self-organizing teams

self-organizing team

12. The team regularly reflects on how to improve performance and adjusts its behavior accordingly

Review regularly keep improving

life cycle

Predictive life cycle

Clear scope, solid experience foundation, plan-driven, also called waterfall type

Iterative life cycle

Develop products through a series of iterative cycles, from blur to clarity

incremental life cycle

Gradually increase product functions within a predetermined time, from part to whole

Agile (adaptive) life cycle

Respond to changes quickly, iterate quickly in smaller increments, and focus on value in each increment

hybrid life cycle

Enabling the transition from prediction to agile

Can be tried in projects with low risk and low to medium levels of uncertainty

Scrum

overall framework

Product vision, product roadmap

release plan

iteration planning

three characters

Product Owner PO

Maximize product value

Be the sole person responsible for managing the Product Backlog

Clearly describe the product backlog ProductBacklog (PB) Prioritize list items Ensure PB is transparent and clear Ensure the development team has a deep enough understanding of PB The team can participate in the above work, but the responsible person is still the PO

Changing the priority of PB needs to go through the product owner

be careful

If the requirements are not clear, you can clarify them with the PO and relevant parties.

PO can be a business expert, but it is generally not held concurrently by the Scrum Master.

Scrum Master

servant leadership

Serving the Product Owner

Make sure the team understands the goals Find tips for managing your PB effectively Make sure the product owner understands how to schedule PB Help understand and practice agility

Serve the team

Serve as a coach providing guidance in self-organizing and cross-functional areas Remove barriers to development team work Serve as a coach to guide development teams in organizational environments where Scrum has not yet been fully adopted and understood.

Serve the organization

Coaching your organization to adopt Scrum Help stakeholders understand and implement Scrum Inspire changes that increase team productivity Enhance the effectiveness of Scrum applications in your organization

development team

Created and authorized by the organization

self-organizing

Cross-functional teams that have all the skills to create a product

No titles are recognized, no matter what work they undertake, they are all called developers.

Does not recognize any sub-teams, such as testing, architecture, etc.

Usually 3~9 people

Generally excludes PO and Scrum Master unless they are also involved in performing work in the Sprint Backlog

be careful

Make your own decisions about the assignment of tasks

Decide for yourself how to complete tasks

Responsible for all estimating work

Emphasis on teamwork

three artifacts

Product Backlog PB

Known needs for covered products

Contains all features, functions, requirements, enhancements and fixes

Responsible by the Product Owner PO

Sort by priority, the higher the priority, the more detailed it is

Monitor progress towards goals

Sprint Backlog

Selected Product Backlog items for the current Sprint

Include at least one high-priority improvement identified in the previous retrospective meeting

product increment

A summary of all backlog items completed in a Sprint and the sum of the value of the increments generated by all previous Sprints

Must meet definitional criteria of "done"

Increments must be available regardless of whether the product owner releases them

five events

Sprint

Fixed length (usually 2~4 weeks)

Including: Sprint planning meeting, daily Scrum stand-up meeting, development work, Sprint review meeting, Sprint retrospective meeting

Things to note during Sprint

Cannot make changes that are detrimental to the Sprint Goal

Theoretically no changes during the Sprint

No loss of quality

What needs to be done can be clarified between the product owner and the team

Only the Product Owner has the authority to cancel a Sprint, which can cause serious damage to the team, so canceling a Sprint is very rare.

Sprit planning meeting

Plan the work to be done in the Sprint, and the entire Scrum team completes it together

There are timebox limitations: for a one-month Sprint, the maximum is 8 hours; for a 2-week Sprint, the general limit is 4 hours

The Scrum Master ensures that the meeting takes place and that each participant understands the purpose of the meeting and adheres to the timebox rules

The meeting answers two questions

What does the increment to be delivered in a Sprint consist of?

How to do the work required to deliver the increment

Determine the Sprint Goal during the planning meeting

Product Owner helps explain selected Product Backlog items

It is up to the development team to choose the number of product backlog items

The development team decides how to complete selected product backlog items

The development team can invite other people to the meeting to gain relevant knowledge or advice

Daily Scrum meeting (stand-up meeting)

Use the stand-up meeting to review the progress of completing the Sprint backlog

Timebox is limited to 15-minute events, held daily

The role of meetings

Improve communication

Reduce other meetings

Discover obstacles that need to be removed

Improve development team awareness

Conference content

What did I do yesterday to help the Development Team reach their Sprint Goal?

What am I going to do today to help the development team reach their Sprint goal?

Are there any obstacles that are preventing me or the Development Team from meeting the Sprint Goal?

be careful

Issues will not be discussed at the meeting and can be discussed in more detail after the meeting

The Scrum Master ensures that the development team's daily stand-up meeting is held as scheduled, but the development team is responsible for holding the meeting themselves

Daily Scrum Scrum is an internal meeting of the development team

If people from outside the development team attend the meeting, the Scrum Master must ensure that they do not disrupt the meeting.

Sprint review meeting

Held at the end of Sprint to review the delivered product increment and adjust PB as needed

There is a time box limit, for a one-month Sprint, the maximum is 4 hours; for a 2-week Sprint. Usually 2 hours

The entire Scrum team and relevant parties participate

Review content

PO explains what has been completed and what has not been completed

Team demonstrates work completed

All participants discussed the next steps

Review the most valuable changes to make next

The outcome of the review meeting is a revised Product Backlog that clarifies the Product Backlog items that are likely to move into the next Sprint

Sprint retrospective meeting

After the review meeting and before the next Sprint

An opportunity for the team to review themselves and create an improvement plan for the next Sprint

There is a time box limit: for a one-month Sprint, the maximum is 3 hours; for a 2-week Sprint, it is usually 1 to 2 hours.

The Scrum Team should identify improvements that need to be implemented in the following Sprint

five values

courage

Have the courage to make promises, fulfill them, and accept the respect of others

promise

Willingness to commit to goals

focus

Put your mind and heart into the work you committed to

open

Scrum opens everything in the project to everyone

respect

Everyone has his or her own unique background and experience

Details in PMBOK

Integrated management

The team decides for itself how the plan and its components are integrated (self-organizing)

The project manager is responsible for creating a collaborative decision-making atmosphere

If the team is T-shaped, it will help to cooperate and solve the island of knowledge.

Project Charter

Why do you want to do this project? Who will benefit and how What conditions mean the project is completed? How will we cooperate?

scope management

Start by defining a high-level vision for the entire project

Product vision, product roadmap

Develop deliverables in multiple iterations

Define the detailed scope at the beginning of each iteration

Sprint planning meeting Sprint Backlog

Continuous involvement of relevant parties

Build and review prototypes with purpose

Increment

Scope and span of control are confirmed every iteration

sprint meeting Focus on the Sprint goal and do not make changes that are harmful to the Sprint goal

Progress management

Schedule with unfinished items

Scrum

on-demand schedule

Kanban [WIP limit, eliminate bottlenecks]

Agile release planning

Product vision, product roadmap

product version

release plan

How many iterations are required for each product release

iteration planning

Detailed user stories in Sprint

control progress

burn down chart Ignition chart

cost management

Lightweight approach to generating high-level predictions

Detailed estimates are suitable for just-in-time planning

Quality Control

Definition of Done DOD

Test-driven development, behavior-driven development, acceptance test-driven development

continuous integration

spy

Sprint retrospective meeting

Code collectively owned

Full responsibility

Resource management

Centralized office

T-shaped talents

collaborative team

Self-organizing task allocation

cross training

Team charter

team values

working agreement

DOR, DOD, timebox, WIP

basic rules

team norms

communication management

Transparent and efficient

information diffuser

Kanban board, burndown chart, ignition chart, cumulative flow chart, obstacle board

face to face

virtual communication

fish tank window remote pairing

Communicate among multiple agile teams

Scrum of Scrums (SoS meeting) chasing the sun

Risk Management

Review increments frequently to speed up knowledge sharing

Consider risks during iteration planning and identify, analyze and manage risks during iterations

Reprioritize based on improved understanding of risk exposures

Procurement management

Customer collaboration trumps contract negotiation

flexible agreement

multi-layer structure

Active Agreement and Supplementary Documents

Focus on user stories rather than overall project budget

dynamic range scheme

Cancel plan early

Fund the team, not the scope

Stakeholder management

Participate frequently

Efficient and transparent communication

Common stakeholder management