Edward Chung ACP Notes

PMP Exam, PMI-ACP, ITIL Certification Best Resources
Edward Chung Professional Certification Process and Notes

http://edward-designer.com/web
PMI-ACP Study Notes: Agile Fundamentals

Author : Edward Chung
Categories : PMI-ACP Exam
Tagged as : PMI-ACP Exam
[PMI-ACP study notes] Unlike the traditional waterfall project management philosophy,
Agile project management philosophy is geared to providing flexibility in response to the ever
changing environment and requirements. Industries like software development and information
technology are among the first to embrace Agile. This article outlines what makes Agile distinct
from traditional project management approaches and how to implement Agile principles in
projects. Knowing these would prepare you well for the PMI-ACP journey.
Ten Agile Fundamental Principles

Below are ten fundamental principles common to all Agile frameworks or methods. These are
the essences which make Agile different from waterfall project management.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Users Involvement
Team Empowerment
Fixed Time Box
Requirements At a High Level
Incremental Project Releases
Frequent Delivery
Finish Tasks One by One
Pareto Principle
Testing Early and Frequent
Teamwork
1. Users Involvement
1/7

In Agile projects, users are actively involved in the project throughout itself development
cycle. Inputs and feedback from the users are sought frequently to better understand the
requirements of the users as the project evolves and circumstances change. This is among the
most important principles of Agile.
The following are the advantages of users involvement:
Reduces the reliance of detailed requirements documentation at the initiating stage of
the project and thus eliminating the hassles of having to update the requirements
documentation in details when circumstances change
Allows the flexibility in adding / changing requirements fast and easily
Better understanding of users requirements as the project grows and evolves with
continual user input
Detailed project status reports are not required as the team and users work collaboratively, the
development progress is transparent to all parties. Users will be able to understand how the
end product will look like and whether all their needs are fulfilled as the project
progresses
Users can help the Agile team to understand priorities of tasks and requirements
Users become part of the project team and they are more likely to embrace the project
outcome
The Agile team and users work towards the same goal and share the responsibilities to
make the project a success
Make this happen
Make sure users are involved before the project starts
[if possible] Pick a representative from the users that is a good communicator and
flexible
Co-location of project team and users for closer interaction or make use of collaboration
tools / video conferencing
If there is not a user representative (e.g. the users are your future customers), pick a
member from your team to pretend to be the user as a whole
2. Team Empowerment
Three characteristics of empowered teams are:
Self-sufficient when forming the team, include all the team members necessary to
perform all the required tasks and make decisions in a timely manner without any need
to consult people outside. The users or the user representatives are integral part of the
team.
Collaborative every member of the team works collaboratively to achieve the project
goal as they are all entrusted with the authority to make decisions on the project. The
success or failure of the project lies in whether everyone has contributed their best.
Responsible since the team is entrusted with taking care of the project, the team as a
2/7

whole feel responsible for the scope of the project as well as the ultimate success of the
final product, not individuals (e.g. functional managers or the CEO) outside of the team.
Every member will perform their best to achieve overall success.
Make this happen
Involve everyone in decision making right from the beginning
Facilitate discussions among all team members to ensure everyone is always heard
Determine whether team decision or individual decision is needed case by case
Deal with team member conflicts or office politics proactively
Form a trusting relationship with all team members by not micro-managing their tasks
3. Fixed Time Box

Unlike traditional project management processes in which the project managers would try to
collect all the requirements from the very beginning and formulate a all-encompassing project
schedule based on the available resources and the interdependencies of the project tasks,
Agile does not make the assumption that requirements are clearly know at the start of
the project. Agile embraces changes in requirements as a fact in the project life and believes
that having a working software for the end users / customers to play with would help them to
better understand their needs.
Therefore, Agile project teams work within a fixed time box. Tasks are assigned priorities with
an estimated number of man-days. At the beginning of each time box, the team choose from
among the list of top priority tasks a number of tasks to be finished by the end of the time box
and work accordingly to give a working product at the end.
In normal projects, once an element of the Triple Constraints (i.e. time, cost and scope, aka
iron triangle) is changed, the other two elements must also be changed in order to maintain
the quality of the outcome. In Agile projects, only the scope from the triple constraints
would be adjusted while the time and cost would be kept constant.
Make this happen
Embrace changes (new requests, changed requirements, changed priority, etc.) and
incorporate them with a change control process
Assess new requests / requirements based on their priority in relation to the list of
collected requirements and adjust the scope for each time box
Fix the launch date of the deliverables so as to keep the team focusing on achieving the
goal
4. Requirements At a High Level

Requirements for Agile projects are collected according to the following two ways:
3/7

At a high level
Requirements are collected at a high level, just enough to give an idea of the required
product for budget estimation purposes.
Requirements are documented in the form of User Stories (showing how the users
interact with the product) rather than detailed specifications.
On a just-in-time basis
Since requirements may change along the progress of the project, requirements are
gathered only when necessary for carrying out the tasks right away.
Not to collect requirements for tasks several weeks away or more
Requirements are usually captured using visual methods (e.g. diagrams and storyboards) for
better understanding across the team. Storyboards shows how the users interact with the
product with hand sketches, wireframes or annotated screenshots.
Make this happen
Expect and prepare for changes in requirements.
Only collect barely enough details for the requirements (can be in the form of
documentation or storyboards) to estimate budget and carry out the work.
Hold workshops to gather the whole team together to understand the requirements as a
team effort.
Record requirements in the form of deliverables (e.g. design the website is NOT a
deliverable; interface design for the website is) and put each deliverable on a separate
card so that the priorities can be easily changed when more requirements are added
along the road.
5. Incremental Project Releases

Incremental releases means building on a previous release of the product / outcome. With
incremental releases, not all the requirements of the users are to be met in a single release,
only the top priority requirements as determined by the team and users. But with releases upon
releases, all the requirements will be met ultimately.
The project runs through many iterations (cycles or sprint) of
1.
2.
3.
4.
getting requirements
development works
testing
releasing the product to users / market
The benefit of this approach is flexibility and ability to respond to actual needs instantly.
Feedback can be sourced from actual users / market which can help adjust the direction of the
project for new features / changes.
4/7

Also, the works and contributions of the project team can be appreciated by people outside the
team as the many releases act like a progress report which in terms can boost the morale of
the team. The organization can also benefits from the new features introduced instantly. Should
there be any early termination of the project, there is aways something useful left.
Make this happen
Establish the core functions (top priority requirements) to be included of the first and
subsequent releases through discussion between the team collectively
Make use of the MoSCoW analysis (Must have, Should have, Could have, Wont have)
Try to keep the number of core functions low (keep it simple rule) to enable delivery of
next incremental release in a short timeframe (usually a week or two)
Focus only on achieving the identified core functions in each iteration and finish all of
them before the beginning the next iteration
6. Frequent Delivery
Make plans to enable the time between each incremental release to be short enough so that
you can:
realize value through early value delivery to reduce risks and attain stakeholder
satisfaction (e.g. to gain organizational support)
keep the momentum going by always focusing on the next shippable product
get timely feedback from users / customers which will be gathered to adjust the project
direction
let users know the progress by a workable product release
create competitive advantage as new features can be introduced real quick
Frequent delivery is especially suited for web-hosted services as there is little overhead for reinstallation, upgrade or manage. The delivery schedule would range from a week to around 30
days for most Agile projects.
Make this happen
Get feedback from users / customers (or through analytics) for timely input to help reprioritizing the features to be included in the next release
Plan a fixed release cycle so that the team has a common goal to work towards the
deadline
Let the whole company know the release plan so that they can work together to make
the project a success (e.g. Marketing for press releases, Support for training materials)
7. Finish Tasks One by One

For the Agile tasks:
5/7

Plan the reasonable amount of tasks for each iteration so that all tasks can be finished
in each iteration.
The tasks should meet the requirements of the Definition of Done which is established
by the team.
This enables frequent delivery of complete (ready for customer use) features.
Completed tasks can act as a sign of progress check which keeps the team focused.
Make this happen
Involve the users for testing
Ask for sign-off of completed features from the customers
Establish a standard procedure (e.g. develop test approve) for each iteration so that
no steps are left out
8. Pareto Principle
The Pareto Principle is also known as the 80/20 rule. It is a statistical principle that holds
true for many things have a similar 80/20 distribution.
In Agile development projects, the Pareto Principle applies to the fact that 80% of all
development effort should be spent on the top 20% of the features that the customer
actually ends up needing.
Need to identify the top 20% of features that customers actually need and use most
frequently.
Make this happen
Educate end users and project stakeholders on the Pareto Principle.
Prioritize the development efforts based on the Pareto Principle and try to identify the
most beneficial and useful features.
Work with the whole team for more accurate choice of features.
Check the project scope with customers and stakeholders regularly to identify any
changes in requirements.
9. Testing Early and Frequent

As each product release in an Agile project needs to be complete, each iteration needs
to include a robust testing process to ensure the finished tasks are complete.
The testing process is integral to the development cycle, there is no a distinct testing
phase.
Everyone in the Agile team is responsible for the testing of the product.
Tests should be run time and again to ensure new feature would not break the
functionality of existing features.
The Agile tester should refer to the Definition of Done to guide the requirements of
testing.
6/7

Make this happen

Include automated tests for more robust and efficient testing.
Include testing as a normal development routine.

Involve the whole team to perform the testing.
Integration tests are very important.
10. Teamwork
Change is normal in Agile development, documentation is usually kept at a minimal.
All the Agile team member should work together in a team so that any changes can be
communicated with everyone.
Make this happen
Collocation is one of the best tactic to ensure great teamwork.
Use of a feature board / task board as a focus point / information radiator for the team.
Conclusion: Understand Agile for the PMI-ACP Exam

These ten fundamentals of Agile project management philosophy form the basis of all Agile
frameworks and methods. Though the PMI-ACP certification exam would test you on different
Agile implementations, like Scrum, XP, Kanban, etc., the above ten fundamentals are still valid
no matter which implementation is selected.
PMI-ACP Exam Study Notes for PMP
? PMI-ACP Study Notes: Agile Manifesto ?
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

PMI-ACP Study Notes: Agile Manifesto
PMI-ACP Study Notes - Declaration of Interdependency
PMI-ACP Study Notes: What is Agile?
PMI-ACP Exam Study Notes Project Justification
PMI-ACP Study Notes - The Agile Team
PMI-ACP Study Notes: Agile Methodologies for PMI-ACP Exam
PMI-ACP Study Notes - Agile Planning
PMI-ACP Study Notes - Agile Project Execution
PMI-ACP Study Notes - Agile Coaching
7/7
Powered by TCPDF (www.tcpdf.org)


[PMI-ACP study notes] Unlike the traditional waterfall project management philosophy,
Agile project management philosophy is geared to providing flexibility in response to the ever
changing environment and requirements. Industries like software development and information
technology are among the first to embrace Agile. This article outlines what makes Agile distinct
from traditional project management approaches and how to implement Agile principles in
projects. Knowing these would prepare you well for the PMI-ACP journey.
Ten Agile Fundamental Principles

Below are ten fundamental principles common to all Agile frameworks or methods. These are
the essences which make Agile different from waterfall project management.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Users Involvement
Team Empowerment
Fixed Time Box
Requirements At a High Level
Incremental Project Releases
Frequent Delivery
Finish Tasks One by One
Pareto Principle
Testing Early and Frequent
Teamwork
1. Users Involvement
1/7

In Agile projects, users are actively involved in the project throughout itself development
cycle. Inputs and feedback from the users are sought frequently to better understand the
requirements of the users as the project evolves and circumstances change. This is among the
most important principles of Agile.
The following are the advantages of users involvement:
Reduces the reliance of detailed requirements documentation at the initiating stage of
the project and thus eliminating the hassles of having to update the requirements
documentation in details when circumstances change
Allows the flexibility in adding / changing requirements fast and easily
Better understanding of users requirements as the project grows and evolves with
continual user input
Detailed project status reports are not required as the team and users work collaboratively, the
development progress is transparent to all parties. Users will be able to understand how the
end product will look like and whether all their needs are fulfilled as the project
progresses
Users can help the Agile team to understand priorities of tasks and requirements
Users become part of the project team and they are more likely to embrace the project
outcome
The Agile team and users work towards the same goal and share the responsibilities to
make the project a success
Make this happen
Make sure users are involved before the project starts
[if possible] Pick a representative from the users that is a good communicator and
flexible
Co-location of project team and users for closer interaction or make use of collaboration
tools / video conferencing
If there is not a user representative (e.g. the users are your future customers), pick a
member from your team to pretend to be the user as a whole
2. Team Empowerment
Three characteristics of empowered teams are:
Self-sufficient when forming the team, include all the team members necessary to
perform all the required tasks and make decisions in a timely manner without any need
to consult people outside. The users or the user representatives are integral part of the
team.
Collaborative every member of the team works collaboratively to achieve the project
goal as they are all entrusted with the authority to make decisions on the project. The
success or failure of the project lies in whether everyone has contributed their best.
Responsible since the team is entrusted with taking care of the project, the team as a
2/7

whole feel responsible for the scope of the project as well as the ultimate success of the
final product, not individuals (e.g. functional managers or the CEO) outside of the team.
Every member will perform their best to achieve overall success.
Make this happen
Involve everyone in decision making right from the beginning
Facilitate discussions among all team members to ensure everyone is always heard
Determine whether team decision or individual decision is needed case by case
Deal with team member conflicts or office politics proactively
Form a trusting relationship with all team members by not micro-managing their tasks
3. Fixed Time Box

Unlike traditional project management processes in which the project managers would try to
collect all the requirements from the very beginning and formulate a all-encompassing project
schedule based on the available resources and the interdependencies of the project tasks,
Agile does not make the assumption that requirements are clearly know at the start of
the project. Agile embraces changes in requirements as a fact in the project life and believes
that having a working software for the end users / customers to play with would help them to
better understand their needs.
Therefore, Agile project teams work within a fixed time box. Tasks are assigned priorities with
an estimated number of man-days. At the beginning of each time box, the team choose from
among the list of top priority tasks a number of tasks to be finished by the end of the time box
and work accordingly to give a working product at the end.
In normal projects, once an element of the Triple Constraints (i.e. time, cost and scope, aka
iron triangle) is changed, the other two elements must also be changed in order to maintain
the quality of the outcome. In Agile projects, only the scope from the triple constraints
would be adjusted while the time and cost would be kept constant.
Make this happen
Embrace changes (new requests, changed requirements, changed priority, etc.) and
incorporate them with a change control process
Assess new requests / requirements based on their priority in relation to the list of
collected requirements and adjust the scope for each time box
Fix the launch date of the deliverables so as to keep the team focusing on achieving the
goal
4. Requirements At a High Level

Requirements for Agile projects are collected according to the following two ways:
3/7

At a high level
Requirements are collected at a high level, just enough to give an idea of the required
product for budget estimation purposes.
Requirements are documented in the form of User Stories (showing how the users
interact with the product) rather than detailed specifications.
On a just-in-time basis
Since requirements may change along the progress of the project, requirements are
gathered only when necessary for carrying out the tasks right away.
Not to collect requirements for tasks several weeks away or more
Requirements are usually captured using visual methods (e.g. diagrams and storyboards) for
better understanding across the team. Storyboards shows how the users interact with the
product with hand sketches, wireframes or annotated screenshots.
Make this happen
Expect and prepare for changes in requirements.
Only collect barely enough details for the requirements (can be in the form of
documentation or storyboards) to estimate budget and carry out the work.
Hold workshops to gather the whole team together to understand the requirements as a
team effort.
Record requirements in the form of deliverables (e.g. design the website is NOT a
deliverable; interface design for the website is) and put each deliverable on a separate
card so that the priorities can be easily changed when more requirements are added
along the road.
5. Incremental Project Releases

Incremental releases means building on a previous release of the product / outcome. With
incremental releases, not all the requirements of the users are to be met in a single release,
only the top priority requirements as determined by the team and users. But with releases upon
releases, all the requirements will be met ultimately.
The project runs through many iterations (cycles or sprint) of
1.
2.
3.
4.
getting requirements
development works
testing
releasing the product to users / market
The benefit of this approach is flexibility and ability to respond to actual needs instantly.
Feedback can be sourced from actual users / market which can help adjust the direction of the
project for new features / changes.
4/7

Also, the works and contributions of the project team can be appreciated by people outside the
team as the many releases act like a progress report which in terms can boost the morale of
the team. The organization can also benefits from the new features introduced instantly. Should
there be any early termination of the project, there is aways something useful left.
Make this happen
Establish the core functions (top priority requirements) to be included of the first and
subsequent releases through discussion between the team collectively
Make use of the MoSCoW analysis (Must have, Should have, Could have, Wont have)
Try to keep the number of core functions low (keep it simple rule) to enable delivery of
next incremental release in a short timeframe (usually a week or two)
Focus only on achieving the identified core functions in each iteration and finish all of
them before the beginning the next iteration
6. Frequent Delivery
Make plans to enable the time between each incremental release to be short enough so that
you can:
realize value through early value delivery to reduce risks and attain stakeholder
satisfaction (e.g. to gain organizational support)
keep the momentum going by always focusing on the next shippable product
get timely feedback from users / customers which will be gathered to adjust the project
direction
let users know the progress by a workable product release
create competitive advantage as new features can be introduced real quick
Frequent delivery is especially suited for web-hosted services as there is little overhead for reinstallation, upgrade or manage. The delivery schedule would range from a week to around 30
days for most Agile projects.
Make this happen
Get feedback from users / customers (or through analytics) for timely input to help reprioritizing the features to be included in the next release
Plan a fixed release cycle so that the team has a common goal to work towards the
deadline
Let the whole company know the release plan so that they can work together to make
the project a success (e.g. Marketing for press releases, Support for training materials)
7. Finish Tasks One by One

For the Agile tasks:
5/7

Plan the reasonable amount of tasks for each iteration so that all tasks can be finished
in each iteration.
The tasks should meet the requirements of the Definition of Done which is established
by the team.
This enables frequent delivery of complete (ready for customer use) features.
Completed tasks can act as a sign of progress check which keeps the team focused.
Make this happen
Involve the users for testing
Ask for sign-off of completed features from the customers
Establish a standard procedure (e.g. develop test approve) for each iteration so that
no steps are left out
8. Pareto Principle
The Pareto Principle is also known as the 80/20 rule. It is a statistical principle that holds
true for many things have a similar 80/20 distribution.
In Agile development projects, the Pareto Principle applies to the fact that 80% of all
development effort should be spent on the top 20% of the features that the customer
actually ends up needing.
Need to identify the top 20% of features that customers actually need and use most
frequently.
Make this happen
Educate end users and project stakeholders on the Pareto Principle.
Prioritize the development efforts based on the Pareto Principle and try to identify the
most beneficial and useful features.
Work with the whole team for more accurate choice of features.
Check the project scope with customers and stakeholders regularly to identify any
changes in requirements.
9. Testing Early and Frequent

As each product release in an Agile project needs to be complete, each iteration needs
to include a robust testing process to ensure the finished tasks are complete.
The testing process is integral to the development cycle, there is no a distinct testing
phase.
Everyone in the Agile team is responsible for the testing of the product.
Tests should be run time and again to ensure new feature would not break the
functionality of existing features.
The Agile tester should refer to the Definition of Done to guide the requirements of
testing.
6/7

Make this happen

Include automated tests for more robust and efficient testing.
Include testing as a normal development routine.

Involve the whole team to perform the testing.
Integration tests are very important.
10. Teamwork
Change is normal in Agile development, documentation is usually kept at a minimal.
All the Agile team member should work together in a team so that any changes can be
communicated with everyone.
Make this happen
Collocation is one of the best tactic to ensure great teamwork.
Use of a feature board / task board as a focus point / information radiator for the team.
Conclusion: Understand Agile for the PMI-ACP Exam

These ten fundamentals of Agile project management philosophy form the basis of all Agile
frameworks and methods. Though the PMI-ACP certification exam would test you on different
Agile implementations, like Scrum, XP, Kanban, etc., the above ten fundamentals are still valid
no matter which implementation is selected.
? PMI-ACP Study Notes: Agile Manifesto ?
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

7/7


[PMI-ACP Exam study notes] The Agile movement began with the publication of the Agile
Manifesto. This post takes a look at what the Agile Manifesto is and the twelve core Agile
principles for the PMI-ACP certification exam. Several question on the PMI-ACP exam will be
about the Agile Manifesto. PMI-ACP aspirants are advised to remember the Agile Manifesto
word by word as the difference between correct and incorrect answers may be just one or two
terms.
Background of Agile Manifesto

In February 2001, 17 software developers who have already been practicing incremental
software development methodologies met at the Snowbird, Utah, to discuss the future of
software development. They later formed the Agile Alliance.
The Manifesto for Agile Software Development (Agile Manifesto) was published to
define core principles and approaches common to their software development
methodologies to develop softwares / products more efficiently
Some of these authors form the Agile Alliance afterwards to further promote Agile
software development.
The Agile Manifesto was written at a high level aiming to define what to do in Agile
projects (the specific how to implement the principles is left to different Agile methods
which can be adopted based on project characteristics and needs).
While many Agile practitioners disagree on the implementation details, they all follow the
Agile Manifesto principles.
The most popular Agile implementations are Scrum, Lean, XP, etc.
The Agile Manifesto
1/6

Below is the Agile Manifesto (Values) in its entirety:

We are uncovering better ways of developing software by doing it and helping others do
it. Through this work we have come to value:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
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.
Kent Beck
James Grenning
Robert C. Martin
Mike Beedle
Jim Highsmith
Steve Mellor
Arie van Bennekum
Andrew Hunt
Ken Schwaber
Alistair Cockburn
Ron Jeffries
Jeff Sutherland
Ward Cunningham
Jon Kern
Dave Thomas
Martin Fowler
Brian Marick
2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.
The essences of the Agile Manifesto are further explained below:
Individual and interactions over Processes and tools

People and their opinion are fundamental to project success
Feedback from end users / customers is highly encouraged
The project team cooperate with the end users / customers to achieve project success
Processes and tools in the traditional project management are considered as supportive
rather than limiting factors
Teamwork is highly valued
Working software over Comprehensive documentation

The team should focus on the shippable deliverables (to deliver actual values)
Documentation is kept to a bare necessity (barely sufficient documentation)
[for software projects] nothing speaks louder than code and the code should be selfdocumenting
for the customers, a working software is more valuable than a set of documentation
2/6

gets minimally marketable features (MMF) delivered at very short duration
Customer collaboration over Contract negotiation

Efforts should be put into fulfilling the requirements of the customers rather than
negotiating the terms of the contract (Agile practitioners and customers are on the
same side of the table)
Relationship between customers and the team is highly valued
The ultimate goal of the project may be realized by trial and error
A contract (e.g. contract statement of work (SOW), project charter or requirements
document) is needed but it is not the most important document for the project
e.g. Acceptance Test Driven Development - all increments are demonstrated to the
customer for verification and acceptance before the team moves forward to next
iteration
Responding to change over Following a plan

Changes are welcome and should be well prepared for
No rigid or detailed planning which may impede flexibility
Implement change-friendly project management methodologies to ensure timeliness in
carrying out the changes
in traditional project management, gold plating and scope creep are considered
detrimental, but can be accommodated in Agile projects with mutual consent
The Agile Manifesto has made it clear that it recognizes the values of traditional project
management methodology like tools, processes, documentation and plan, but to a degree that
would not limit the ability to respond to changes.
12 Agile Manifesto Principles

A supporting document of 12 principles to the Agile Manifesto is also published to provide more
in-depth explanations of the Agile concepts.
Provide Value to Customer

1. Customer Satisfaction: Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
early delivery of products to customer for testing and feedback
continuous delivery to let customer know the progress
deliver values to the customers by fulfilling the top priority requirements first
2. Welcome Changes: Welcome changing requirements, even late in development.
Agile processes harness change for the customers competitive advantage.
simplify the change control process, no formal documentation and approval
required
allow fast response to latest changes in external environment to enhance
3/6

competitive advantage to emerging opportunities

3. Frequent Delivery: Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
can release the product to the market faster
provide immediate values to the customers by delivering working features
the project team activities can be better structured with the fixed delivery
timeframe to focus on delivery of value
Facilitate Teamwork
4. Collocated Team: Business people and developers must work together daily
throughout the project.
collocation of team members can foster osmotic communication (with vehicles
other than verbal, e.g. gesture, what not being said, etc.)
get instant feedback to questions, others at the location can join in the
discussion if deem related
the whole team can remain focused and work towards a common goal
5. Motivated Individuals: Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
team members are able to choose the jobs they are most interested in through
self-organization (not through external management influence)
the team is empowered to make day-to-day decisions
every member is motivated to achieve success
vs traditional project management -> micro-management, top-down approach
6. Face-to-face Conversation: The most efficient and effective method of conveying
information to and within a development team is face-to-face conversation.
get direct feedback by going to the source of problem or confusion
often via oral communication at the workplace for the benefit of osmotic
communication
tools like video conferencing can facilitate virtual team conversation
Deliver Great Products

7. Working Software: Working software is the primary measure of progress.
the working software enhance customer satisfaction
measurements of the working software are necessary to maintain and improve
the quality
the software will be judged on whether it can support the overall project goals
traditional project management focuses on plans and documentation
8. Constant Pace: Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.
helps to promote work-life balance among the team members to promote
happiness by avoiding burnout or exhaustion
a happy team is also a motivated and productive team
the team can respond to changes quickly
4/6

traditional project management would accelerate near deadline

9. Continuous Attention: Continuous attention to technical excellence and good design
enhances agility.
agility is the ability to modify, improve and upgrade in a short time
codes need to be refactored from time to time to enhance agility so that changes
to the products can be easily introduced
time spent on achieving quality code and finishing requirements should be well
balanced
10. Simplicity: Simplicity the art of maximizing the amount of work not done is
essential.
focus on what are essential to create value to the project and customer
discard any distractors that do not act values (components, process, etc.)
the simpler the product, the easier to maintain it, the less risks are there to
control
Quest for Better

11. Self-Organization: The best architectures, requirements, and designs emerge from selforganizing teams.
the team knows best how to carry out the work, not the project manager nor
human resources department
higher level of ownership of the product and will be dedicated to project success
the team becomes experts in how to improve the process and project as they
understand the project details
most significant difference from traditional waterfall project management
12. Regular Reflection: At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
need to gather the lessons learned frequently during the project and put back
into the next iteration
retrospective meeting as the primary tool what works and what doesnt and
suggestion / solutions
changes can be implemented immediately
traditional project management carries out reflection only at the end of the
project/phrase
Conclusion: PMI-ACP Exam Study Notes Agile Manifesto

This PMI-ACP exam study note has given an overview of what the Agile Manifesto is about,
including the core values as well as the twelve principles behind it. The Agile Manifesto forms
the basis of all Agile methods implementation available today.
? PMI-ACP Study Notes: Agile FundamentalsPMI-ACP Study Notes - Declaration of
Interdependency ?
5/6

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

6/6

PMI-ACP Study Notes: Agile Project Management vs

PMBOK Guide
Categories : PMI PMP Exam Tips, PMI-ACP Exam
Tagged as : 47 processes of project management, PMBOK Guide, PMI, PMI-ACP Certification,
PMI-ACP Exam, PMP Certification, PMP exam prep
[PMI-ACP exam study notes] Both the PMP Certification as well as the PMI-ACP
Certification are created and administrated by the Project Management Institute. This post
addresses the relationship between what is written in the PMBOK Guide (PMP exam) and
Agile principles and practices (PMI-ACP exam).
Agile Project Management (PMI-ACP)

There is no official reference guide for the PMI-ACP Certification Exam. PMI only provides a
list of eleven reference books with close to 4000 pages in total. In addition, the Agile Manifesto
is an indispensable part of the exam syllabus.
Traditionally, project management is often seen as perfecting a project management plan and
following the plan to completion. However in the fast moving world, and in particular the
software development industry, adjusting to the changing environment is considered far
more important than following the plan. And this gives rise to the proliferation of Agile project
management.
Under Agile project management, the project is kicked off with barely sufficient details
with the assumption that requirements will become clearer as the project moves on. The
project will continuously evolves and adjusts to to reach success. Agile project management
methodologies describe how to do the things that should be done rather than what to be
done.
1/3

Agile project management is often carried out in an iterative fashion (called Agile sprints with
relatively short duration). Agile methodologies start with developing a Product Vision, follows by
development and prioritization of user stories, a series of sprint or iterative cycles, reviews and
ends with Product Delivery.
Project Management PMBOK Guide (PMP)

Unlike the PMI-ACP Certification Exam, the standard reference book for the PMP Certification
Exam the PMBOK Guide (A Guide to the Project Management Body of Knowledge) is
published by the PMI. The most current edition of the PMBOK Guide is the Fifth Edition. The
PMP Exam is largely based on the PMBOK Guide.
The PMBOK Guide, on the other hand, describes a plan-driven approach about what should
be done during the management of a project. It describes 47 processes of project
management grouped within 10 Knowledge Areas and 5 process groups according to the
project management lifecycle (more on the PMBOK Guide processes, knowledge areas and
process groups here).
The PMBOK Guide represents a more traditional way of doing project management: from
creating and perfecting a plan, carrying out the project according to the plan, making corrections
for deviations, to closing the project by archiving what are learnt along the project development.
Each process is described in details with the ITTO (inputs, tools & techniques, outputs)
approach.
The project lifecycle described in the PMBOK Guide begins with processes associated with
Initiating the project, follows by processes for Planning, Executing and Monitoring & Controlling
(often in a recursive manner), eventually ends with processes for Closing (end the project or
phase).
Agile Project Management vs PMBOK Guide

Agile
Essences
Project Nature
Attitude to Changes
Customer Involvement
Project Requirements
Documentation
PMBOK Guide
Plan driven
Plan,
process and change
control
Waterfall
Control changes
Gold-plating is to be avoided
Collaborative actively
Authoritative approving the
involved throughout the project plan and product
Requirements are getting more Rather fixed from the beginning
detailed as the project evolves
Barely sufficient
Detailed to track changes and
deviation, need formal change
Change driven
Value driven
People, collaboration
and shared value
Iterative
Embrace changes
2/3

Agile
Project Success
Advantages
Disadvantages
Ideal For
PMBOK Guide
approval
Measured against final outcomeMeasured against the plan
Can respond to
Easily controlled and
changes rapidly for
measured (costs,
competitive advantages
time and quality)
Know the output from
the beginning
When the processes
are designed right,
quality is easily
guaranteed
Final product may be
Relies heavily on initial
vastly different from
requirements gathering
what is planned at the
Project may fail owing to
beginning
faults in the plan
Depends very much on
Time spent on plans
getting the right people
and documentations are
on board
costly
Cost overrun may be
Changes are not easily
expected
accommodated
Projects with fast changing
Large projects with relatively
environments (e.g. software
fixed requirements (e.g.
development)
construction)
Mike Griffiths has published a detailed comparison between Agile practices and PMBOK Guide
(though based on the 4th edition), a good read for those coming from the PMP background who
would like to pursuit the PMI-ACP exam.
Is Agile and PMBOK Guide Project Management Compatible?

Yes, project management processes described in the PMBOK Guide and Agile methodologies
are compatible. Projects practicing Agile methodologies can make use of the processes
described in the PMBOK Guide because Agile is about the how a project is to be carried
out and PMBOK Guide is about what should be done. After all, it is up to the project
manager to determine which principles and practices to apply in any given project an
emphasis of both the PMBOK Guide as well as Agile project management.
?
1. PMI-ACP Study Notes: Agile Project Management vs PMBOK Guide
3/3


[PMI-ACP study notes] Following the publication of Agile Manifesto in 2001, a number of
authors worked on the management principles for the adoption of the Agile principles. In 2005,
the Declaration of Interdependence was published put forward six essential principle for modern
project management (and management as a whole).
Below is the Declaration of Interdependence in its entirety:
Declaration of Interdependence
Agile and adaptive approaches for linking people, projects and value
We are a community of project leaders that are highly successful at delivering results.
To achieve these results:
We increase return on investment by making continuous flow of value our
focus.
We deliver reliable results by engaging customers in frequent interactions and
shared ownership.
We expect uncertainty and manage for it through iterations, anticipation, and
adaptation.
We unleash creativity and innovation by recognizing that individuals are the
ultimate source of value, and creating an environment where they can make a
difference.
We boost performance through group accountability for results and shared
responsibility for team effectiveness.
1/3

We improve effectiveness and reliability through situationally specific

strategies, processes and practices.
2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald,
Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert
Wysocki.
Elaboration to the Declaration of Interdependency

The Declaration of Interdependency outlines the leadership approaches used to manage the
interdependency of people, processes and value to enhance the performance of work. The six
principles are:
1.
2.
3.
4.
5.
6.
Focus on Value
Engage Customers
Expect Uncertainty
Unleash Creativity
Group Accountability
Improve Effectiveness
1. Focus on Value
value is determined by how close the requirements of the users / customers are met
only work on features that are actually requested by the users / customers
changes requested by users / customers will always be embraced
2. Engage Customers
customer feedback is critical to success of the project
interact frequently with the customers to understand and gain trust
treat customers as team members
3. Expect Uncertainty
prepare for changes in requirements and environment through short development
iterations
changes would add value to the final product
4. Unleash Creativity
team members are motivated to contribute their best
members understands their values to the project and are presented with a common goal
feedback from each individual is highly encouraged
2/3

5. Group Accountability
the team is empowered through self organization
empowered team members are committed to working together to the final success
the success or failure of the project would be borne by the team as a whole
6. Improve Effectiveness
though the environmental conditions will never be perfectly suited to Agile way of project
management, the team will try their best to tune the processes and strategies to improve
effectiveness situation by situation
review and evaluation will be performed often to gain new insights into how to best
implement the Agile principles
These six principles provides the guidelines on the six interdependent aspects of any projects to
link people, processes and value. These aspects must be well managed to give the best project
results.
Conclusion: PMI-ACP Study Notes Declaration of

Interdependency
This PMI-ACP study note has given an overview of the Declaration of Interdependency, which
was written to provide management guidelines on how to best implement Agile principles to link
people, processes and value.
? PMI-ACP Study Notes: Agile ManifestoPMI-ACP Study Notes: What is Agile? ?
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

3/3


Tagged as : Agile, Certification Study Notes, PMI-ACP Certification, PMI-ACP Exam, PMI-ACP
Knowledge and Skills, PMI-ACP Tools and Techniques
[PMI-ACP Exam Study Notes] Unlike the role of project managers in traditional waterfall
project management, Agile managers (e.g. ScrumMaster, Coach, etc.) have the primary role of
helping team members to embrace Agile principles and removing obstacles. Ideally, Agile teams
are self-organized and self-managing. Agile coaching is therefore an important function for the
smooth running of Agile projects.
Agile Coaching and Mentoring

In Agile projects, management has the key role of ensuring self-organization and self-managing
of the Agile team happen. The Agile manager, on one hand, needs to shield the team from
external pressures and interference; on the other hand, support the project team to implement
Agile principles.
Agile Concepts and Meetings
Daily Stand-ups a 15-minutes time-boxed meeting attended by the team
members to catch up on the progress for the iteration by focusing on the
following 3 questions:
What has been done yesterday?
What are planned for today?
Any roadblocks or impediments?
Iteration Review to demonstrate the deliverables of the iteration to the
customer and other stakeholders
Iteration Retrospectives for the team members only, to review what internal
processes could be improved for the next iteration, not to finger point or find
faults
1/3

Process Tailoring processes should add values to the project, all the Agile
processes can be tailored to fit the particular needs of a project
Team Motivation including support, team participation, ground rules and team
performance visibility
Soft Skills Negotiation

Emotional Intelligence people with high E.I. can relate to people, deal with people
issues effectively and gain support from other
Collaboration everything about Agile should encourage collaboration, including
communication, co-location, self-organization, decision making, etc., collaboration is
integral to Agile projects
Negotiation negotiation is an important activity for Agile which yields productive
results; plan, schedule, features, changes, etc. are negotiable
Active Listening active listening includes: listening, understanding, retaining and
actively responding, can reduce conflicts within the team
Conflict Resolution conflict should be resolved by searching for a win-win solution
through active listening and communication
Servant Leadership Leaders for Agile projects should practice servant leadership,
they are not in the command and control position but rather be a servant to enable the
team to perform well and model the right behavior
Adaptive Leadership the leader adapts to the environment to lead effectively, i.e. to
focus on value-adding activities and discard wastes
Summary
This piece of PMI-ACP Exam study notes describes the knowledge and skills required by Agile
team leaders to perform coaching and mentoring with a view to enhance the efficiency of the
Agile team and removing any roadblocks. Tools and techniques for Agile coaching are also
covered.
? PMI-ACP Study Notes - Agile Project Execution
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

2/3

3/3


Tagged as : Agile, Certification Study Notes, PM Plan, PMI-ACP Certification, PMI-ACP Exam
[PMI-ACP Exam Study Notes] After having obtained the project charter, the customer /
Product Owner and the team would be engaged in the planning for the Agile project. Agile
planning deals with project organization, planning, management, communications and
continuous management. Though it is often said that Agile projects emphasis on responding to
changes rather than planning, a right amount of planning is required for the projects to kick off
successful.
Stakeholder Identification
Stakeholders are anyone with an interest in the project (can be positive or negative).
For Agile projects, the project team and the customer are NOT considered as
stakeholders (in traditional project management and according to the PMBOK Guide,
stakeholders include the project team but not the project manager).
The customer / Product Owner would try to understand the needs (including
communication needs) of the stakeholders and bring their views into the project.
The stakeholder registry would include barely sufficient information about the
individual stakeholder groups support level, preferences, etc.
Agile Project Analysis (Initial and Continuous)

Agile teams do need to carry out analysis and planning at the beginning of the project
(often termed as Iteration 0) and during the project (retrospectives, etc.)
The project team would discuss in depth about problems and wants of the customer
through face-to-face communication, often with the help of some tools and techniques
(many are similar to what are described in the PMBOK Guide):
1/4

Brainstorming everyone to voice out their opinions without immediate

judgement
Innovation games games are used to engage the team members and
customer, e.g. 20/20 Vision, the Apprentice, Buy a Feature, Product Box, Prune
the Product Tree (reference: Innovation Games: Creating Breakthrough Products
Through Collaborative Play by Luke Hohmann).
Parking lot chart a piece of paper to put important but off-topic issues /
queries for later investigation / discussion, e.g. in requirement gathering
Agile Analysis Concepts
Value Stream Mapping inspired by Lean Manufacturing, this is the method to
analyze the processes to eliminate wastes
Root cause analysis with cause and effect diagrams (Ishikawa / fishbone
diagrams), five whys
Force field analysis to understand the forces for and against a change
Agile Planning
The accuracy of estimation will improve over time on a project in the form of Cone of
Uncertainty (25%-400% from the very beginning to within several percentage near
complete)
Agile Planning Artifacts and Meetings
The Product Vision Statement is developed by the Product Owner (with the
help of the team) as an elevator statement on the purpose of the product
The Product Roadmap tells the about the schedule and cost milestones an
overview of the planned releases of the project, the Product Roadmap will
change over time
Personas realistic depiction of likely users for the product, can be real or
fictitious
Wireframes as a sketch graphical presentation of how the requirements are
fulfilled, as a kind of requirement documentation
Release Plan responsible by the customer / Product Owner with the help of
project team in release planning to indicate the availability dates for features,
subject to changes depending on actual progress / change requests
Agile Planning Terms
Agile Themes a theme for an iteration for grouping similar functions to be
done in a batch, e.g. bug fix, reporting, etc.
Epic Story a large block of functionality (spanning several iterations) will
later be disaggregated into user stories for implementation
User Story taking the format of As a [role], I want [need] so that [business
value] to describe the requirements in real world scenarios, often written on
Story Cards
[INVEST] Independent, Negotiable (can be discussed on
implementation), Valuable, Estimatable (adequate info), Small, Testable
Story Maps an overview of how individual user stories are related to each
other
2/4

Features a capabilities / group of functionalities that is of value to the end user

Minimal Marketable Feature (MMF) the smallest group of functionality that
can offer value to the end user, can be put into production once finished but
depending on the decision of the Product Owner / customer
Tasks the underlying actions / development work to be taken to finish a user
story, tasks are taken up by the team through self-organization
Agile Planning Concepts
Progressive Elaboration knowledge about the product and requirements will
be clearer as the time goes by, those will be revisited and refined continually
Rolling Wave Planning break down the planning into stages, with the neartime planning to be carried out first
Definition of Done this is a written consensus of what are considered Done
of the whole team (including the customer)
Timeboxing to combat Pakinsons Law by introducing a fixed deadline for
tasks/meetings in order to enhance efficiency
Agile Estimation
Agile Estimation Concepts, Tools and Techniques
Relative Sizing traditional project management would estimate in terms of
money and time, but in Agile project relative sizing (e.g. story points) will be used
as Agile projects are more prone to changes and thus it is not meaningful to
estimate in exact units
Ideal Time a block of uninterrupted period to focus solely on the task without
distractions of others/tasks/routine, etc. for estimation (though not realistic in real
world)
Wideband Delphi Estimating allow discussion of details of the requirements
first and then each individual would try give an estimate for the user stories, etc.
with relative sizing, repeat until a consensus is reached
Planning Poker each members select from a deck of cards (with ?, 0, 1, 2, 3,
5 ) the story points for a user story, discuss to reach a consensus
Affinity Estimating assign a size (e.g. S, M, L, XL, XXL) to user stories
Summary
This piece of PMI-ACP Exam study notes describes the tools and techniques, artifacts and
concepts for Agile Planning and Estimation. Though Agile is often considered to be low on
planning, planning is very important for Agile projects and the actual Agile planning scattered
over the whole project duration.
? PMI-ACP Study Notes: Agile Methodologies for PMI-ACP ExamPMI-ACP Study Notes - Agile
Project Execution ?
3/4

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

4/4


Tagged as : Agile, Certification Study Notes, PMI-ACP Certification, PMI-ACP Exam, PMI-ACP
Knowledge and Skills, PMI-ACP Tools and Techniques
[PMI-ACP Exam Study Notes] The distinction between Agile Planning and Agile Project
Execution is not clear cut. In fact, for Agile projects, planning is interwoven into the project
execution following the plan-do-check-act cycles. Analysis and planning is performed for every
iteration and even every day of Agile life.
Working with Agile

Agile terms
Velocity a measure of Agile project progress (e.g. the number of story points
in each iteration), useful for predicting and planning future releases
note that if a task is not 100% finish, the story point will NOT be counted
towards the iteration, e.g. 50% completeness of a task with 100 story
point gives 0 story point
Cycle time the amount of time for a feature from start (entering into the
product backlog) to finish (done), the shorter the better
Burn rate the amount of cost estimated over a given period of time (e.g. $1000
per day)
Escaped defects defects that are discovered by the customer, used for
tracking the effectiveness of testing and quality control measures
if the escaped defects trend up, a root cause analysis should be carried
out
Agile smells Agile term for symptoms of a problem
Agile concepts
Verification ensures functionality meets requirements
Validation ensures the deliverable works as intended
1/3

Refactoring [for codes] re-organizes and simplifies the code without changing
the behavior
Osmotic communications takes up information through overhearing
communication between other members and participate if deemed relevant,
usually for co-located teams
Information radiators display of key info in a highly visible location for
communicating project progress
Agile Earned Value Management (EVM) make use of the velocity to
calculate planned value and actual story points completed for the current
iteration as the actual value
Incremental delivery by its nature, Agile project embraces incremental
delivery get working parts to end users as fast as possible
Kaizen a Japanese management philosophy of continuous checking and
improvement
Spikes a short experimental test to help decisions making, e.g. trying a new
technology for feasibility study
Stakeholder Management managing stakeholders and their expectations is
one of the core responsibilities of the Agile team
Agile artifacts
Product backlog responsible by the customer, the product backlog is a
complete prioritized listing of all features/user stories for the Agile project, the
priority is usually based on the perceived value by the customer
grooming add items based on new user stories and delete old items
[DEEP] Detailed appropriately, Estimable, Emergent, Prioritized
Risk-adjusted backlog usually the product backlog would need to be
re-prioritized based on risk analysis input from the team and stakeholders
and balance the risk vs value factor
risks are usually considered to be possible negative impacts
(though there are many possible positive impacts)
Iteration backlog responsible by the team, the iteration backlog contains tasks
for the iteration, tasks are allocated through self-organization
Burn-down charts show the tasks remaining (in story points, etc.) over the
project life
Burn-up charts show the tasks completed (in story points, etc.) over the
project life, better than burn-down charts as scope changes are clearly visible
Kanban boards a task board showing the progress of tasks through the
project processes, can be tailor-made to suit individual projects
a WIP limit (work-in-progress) would be enforced to ensure efficiency;
work-in-progress are tasks that have been started but not yet done
Cumulative flow diagrams a chart showing the state of all tasks through the
project processes; a widening band indicates some issues for the process that
may need intervention (e.g. root cause analysis, WIP limit, etc.)
Summary
2/3

This piece of PMI-ACP Exam study notes describes the working of Agile projects, including the
daily stand-ups, iteration, iteration review and iteration retrospectives, etc. Tools and techniques
for working with Agile are also covered.
? PMI-ACP Study Notes - Agile PlanningPMI-ACP Study Notes - Agile Coaching ?
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

3/3


Tagged as : Certification Study Notes, PMI-ACP Certification, PMI-ACP Exam
[PMI-ACP Exam Study Notes] Project justification looks at how to determine whether a project
would be carried out or not while chartering is the formal begin of any projects. These processes
apply to both traditional waterfall project management and Agile project management.
Project Justification
The following are a number of concepts/terms used in evaluating a given project:
Value-based Prioritization when given a number of proposed projects, assign a
financial value in terms of money to every project and choose the one with the best
return
Present Value (PV) vs Net Present Value (NPV)
a dollar today worths more than a dollar tomorrow (owing to inflation, etc.)
Present Value (PV) indicates the actual value a project worth at present, the
larger the better
Net Present Value (NPV) is the PV minus the cost
Internal Rate of Return (IRR) express the projects projected return as an interest
rate (in %) based on the cost, the larger IRR the better
Return on Investment (ROI)
the return (expressed in percentage) based on the investment
(benefit cost) / benefit * 100%
the larger the better (note: the contesting projects need to have comparable
scope)
Compliance the project would be given high (if not top) priority if it is carried out to
meet regulatory requirements
1/3

Chartering
If a GO is received for a project after the project justification process, the performing
organization needs to create a project charter through the chartering process.
Creating the charter is IMPORTANT and necessary even in Agile project environment
A charter is the formal document that authorize a project (names the project manager,
gives the resources and authority, etc.)
Facts about Project Charter for Agile Projects

As part of Iteration Zero before the actual project work has begun
To be signed by senior management to give official authority for the project manager
and resource allocation
Names the project manager (if applicable)
Addresses the 5W1H (What, Why, Who, When, Where and How) of the project
Similar to Develop Project Charter defined in the PMBOK Guide but the level of
details and assumptions are different: Agile project charters are less detailed and focus
on How since Agile projects are progressively elaborated
Includes high-level requirements, critical success factors, milestones (schedule), and
preliminary budget
Authority must be given to the team to carry out defined Agile processes that may be
different from organizational practices (e.g. change management)
The project charter must be created
Summary
This piece of study notes on PMI-ACP Exam examines the very first steps in carrying out a
project in both Agile or traditional waterfall project management. The project benefit must be
evaluated using project justification techniques and the project charter must be created.
? PMI-ACP Study Notes: What is Agile?PMI-ACP Study Notes - The Agile Team ?
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

2/3

3/3

PMI-ACP Exam Tips from the Trenches

Tips 1 Look out for Tricky Words

Since the PMI-ACP Exam is a test of your Agile knowledge and concept, you must look out
for the following words that are against the Agile principles. Though answers containing these
words are not automatically made false, you should raise a red flag and re-read the questions
and answers if the following tricky words appear:
assigned (tasks / user stories) Agile teams works with self organization, not work
assignment
escalate (the situation) the very nature of the Agile team formation (with Product
Owner / Customer co-located) makes escalation of issues much less than traditional
project management
Tips 2 Distinguish between the Meaning for the following Words

Some concepts for the PMI-ACP Agile Exam are often confused as they are quite similar, yet
failing to distinguish them will result in an answer wrong:
user story vs task user stories will add value (bearing story points) but that is not
necessarily true for tasks
affinity estimating vs relative sizing both have similar meaning, relative sizing is
estimating the efforts in relation to other user stories while affinity estimating is the use
of common sizing units to compare task sizes (like S,M,L,XL or coffee cup sizes), affinity
estimating is usually used for release planning (early stage) while relative sizing is used
in iteration planning
Tips 3 The general Agile principles and practices are correct
1/2

Since Agile allows process tailoring, many of the Agile processes can be tailored to
suit the particular needs of a project environment. For many PMI-ACP questions, it
may seem that many answer choices of a question are feasible. Yet, one should
consider the answer choices according the general Agile principles and practices (i.e.
the plain-vanilla Agile processes) and select the answer that is the general
recommendation / practice.
PMI-ACP candidates should study the plain-vanilla Agile processes and practices and
cannot depend only on their actual working experience to answer the exam questions.
2/2


Tagged as : PMI, PMI-ACP Certification, PMI-ACP Exam
[PMI-ACP exam study notes] Traditionally, project management follows the waterfall
approach, i.e. a project management plan is created at the very beginning to guide the project
to completion. Agile project management, which comes into being in the mid 1990s, represents
a shift in paradigm in the world of project management from following a plan to responding to
changes.
What are Methodologies in Project Management?

A methodology is a set of processes and practices performed in a specific way to
accomplish a project.
A methodology can be thought of a specific way to carry out a project in order to reach a
goal, it may include workflows, processes, deliverables, approval path, checklists and
policies, etc. A well-developed methodology is important to achieve project success in
an effective and efficient manner.
Agile can be considered as a family of project management methodologies, including
XP, Scrum and Lean, etc.
Traditional Waterfall Approach

Following a path/plan
Make reference to the Deming Cycle: Plan-Do-Check-Act: analysis -> planning ->
documentation -> carry out the plan -> compare results w/w plan -> take corrective
action
1/4

The project manager dictate the direction of the project

Advantage: well documented, well controlled
Disadvantage: rigid, resistant to changes, process-centred (instead of product-centred),
commit to a specific solution early in the project, customers not involved
Agile Project Management

Agile is a philosophy that emphases on people, collaboration and shared values.
The Agile Manifesto outlines essences of the agile philosophy (way of thinking).
Agile Methods/Methodologies are processes / way of working / framework that
support the Agile philosophy.
Agile methodologies includes SCRUM, XP, Lean and Test-driven Development (TDD),
DSDM, FDD, etc.
Agile projects are kicked off by at least 3 processes: product vision, product roadmap
and list of product backlogs. The interim phases in Agile projects are project
releases (marketable deliverables a working set of features) which is often made up of
several iterations. The final process is the project retrospective.
Iron Triangle vs Agile Triangle
(Agile) Iron Triangle / Triple Constraints: Schedule, Scope, Cost to deliver
Quality
Agile Triangle: Value, Quality and Constraints
Characteristics of Agile project management include:
The project team together conduct experiments to discover the best way to
handle the project through team consensus
Emphases on delivering values to the customer
Open and transparent communication within the team and with other
stakeholders using daily standup meeting, information radiators, etc.
Welcome to changes (even if late in the project) with just-enough planning for
each iteration
Work is carried out iterations and products are delivered continually (usually in
small increment) to the customer for testing and feedback (rolling wave planning)
Retrospective meetings are carried out after each iteration for process
improvements
Ever evolving and adapting
Requirements are written as user stories
a requirement description in terms of what the product will accomplish
and for whom
created by everyone involved in the project
ideal to be used as backlog items
typical template:
As a , I want so that .
e.g. as a student, I want to compose my PMI-ACP study notes online so
that I can revise the topics everywhere
Agile terminology
Agile Project Planning includes:
2/4

Product Vision: describes the goals of the product and how the
goals align with corporate strategy
Product Roadmap: a high-level view of product features and release
schedule (in quarters)
Release Planning
Iteration Planning and
Daily Stand-up meetings.
Agile epic vs Agile theme
An Agile epic is a group of related user stories (a large user story is
usually broken down into smaller stories to minimize complexity and
reduce uncertainty), all the user stories of an epic must be finished
before release
An epic must be decomposed to a number of user stories small enough
to fit in iterations
An Agile theme is a top-level objective of the product / project
theme > many sub-themes > many epics > many user stories
Which is Better, Waterfall or Agile?

Depends on the nature of the project:
Waterfall: details are known and agreed with low likelihood of changes; extreme
chaotic project environment
Agile: need for complex decision through experimentation, goal is not well
known in the beginning
The Stacey Diagram outlines the project environment which is friendly to Agile
methodology.
3/4

Stacey Diagram
Commonly Confused Agile Terms

Agile Manifesto a public declaration of the philosophy and principles of agile software
development
Agile Principles the fundamental truths and shared values that drive behavior in agile
methodologies
Agile Projects a project that is planned and executed based on tenets of Agile
Manifesto
Agile Methodologies frameworks and processes whose practices support the Agile
Manifesto principles, e.g. Scrum, XP, Kanban Crystal, Lean, TDD, DSDM, FDD
Agile Methods the processes that support agile philosophy
Agile Practices the activities that are the application of agile principles
Conclusion: PMI-ACP Exam Study Notes What is Agile?

This PMI-ACP exam study note gives an overview of the project management, which can be
divided into two major schools of thoughts traditional waterfall and Agile. It has also explained
what methodologies are and which project environments are suitable for the implementation
of Agile project management.
? PMI-ACP Study Notes - Declaration of InterdependencyPMI-ACP Exam Study Notes Project
Justification ?
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

4/4

PMI-ACP Study Notes: Agile Methodologies for PMI-ACP

Exam
Tagged as : PMI-ACP Certification, PMI-ACP Exam
[PMI-ACP exam study notes] Agile Methodologies is a very important topic for the PMI-ACP
exam. Methodologies describe the ways how the project is to be carried out (unlike traditional
project management with plans to describe what to be carried out). This article briefly touches
upon the essences of different Agile methodologies.
Agile Methodologies for the PMI-ACP Exam

Remembering roles as well as core concepts for the following Agile methodologies are required
to pass the PMI-ACP exam:
XP (eXtreme Programming)
Scrum
LSD (Lean Software Development)
Crystal Family
ASD (Adaptive Software Development)
DSDM (Dynamic Systems Development Method) Atern
FDD (Feature Driven Development)
Kanban
XP (eXtreme Programming)
XP (eXtreme Programming) is currently one of the most popular Agile methods. XP is a
disciplined approach to delivering high-quality software quickly and continuously at very
short intervals (typically every 1-3 week). XP promotes responsiveness to changes, higher
1/4

customer involvement, rapid feedback loops, continuous testing, continuous planning and close
teamwork. The name suggests that the beneficial elements of traditional programming practices
are taken to the extreme.
XP is based on 4 values and 12 supporting practices. The 4 values are: simplicity,
communication, feedback, and courage. The 12 supporting practices are: Planning Game,
Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven
Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding
Standards, Metaphor and Sustainable Pace.
Scrum
Scrum is considered a lightweight management framework suitable for managing iterative and
incremental projects (including product development projects other than software). Scrum has
grown rapidly in the past few years and is fast becoming one of the most popular Agile
methods, especially among the software industry. Scrum is renowned for its simplicity, proven
success, productivity, and its flexibility to be used as a framework for various engineering
practices promoted by other Agile methodologies, i.e. Scrum Masters are allowed to select the
most suitable Agile practices to be brought under the Scrum framework. Scrum adopts an
empirical approach by accepting problems cannot be fully understood at the beginning and
must be continuously attended to along the project.
LSD (Lean Software Development)

Lean Software Development is an iterative methodology developed from the processes and
practices in Lean Enterprise movement (for the production industry). Lean Software
Development focuses the team on delivering value to the customers by focusing on the Value
Stream. Core Lean principles include: Eliminating Waste, Amplifying Learning, Deciding as
Late as Possible, Delivering as Fast as Possible, Empowering the Team, Building Integrity In,
and Seeing the Whole. The value stream approach emphasizes on the speed and efficiency of
development workflow, and relies on rapid and reliable feedback between programmers and
customers. Lean methods try to eliminate waste by prioritizing and working on truly valuable
features of a system and delivering values rapidly in small batches.
Crystal Family
The Crystal methodology is one of the most lightweight, adaptable approaches to software
development. Crystal is a family of methodologies including Crystal Clear, Crystal Yellow,
Crystal Orange, etc. The different methodologies in the Crystal family are differentiated
by factors like team size, system criticality and project priorities. The Crystal family allows a
tailored set of policies, practices and processes for individual projects in order to suit
the characteristics of the projects. Crystal methodologies emphases on the interaction between
people and processes.
ASD (Adaptive Software Development)
2/4

ASD embraces the principle of continuous adaptation of the processes to the project. It
consists of repeating series of speculate, collaborate and learn cycles. Characteristics of ASD
includes: mission focused, feature based, iterative, timeboxed, risk driven and change tolerant.
DSDM (Dynamic Systems Development Method) Atern

DSDM was first released in 1994 to provide guidance on Rapid Application Development (RAD)
and was primarily focused on software development. DSDM has evolved over the years to
become a generic approach for Agile project management and solution delivery by providing a
comprehensive foundation for planning, managing, executing, and scaling agile and iterative
software development projects. DSDM is based on 9 key principles that primarily revolve around
business needs/value, active user involvement, empowered teams, frequent delivery, integrated
testing, and stakeholder collaboration. By utilizing DSDM, costs, quality and time are fixed.
DSDM singles out fitness for business purpose as the primary criteria for delivery and
acceptance of a product. It makes use of the MoSCoW prioritization principles to deliver values
which is based on the principle that 80% of features can be deployed in 20% of the time.
FDD (Feature Driven Development)

FDD is a feature-driven methodologies that consists of short iterations (two weeks). It makes
use of a design by feature, build by feature approach where features through a client
perspective. FDD adapts the project development process around feature delivery by making
use of the following 8 practices: Domain Object Modeling, Developing by Feature,
Component/Class Ownership, Feature Teams, Inspections, Configuration Management,
Regular Builds, Visibility of Progress and Results.
Kanban
Kanban is a scheduling system used in Lean and JIT (Just-in-time) production. When applied to
software development, kanban is a pull-based planning and execution method. For software
development teams, cards representing tasks to be done are kept on a Kanban Board which
is organized into columns and rows. The columns represent the status, i.e. from initial planning,
work-in-process through customer acceptance. The status can be tailored to find the project
context. The rows contain the tasks to be performed. Since Kanban focuses on maximizing
throughput, a limit would be set on the maximum tasks in the Work-in-Process (WIP) column to
avoid bottlenecks. Queues or inventories of work in any state are seen as waste. The WIP
limit allows the team to focus on optimizing the flow of work items through the work processes,
thereby achieving process optimization at a sustainable pace.
Conclusion: PMI-ACP Exam Study Notes Agile Methodologies

This PMI-ACP exam study note gives an overview of all the different Agile Methodologies that
would be tested on the PMI-ACP exam including XP (eXtreme Programming), Scrum, LSD
(Lean Software Development), Crystal Family, ADS (Adaptive Software Development), DSDM
(Dynamic Systems Development Method) Atern, FDD (Feature Driven Development)
3/4

and Kanban.
? PMI-ACP Study Notes - The Agile TeamPMI-ACP Study Notes - Agile Planning ?
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

4/4


Tagged as : Certification Study Notes, PMI-ACP Certification, PMI-ACP Exam, Project Team
[PMI-ACP Exam Study Notes] The Agile team differs greatly from traditional project teams in
terms of organization, management and decision making. This is an important topic for the PMIACP Exam. The characteristics of the Agile team is listed below.
Self-organization
Self-organizing teams are the foundation for Agile project management
traditional project management: top-down approach, follow instructions/planning from
managers, little or no input from the front-line staff
Agile project management: the problem is handed down to the project team to determine
what and how to do
in Agile projects, the project manager/Coach/ScrumMaster are there to facilitate the
team in times of dysfunction, e.g. conflicts are necessary for high performing teams, if
the team culture is too reluctant to enter into conflicts, the Coach should be the one to
introduce some conflicts
Self organization includes: team formation, work allocation (members are encouraged to
take up works beyond their expertise), self management, self correction and determining
how to work is considered done
all members of the team are collectively responsible for the success (or failure) of the
project, everyone is responsible for everything
Agile projects work best when the team members are seasoned, self-directed and highly
motivated
team members should be involved in the selection and interviewing of new members
Open and Transparent
1/3

contribution and progress of individual members should be visible to all the team
work does not belong to a single member but the whole team
Small Team Size

in the book Succeeding with Agile by Mike Cohn, it is suggested that the team should be
able to be fed with a couple of pizzas
for larger projects, the team should be sub-divided (break down the project into subprojects)
for Scrum teams, the optimal team size is 7 2
Colocation
the ideal co-located team should be all in the same room with all barriers (e.g. partitions)
removed to facilitate communication and collaboration while minimize distraction
team members as well as the customer should sit around a square/circular table facing
each other
members can hear and see each other to facilitate communication
colocation can avoid the formation of silos (expert groups focusing on single aspects of
the project, communication across different groups is very challenging)
make use of information radiators (e.g. charts/backlog lists/user stories posted on the
walls) and whiteboards
if physical colocation is not feasible, virtual colocation by making use of instant
messengers/video conferencing software is highly encouraged
Agile Tooling
use of Agile tooling (a class of tools, technologies and practices) should be made to
help building bonding and sense of belonging by encouraging communication,
participation and information sharing
high-tech Agile tooling: instant messengers, video conferencing, online Agile
project management tools
low-tech Agile tooling: recreational space, daily stand-up meetings, team
building activities
Empowered Team
the Agile team is given the power to self-direct and self-organize by making and
implementing decisions, including: work priority, time frames, etc.
the team may optionally given the power to add value to the customer and choose team
members
an important aspect of the empowered team is to have the customer/product owner colocating with the team
the best person to make the decision is the one whose hands are actually doing the
2/3

work
factors needed: organizational buy-in, alignment with corporate goals, shared vision,
clear communication, customer involvement and team accountability
Ground Rules
ground rules are unwritten rules about the expectation of the project team members
including: work time, culture, language, rituals, etc.
Summary
This piece of PMI-ACP Exam study notes describes the characteristics of an Agile team which
include self-organization, colocation and empowerment. The Agile team is central to the
success of Agile project management.
? PMI-ACP Exam Study Notes Project JustificationPMI-ACP Study Notes: Agile
Methodologies for PMI-ACP Exam ?
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

3/3

Edward Chung ACP Notes

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Edward Chung ACP Notes

Uploaded by

Copyright:

Available Formats

PMP Exam, PMI-ACP, ITIL Certification Best Resources

Edward Chung Professional Certification Process and Notes

PMI-ACP Study Notes: Agile Fundamentals

Ten Agile Fundamental Principles

PMP Exam, PMI-ACP, ITIL Certification Best Resources

PMP Exam, PMI-ACP, ITIL Certification Best Resources

3. Fixed Time Box

4. Requirements At a High Level

PMP Exam, PMI-ACP, ITIL Certification Best Resources

5. Incremental Project Releases

PMP Exam, PMI-ACP, ITIL Certification Best Resources

7. Finish Tasks One by One

PMP Exam, PMI-ACP, ITIL Certification Best Resources

9. Testing Early and Frequent

PMP Exam, PMI-ACP, ITIL Certification Best Resources

Make this happen

Include testing as a normal development routine.

Conclusion: Understand Agile for the PMI-ACP Exam

PMI-ACP Study Notes: Agile Fundamentals

PMP Exam, PMI-ACP, ITIL Certification Best Resources

PMI-ACP Study Notes: Agile Fundamentals

Ten Agile Fundamental Principles

PMP Exam, PMI-ACP, ITIL Certification Best Resources

PMP Exam, PMI-ACP, ITIL Certification Best Resources

3. Fixed Time Box

4. Requirements At a High Level

PMP Exam, PMI-ACP, ITIL Certification Best Resources

5. Incremental Project Releases

PMP Exam, PMI-ACP, ITIL Certification Best Resources

7. Finish Tasks One by One

PMP Exam, PMI-ACP, ITIL Certification Best Resources

9. Testing Early and Frequent

PMP Exam, PMI-ACP, ITIL Certification Best Resources

Make this happen

Include testing as a normal development routine.

Conclusion: Understand Agile for the PMI-ACP Exam

PMI-ACP Study Notes: Agile Fundamentals

PMP Exam, PMI-ACP, ITIL Certification Best Resources

PMI-ACP Study Notes: Agile Manifesto

Background of Agile Manifesto

The Agile Manifesto

PMP Exam, PMI-ACP, ITIL Certification Best Resources

Below is the Agile Manifesto (Values) in its entirety:

Arie van Bennekum

The essences of the Agile Manifesto are further explained below:

Individual and interactions over Processes and tools

Working software over Comprehensive documentation

PMP Exam, PMI-ACP, ITIL Certification Best Resources

gets minimally marketable features (MMF) delivered at very short duration

Customer collaboration over Contract negotiation

Responding to change over Following a plan

12 Agile Manifesto Principles

Provide Value to Customer

PMP Exam, PMI-ACP, ITIL Certification Best Resources

competitive advantage to emerging opportunities

Deliver Great Products

PMP Exam, PMI-ACP, ITIL Certification Best Resources

traditional project management would accelerate near deadline

Quest for Better

Conclusion: PMI-ACP Exam Study Notes Agile Manifesto

PMP Exam, PMI-ACP, ITIL Certification Best Resources

PMI-ACP Study Notes: Agile Fundamentals

PMP Exam, PMI-ACP, ITIL Certification Best Resources

PMI-ACP Study Notes: Agile Project Management vs