Course Transcript [Link]

Agile Principles and Methodologies

Agile projects use short work iterations and incremental development of products that focus on
business priorities and customer value.

In this course, you'll learn about Agile concepts that are fundamental when managing projects,
including the four Agile values and twelve Agile principles. This course also covers the �ve phases of
the Agile project management model, and introduces you to the most common Agile methodologies
and frameworks. Finally, this course introduces key activities for managing Agile projects, including
creating a product vision and project charter, and best contract and documentation types.

This course is one of a series in the Skillsoft learning path that covers the objectives for the PMI
Agile Certi�ed Practitioner (PMI-ACP)® exam. PMI-ACP is a registered mark of the Project
Management Institute, Inc.

Table of Contents
1. Video: Agile Principles and Methodologies (bs_apj13_a01_enus_11)
2. Video: Understanding Agile (bs_apj13_a01_enus_01)
3. Video: Agile Values and Principles (bs_apj13_a01_enus_02)
4. Video: Agile Project Management Model (bs_apj13_a01_enus_03)
5. Video: Agile Methodologies (bs_apj13_a01_enus_04)
6. Video: Scrum Framework (bs_apj13_a01_enus_05)
7. Video: Adopting an Agile Approach (bs_apj13_a01_enus_06)
8. Video: Initiating an Agile Project (bs_apj13_a01_enus_07)
9. Video: Creating Vision and Charting a Project (bs_apj13_a01_enus_08)
10. Video: Agile Contracts (bs_apj13_a01_enus_09)
11. Video: Agile Documentation (bs_apj13_a01_enus_10)
12. Knowledge Check: Key Agile Concepts
Course HTML Resources

1. Video: Agile Principles and Methodologies (bs_apj13_a01_enus_11)

O b j e c t i ve s

• No Objective Provided

1 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

[Course title: Agile Principles and Methodologies. The presenter is Barbara Waters, PMI-ACP.]
Agile Projects are characterized by the use of short work iterations and incremental product
development. In this course, you'll learn about the core values and principles outlined by the
Agile Manifesto. You'll also learn about some of the more common Agile methods and
practices, how to create an Agile product roadmap, and the unique aspects of Agile contracts
and documentation.

2. Video: Understanding Agile (bs_apj13_a01_enus_01)

O b j e c t i ve s

• identify characteristics of the Agile method

[Topic title: Understanding Agile.] While there are countless ways you can manage a project,
most common project management methodologies fall into one of two model types. Either a
de�ned and linear process model, or more of an empirical and iterative process model.

In a de�ned and linear process model, there's a very linear approach planned for the project
work. And work gets carried out following that plan through distinct and complete project
phases. You complete one phase of a project, then move on to the next phase, each phase needs
to be completed before moving to the next.

In an empirical and iterative model on the other hand, you use actual and empirical data
gathered as project work is performed, working in iterations, building on what's been done, and
introducing or changing elements as you go. Sometimes performing work in cycles to create the
end result. [A diagram of Empirical and Iterative Model displays. Based on empirical data
gathered, or requirements, a project is built. Building a project includes the following three
stages: Design and Development, Testing, and Implementation.]

Agile Project Management is considered an incremental model for project management. So,
instead of project work being completed in a linear model with one �nal delivery phase, your
project work is divided up into increments. And each increment of project work goes through
requirements, design, development, and then testing and delivery, before moving on to the next
piece of project work. So you're taking it one piece at a time and delivering each piece.

Agile Project Management is additionally considered an iterative model. So not only are you
building the pieces of your �nal product incrementally over time, you're also iterating. [An
example depicting multiple iterations displays. Iteration 0 is Project Setup Plan, Iteration 1 is
Plan, Develop, and Test Feedback, which is repeated as needed, and Iteration n is Develop and
Test Release Product.] Meaning in the �rst increment, you might initially build the minimum
features that are required for your product, such as login functionality. [An example showing
login functionality displays. It has a username text box, a password text box, and a Sign in
button.] Then once you've tested that functionality, in the next increment of work you may
build more robustness into that feature. [A Forgot Password button is added to the login
functionality.] So you're incrementally adding different features to your end product, and

2 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

adding robustness to your features with each iteration.

With Agile being iterative and incremental, the focus is on delivering the highest value items
�rst. So if you're starting with highest value items �rst, then you know that you've at least
tackled the things that are the most important to your stakeholders.

Another characteristic of Agile Project Management, is that you identify issues much earlier.
Because testing is ongoing with each iteration rather than just in one testing phase at the end
of the project life cycle, issues are realized much earlier in the development process. Feedback
is also obtained early and often because at the end of each iteration, you're getting feedback
from the project stakeholders. And then incorporating that feedback into the next iteration.
Once that feedback has been received, and since you haven't moved too far ahead in the
project work, it's a lot easier to make changes as well.

In summary, the Agile Project Management approach is incremental and iterative. Other
characteristics of Agile are that it helps focus on the highest value requirements �rst. Issues get
identi�ed earlier in the project life cycle. Stakeholder feedback is received earlier and often.
And changes are easier to implement.

3. Video: Agile Values and Principles (bs_apj13_a01_enus_02)

In 2001, a group of independent software practitioners came together and authored an Agile
Manifesto in response to the need for a development methodology that was driven by the
features and end product, rather than traditional project management methods. In this video,
you’ll explore the primary values and secondary values of Agile, and how to distinguish between
them.

O b j e c t i ve s

• distinguish between primary and secondary Agile values

[Topic title: Agile Values and Principles.] So where does Agile come from, and what is it based
on? Well, in February of 2001, a group of 17 independent software practitioners came together
and authored what is called the Agile Manifesto.

The Agile Manifesto was born out of a need for a software development methodology that was
driven by the features and end product, rather than being driven by traditional project
management methods that focused more on the project management process itself, and less on
the �nal product. The Agile Manifesto is comprised of 4 values and 12 principles.

The Agile Manifesto contains four values, which are further broken down into two sets,
primary values and secondary values. [The four Primary values are: Individuals and
interactions, Working software, Customer collaboration, and Responding to change. The four
Secondary values are: Processes and tools, Comprehensive documentation, Contract
negotiation, and Following a plan.] Essentially, all of the values contribute to the success of your

3 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

project, but the primary values are the values that contribute most to successful projects, and
are valued over the secondary values.

So the �rst Agile value says that we value individuals and interactions over processes and tools.
Sometimes in our corporate environments or in team environments, we value certain
processes and working with certain tools more than we value the individuals and interactions
that create success. What that means is if we have a tool, for example, that we're using that
costs us a lot of overhead, we should be thinking twice about using that tool. We should be
thinking more about, how do we foster more communication? How do we foster more
collaboration? And if there is a process that ultimately seems wasteful and doesn't really create
a lot of optimization and people being creative or doing their best work, then we should rethink
that process and focus more on having individuals interact in ways that bring out the best ideas.

The second Agile value says that we value working software over comprehensive
documentation. What this means is working software really should be our measure of progress.
The ability to start a project and quickly prototype something, or come up with something that
works, is a lot more valuable than working for weeks and weeks, and in some cases, months, on
documenting everything very comprehensively, especially for software development projects,
since there's a lot of change to the �nal product across the life of the project.

The third value is that we value customer collaboration over contract negotiation. So if you've
worked in an environment where you have a de�ned project plan, it sometimes becomes a big
pain to actually have your stakeholders request a change. That change becomes a big contract
negotiation. A change request goes in, and then you have to identify whether the change is
worth it. In an Agile environment, it's understood that change is constant. Change is going to
happen. And so the focus should be on collaboration with the customer to make sure that we
understand the impact of the change, the need for the change, and the value that comes out of
the change, instead of trying to negotiate whether or not to make changes.

The fourth and �nal Agile value is that we value responding to change over following a plan.
This one is pretty self-explanatory. We need to be able to respond to change and have a system
that allows us to do so dynamically, versus following a linear de�ned plan, where we try to
de�ne everything upfront, which is typically going to change over the course and lifetime of a
project anyway, particularly in a software development project.

In addition to the four Agile values outlined in the Agile Manifesto, there are 12 principles.
These principles should drive all work on your project. The �rst six principles are satisfy the
customer, welcome change, deliver software frequently, work together, motivate individuals,
and use face-to-face communication.

It is important to satisfy the customer. The highest priority is to satisfy the customer through
early and continuous delivery of valuable software. It's also essential to welcome change, even
late in development. Agile processes harness changes for the customer's competitive
advantage. It's also important to deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter time-scale. And working together is
vital. Businesspeople and developers must work together daily throughout the project.
Motivating individuals is also key to your project's success. It's important to build projects
around motivated individuals. Give them the environment and support they need, and trust
them to get the job done. And face-to-face communication is the most ef�cient and effective
method of conveying information to and within a development team, particularly when time
scales and development require the quick transfer of information.

The remaining six principles are that working software equals progress, constant pace,
technical excellence, simplicity, self-organizing teams, and re�ection. This means that working
functionalities in the product are your signs of progress along the project timeline, not the
succession of project phases in a spreadsheet. Constant pace is also needed. Agile processes
promote sustainable development. The sponsors, development team, and users should be able
to maintain a constant pace inde�nitely. In addition, continuous attention to technical

4 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

excellence and good design enhances agility. Simplicity is key. Keeping it simple is an art.
Sometimes we tend to think that the more features we build or the more complexity we build
into our features, the better, when actually, the best products are the simplest ones that have
all the features and function the customer wants, but remain uncomplicated. In addition, the
best architectures, requirements, and designs emerge from self-organizing teams. And �nally,
the principle of re�ection brings success, and carries it through future work. At regular
intervals, the team should re�ect on how to become more effective, then tunes and adjusts
working behaviors and procedures accordingly.

In summary, the Agile Manifesto outlines four values that should be kept in mind for project
management. The values are, value individuals and interactions over processes and tools. Value
working software over comprehensive documentation. Value customer collaboration over
contract negotiation. And value responding to change over following a plan.

The Agile Manifesto also outlines 12 principles that should guide your project. They are, satisfy
the customer, welcome change, deliver software frequently, work together, motivate
individuals, use face-to-face communication, working software equals progress, constant pace,
technical excellence, simplicity, self-organizing teams, and re�ection.

4. Video: Agile Project Management Model (bs_apj13_a01_enus_03)

Learn how to identify the �ve phases of the agile project management model.

O b j e c t i ve s

• identify the �ve phases of the Agile project management model

[Topic title: Agile Project Management Model.] While the Agile manifesto values individuals
and interactions over processes and tools, and working software over getting caught up and
focusing on comprehensive documentation, there is still a recognized value in a model outline
for successful Agile project management.

Jim Highsmith, one of the authors of the Agile manifesto, developed the Agile project
management model. The model consists of �ve phases, and it's worth noting that these �ve
phases do not have a linear progression, but rather they are cyclical in nature. Agile is really a
cycle and a set of iterations or loops where we're doing a lot of different activities within each
cycle, rather than working through a prescribed path with distinct step.

The �rst phase of the Agile project management model is the envisioning phase. During this
phase, you envision what this product is going to be, what type of value you should be
delivering to your end customers, and what the vision is for the overall project or product.

The second phase is the speculating phase. In the speculating phase, you start thinking about
how to implement different features or functionality that will actually ful�ll that vision that you
created in the envisioning phase.

5 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

Next is the exploring phase. In the exploring phase, you're performing iterations of learning.
This is the phase in which you're developing code, you're developing software, you're testing it,
you're getting feedback on it, and you're �guring out the way to ful�ll that vision.

The next phase is the adapting phase. In Agile, in every cycle, and in every iteration, there is
adaptation. As you learn, you adapt and change the plan. You might change your idea of what is
higher priority. You can even be changing the way you work in order to optimize and come out
with the best ideas, as well as a really effective strategy for working together as a team.

And �nally, the last phase is the closing phase. Because the Agile project management model is
iterative, that could mean closing a speci�c iteration, or the whole project. [An example
depicting multiple iterations displays. Iteration 0 is Project Setup Plan, Iteration 1 is Plan,
Develop, and Test Feedback, which is repeated as needed, and Iteration n is Develop and Test
Release Product.]

In summary, the �ve phases of the Agile project management model are, envisioning,
speculating, exploring, adapting, and closing.

5. Video: Agile Methodologies (bs_apj13_a01_enus_04)

In this video, you will learn how to identify some of the methodologies that can be used for Agile
project management.

O b j e c t i ve s

• identify some of the methodologies that can be used for Agile project management

[Topic title: Agile Methodologies.] There are what seems like countless methodologies that you
can use for managing your Agile project. You're speci�c project type will help determine
whether an Agile methodology is suitable and which methodology should be used. You need to
consider both criticality and safety and security requirements. You can implement an Agile
model rigidly with no deviations, partially tailoring it to speci�c needs and in combination with
another methodology as a hybrid model. Regardless of what you select, there are a number of
common ones that you should be aware of and consider for your Agile project.

The �rst is the extreme programming, or XP methodology. XP is one of the �rst frameworks
that could be considered Agile. [The iterations involved in Extreme Programming methodology
are: Release Plan, Iteration Plan, Acceptance Test, Stand-up Meeting, Pair Negotiation, Unit
Test, and Pair Programming.] XP is a software engineering centric model and was developed by
a number of software engineers who wanted to improve the way they worked together as
teams, the way they worked with their stakeholders and the quality of the end product that
they were building. XP focuses on the ongoing rapid delivery of software through quick, short
releases with a recommended one week iteration. Each iteration results in production ready
code.

6 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

Lean principles and tools are another approach to Agile project management. Lean principles
and tools don't prescribe speci�c development methods, but instead provide guidelines for
streamlining the development process. [The various Lean Principles are: Identify Value, Map
the Value Stream, Create Flow, Establish Pull, and Seek Perfection.] The guidelines are driven
by seven key principles to accomplish this, eliminate waste, build quality in, create knowledge,
defer commitment, deliver fast, respect people, and optimize the whole.

Kanban, another Agile framework, is derived from Lean principles and tools. Kanban principles
include visualizing a work�ow, limiting work in progress or WIP, focusing on the work�ow and
continuous improvement.

Crystal Methodologies are a family of Agile methodologies named after the colors of crystals of
different hardness. [A sample diagram of Crystal Methodologies displays.] The Crystal
Methodology you should apply depends on the complexity or hardness of a speci�c software
development project. As the size and criticality of the project increases, a methodology with
more prescribed steps and artifacts is required to keep control of the development process.

Feature-driven Development, or FDD, provides a client-centric, architecture-centric and

pragmatic software development process. All aspects of the software development process are
planned, managed, and tracked at the level of individual software features. Five main activities
in FDD are develop an overall model, build a features list, plan by feature, design by feature and
build by feature.

The Dynamic Systems Development Method, or DSDM is another framework for Agile
development. It re�ects a business perspective rather than a technical one and has three
phases, pre-project activities, project activities, and post-project activities. DSDM requires a
large number of artifacts and designates a large number of roles, but has �exibility in the way
activities are incorporated. [A diagram depicting Dynamic Systems Development Method
displays. In the Pre-project phase, the initiation of the project takes place. Feasibility is a short
phase to assess the viability and the outline business case. Foundation is a key phase for
ensuring the project is understood and de�ned well enough so that the scope can be baselined
at a high-level and the technology components and standards agreed, before the development
activity begins. Exploration is an iterative development phase during which teams expand on
the high-level requirements to demonstrate the functionality. Engineering is an iterative
development phase where the solution is engineered to be deployable for release. In the
Incremental Deployment phase, for each increment of the project the solution is made
available. The Post-project phase assesses the accrued bene�ts.]

Model-driven Development, or MDD, requires extensive models prior to production. The Agile
version of MDD, or AMDD involves creating incremental models just to add suf�ciently
detailed support throughout the project life cycle. A team can begin by developing a high-level
model of the project requirements, and then develop more low level models for each iteration
requirement. AMDD principles include assuming simplicity, modeling with a purpose, valuing
content above representation, creating quality work, communicating openly and traveling light.

Disciplined Agile delivery, or DAD, is a process decision framework that is a people �rst,
learning-oriented hybrid Agile model. It has a risk value delivery cycle and it is goal-oriented,
enterprise-aware and scalable. DAD is not prescriptive. Rather, DAD provides the guidelines
for �tting together appropriate strategies and approaches for a successful outcome.

Test-driven Development, or TDD is a design technique that emphasizes unit testing with tests
written before code. TDD components include test cases, test �xtures, test suites and test
harnesses. TDD is useful for speci�cation and validation rather than overall system design. [A
�owchart depicting Test-driven Development displays. The idea is that before adding a
functionality, you write an automated test about how this new functionality that you want to
introduce to your system (new code) has to behave. You then run the test and you wait for it to
fail. You then again update the functional code to the speci�cation, you write the simplest code,
for it to pass. You run the test again and you make sure that this time it passes. At the end you

7 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

have to refactor (even the simplest code has undesirable properties) and make sure that you
have a clean code.]

And �nally, Behavior-driven Development, or BDD is often iterative and aims to improve a
team's ability to deliver prioritized, veri�able business value using a shared language known as
ubiquitous language.

In summary, there are numerous Agile methodologies you can use for your project. Some of the
most common ones include, Extreme Programming or XP, Lean Principles and Tools, Kanban,
Crystal Methodologies, Feature-driven Development, or FDD. Dynamic Systems Development
Method, or DSDM, Agile Model-driven Development, or AMDD, Disciplined Agile Delivery, or
DAD, Test-driven Development, or TDD, and Behavior-driven Development, or BDD.

6. Video: Scrum Framework (bs_apj13_a01_enus_05)

During this video, you will learn how to recognize the four Scrum inspect and adapt events.

O b j e c t i ve s

• recognize the four Scrum inspect and adapt events

[Topic title: Scrum Framework.] As a lightweight framework for Agile project management, we
say that Scrum is a framework versus a methodology since Scrum does not prescribe how to
implement certain things such as reporting, source control, or even code. Scrum utilizes an
iterative, incremental approach which allows for predictability and better risk management. So,
Scrum is centered around iterations or sprints that are typically anywhere between one to four
weeks in length. Most commonly these days, many teams are implementing a two-week sprint
length.

Each sprint or iteration development period has a clear goal consisting of an agreed set of work
items to implement during that iteration. So before starting any sprint, the team gets together
and agrees on what work items they will complete within the course of a sprint. And at the end
of each sprint, the goal is to have some kind of product increment that can be inspected and
adapted, gaining feedback from stakeholders.

Each successive sprint then builds on the last. And planning occurs in between the sprints. So,
although we do have a general high-level plan for the overall release, sprints also allow us to
inspect and adapt and potentially change the plan for the next upcoming sprint based on
feedback or based on something we've learned during the course of a sprint.

Inspecting and adapting are central to the success of Scrum. And Scrum includes four events
that provide opportunities to inspect and adapt. These are sprint planning, daily Scrum, sprint
review, and sprint retrospective.

The sprint planning meeting is the initial meeting where the team will commit to a set of
deliverables for the sprint. The sprint planning meeting is an opportunity to inspect and adapt

8 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

because at this meeting, the product owner is able to provide the team with some feedback
based on either the last sprint or based on things that have changed since the last sprint. It's an
opportunity to potentially reorder or reprioritize the requirements backlog.

The daily Scrum is another opportunity to inspect and adapt as a team. Everyday there's a
Scrum meeting, also known as a daily stand up. Typically 15 minutes maximum in which team
members discuss what they've done, what they are going to work on and any roadblocks or
impediments to their work. Each team member answers three main questions. What work have
I completed since the last Scrum and why? What do I plan on completing between now and the
next Scrum? And do I have any roadblocks or problems that the team can help me overcome?
On many occasions, the why part of the �rst question is skipped since everybody should know
why they've worked on speci�c items. Those items typically line up with sprint goal and have
been agreed on at the beginning of the sprint. However, in the case that something has delayed
or changed priorities, it's good to make sure that everybody understands why priorities
changed with work items and what challenges are being experienced?

The sprint review, which happens at the end of a sprint, allows the team to review and demo
the product of their work to their stakeholders and to the product owner. It's also another
opportunity to inspect their deliverables, to inspect what they've been working on, and adapt if
necessary.

And lastly, the sprint retrospective is the fourth event that provides opportunities to inspect
and adapt. The sprint retrospective is a meeting in which the team can get together and talk
about what went well, what didn't go well, and what action items they can take in order to
improve as a team.

In summary, the primary goal of the Scrum framework is to have opportunities to inspect and
adapt as work progresses in your Agile project. The four Scrum events that provide
opportunities for this are, sprint planning, the daily Scrum, the sprint review and the sprint
retrospective.

7. Video: Adopting an Agile Approach (bs_apj13_a01_enus_06)

Discover how to identify the �ve steps required to transition to Agile.

O b j e c t i ve s

• identify the �ve ADAPT steps required to transition to Agile

[Topic title: Adopting an Agile Approach.] When considering the adoption of an Agile approach,
there are some factors to consider. The organizational structure, the project type, a customer's
role, and the team composition all in�uence how Agile can be adopted. It's also important to
consider how an organization approaches change. An organization that focuses on controlling
change to minimize potential disruption may struggle with Agile methodology. If the focus is on
welcoming change, an Agile methodology will be easier to support.

9 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

Regardless of the individual factors within your organization, the ADAPT steps developed by
Mike Cohn identify �ve necessary requirements for successfully transitioning to Agile. These
�ve steps are create awareness, increase desire to support change, develop ability, promote
successes, and transfer the Agile mindset throughout the organization.

The �rst step of the ADAPT process is awareness. Your organization needs to be aware of the
problems that it has currently. What are some of the process issues that are occurring? What
are some of the inef�ciencies? What are some of the issues that we want to improve upon?
Also, awareness around how Agile methodologies can help us achieve those goals or �x those
issues is key knowledge to have.

The second step is desire. There de�nitely needs to be a desire from the organization, or from
enough people in the organization, to make the change and to make the shift towards Agile
methodologies.

Ability is the next step. The actual ability for an organization to support an Agile approach is
vital. In some cases, organizations may not have the ability to change because of certain
factors. There might not be enough co-location of teams, or the engineering structure may not
allow for things like test-driven development or unit testing. It could also come down to an
organization just not currently having people with the right skill sets to adopt Agile.

Next, after deciding whether you have the ability to actually move to an Agile methodology, you
want to start promoting it. This includes promoting Agile across the organization, not just
speci�c to your project. And it also includes talking about the bene�ts that you expect to gain.

And the �fth and �nal step is transfer. This is the step where you �nally make the transition and
start implementing Agile methodologies or frameworks in your organization.

Moving to Agile is de�nitely not an easy thing to do. It includes change and requires successful
change management. It includes a lot of understanding of why you're moving, and why you're
trying to change the way that you've done things. It involves cooperation with governance,
constraint and feedback, and organization and learning. However, the bene�ts for
organizations that have moved to Agile have been very clearly measured, and show a lot of
improvement in areas that people and organizations care about.

In summary, the ADAPT steps are required when transitioning to an Agile approach. The steps
include awareness, desire, ability, promote, and transfer.

8. Video: Initiating an Agile Project (bs_apj13_a01_enus_07)

In this video, you will learn how to identify the recommended components of a business case.

O b j e c t i ve s

• identify the recommended components of a business case

10 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

[Topic title: Initiating an Agile Project.] When initiating any project, it's a good idea to �rst make
sure that you understand the opportunity and whether it makes sense for your business to
pursue that opportunity. So the key activity for initiating an Agile project is establishing a
business case or business justi�cation.

The purpose of having a business case is multifold. A business case helps ensure that everyone
understands what they are trying to achieve. By establishing a business case for the end
product, it becomes very clear across the organization from executives to managers, to
marketing, to sales, to the development team, what the goal is for developing this product or
working on this project.

The business case also helps simplify decision-making by setting clear objectives and
parameters. By understanding those parameters, you can also start to create a framework for
making decisions around the product. A business case also helps keep the project team focused
on meeting the customer's overall objectives for a project. By de�ning the value that the
customer sees or that the customer is seeking, it becomes a lot easier for the team to focus on
those things, versus perhaps features or functionality that the team considers as valuable.

Finally, the business case provides the key criteria for judging the success of a project.

So what exactly is included in a business case? Recommended components of a business case

include an opportunity, goals, strategy, project vision, milestones, investment, and expected
payback. Some components of a business case can include an opportunity. So an opportunity is
a chance to create value or meet a business need. For example, in a hypothetical project, the
stated opportunity might be to update the website with the company's revised corporate
image, to improve functionality, and bring it in line with industry standards.

Another component in a business case are the goals which provide the reason why a project
should be implemented. They also inspire a team and they need to be speci�c, measurable,
attainable, and realistic.

Strategy is another component that should be included in a business case. Strategy is the plan
that will help the customer achieve the speci�ed goals.

The project vision, which speci�es what the customer hopes a project will have achieved once
it's completed, should also be included in the business case. The project vision also helps an
Agile team understand the purpose of the project.

Milestones, which identify signi�cant points in the development and shipping of a project or
product, should be in your business case. Milestones help focus the team and make it easier to
track progress.

The investment speci�es what a customer will need to invest in a project based on each
milestone.

And �nally, the expected payback is included. The expected payback identi�es both the
�nancial bene�t or return on investment that a customer can hope to gain from a project. As
well as what the payback is for the company as a result of the project.

In summary, there are seven different components that should be identi�ed in a business case
when you are initiating an Agile project. They include opportunity, goals, strategy, project
vision, milestones, investment, and the expected payback for both the customer and the
organization.

9. Video: Creating Vision and Charting a Project (bs_apj13_a01_enus_08)

11 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

During this video, you will learn how to recognize the elements of a project charter.

O b j e c t i ve s

• recognize the elements of a project charter

[Topic title: Creating Vision and Charting a Project.] Any project requires directions to steer the
team toward success. Creating the product vision and developing the project charter are two
key activities that help guide the project team to a accomplishing the goals of your Agile
project.

The product vision is a compelling statement about why you're building a product, the bene�t
the product brings, who you're building it for and why you are uniquely positioned to develop it.
A product vision also describes how a project can capitalize on the opportunities and ful�ll the
goals of the business case. A product vision should provide all the stakeholders, including the
development team, with a common understanding of what's required, without limiting that
team's creativity in �nding solutions.

An important part of creating a product's vision is to interview the people who are
stakeholders of the product about their vision for the product. The interview should focus on
establishing minimum and maximum requirements for the product and investigate the
relationship between the project's potential risks and bene�ts. The vision statement doesn't
just describe a product's features, it focuses on how a product will add value. It should motivate
the development team and help them envision the �nal product.

Project charters are great way to ensure that the intentions, outcomes and priorities are clear
to both the stakeholders and the team. It's a good way to try to establish alignment on key
elements of a project, especially early on. A project charter can contain many elements. But one
of the most common ones is the vision statement, which de�nes the why of the project. This is
the purpose, or the reason, why this project exists. The objectives or mission are the what of
the project, and these state what will be done in the project to achieve the vision. It should also
identify who the customer is and what problem is going to be �xed with the end product.

The success conditions, or success criteria, are a set of outcomes or results that de�ne success
of the project for management or stakeholders. A charter can also contain priorities and
compromises. It's a good idea to understand what a stakeholder will and will not accept as a
compromise before starting out on a project. And it's also important to know what risks the
project has. As well as to think about the acceptable workarounds. Risks and mitigation
strategies should be included in the project charter. Team roles should also be included. Who
will be doing what should be documented, along with a high-level overview of what each
person is responsible and accountable for.

The most important thing to note about a project charter in an Agile environment is that it's a
one page document. It needs to include these high-level essential items that talk about what
creates success for a project. But it shouldn't go on and on for many, many pages.

In summary, a project charter should be no more than a page long. But should still include the

12 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

following elements. A vision statement, objectives or a mission of the project, customer,

problem, success conditions or criteria, priorities and compromises, risks and mitigation and
team roles.

1 0 . V i d e o : A g i l e C o n t ra c t s ( b s _ a p j 1 3 _ a 0 1 _ e n u s _ 0 9 )

In this video, �nd out how to identify the contract types suitable for Agile projects.

O b j e c t i ve s

• identify the contract types suitable for Agile projects

[Topic title: Agile Contracts.] Contracts help organizations manage their risks and resources. In
traditionally managed projects, the most commonly used contract is a �xed-price contract.

Fixed-price contracts aren't generally the best for Agile projects, as they assume a �xed scope.
They also place risk on the team implementing the project. Because if the work ends up
exceeding the estimate or if requirements change, which they frequently do, the team has to
bear that loss and still continue with the promised scope. Fixed-price contracts may also take
focus away from what's best for the product and customer. And instead, developers become
bound by legal limitations that are no longer in the customer's best interest.

In theory, a possible solution is for a contract to specify the overall business goals that a project
team must enable a customer to meet. Instead of specifying detailed technical requirements.
However, this isn't always practical. Because in terms of legal requirements, business goals
need to be de�ned in monetary terms, which can be dif�cult.

So what types of contracts are suitable for Agile projects? You can use different contract types
for each of the Agile development phases. So for example, in the initiation phase, you may use a
service contract. Instead of measuring a speci�c deliverable like product development, a
service contract may measure the time, cost, and materials spent on coming up with for
example, a roadmap or a story map within that project.

The next phase, or the development phase, may be a series of �xed-price contracts for each
iteration. Some variants on the �xed-price contract include �xed-range contracts and �xed-
price per user story.

Cost-reimbursable or time-and-materials contracts operate on a pay-as-you-use basis. So it's in

the client's hands to decide whether or not to pay the team to spend more time or more
resources on developing additional requirements, making changes or enhancements, or �xing
issues.

A not-to-exceed with �xed-fee contract can protect both the development team and the
customer. It's made up of a �xed-fee base as well as a not-to-exceed condition. So it may be, for
example, that our �xed-fee base for this project is x dollars and then the not-to-exceed
condition is we will not exceed 15% of that base.

13 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

An incentive contract can also be used and can motivate a development team by offering
rewards for good performance. The types of incentive contracts include, �xed price with
incentive, cost-reimbursable with award fee, percentage increase or decrease based on time,
and a �xed price user story with additional hourly rate.

In summary, while regular �xed-price contracts are not suitable for Agile projects, many other
types of contracts are. They include service contracts for the series of �xed-price contracts,
cost-reimbursable or time-and-materials contracts, not-to-exceed with �xed-fee contracts, and
incentive contracts.

11. Video: Agile Documentation (bs_apj13_a01_enus_10)

Learn how to identify helpful types of documentation for Agile projects.

O b j e c t i ve s

• identify helpful types of documentation for Agile projects

[Topic title: Agile Documentation.] One of the key principles of the Agile Manifesto is to
emphasize Working Software over Comprehensive Documentation. So that means we prefer
having Working Software be our primary measure of progress versus Comprehensive
Documents. Agile approaches focus on keeping documentation light or having just enough
documentation to help you move forward and make progress. Most agile teams use speci�c
forms of documentation. And they favor those that are simple and highly visual.

So for example, a Project Backlog Iteration, Sprint Backlog User Story Cards, and Burnup and
Burndown Charts are very common documentation forms used in Agile teams. All of these are
very simple to use and are highly visual, and it's shown that visual communication is a lot more
effective than communication via pages of text.

Sometimes people feel that documentation is required for every process in every project.
Reasons might be that it's needed for Managing risk, Following a process, Information sharing
or Detailing requirements. These are not valid reasons for generating comprehensive
documentation, and can actually hinder, rather than help in Agile project success.

In an Agile environment, you manage risk better by focusing on delivering the highest value
items �rst, versus by creating very comprehensive documents. And you can still follow a very
speci�c and very effective process without having comprehensive documentation. In addition,
sharing information among teams can happen in collaborative environments where people are
talking verbally and communicating without the need for documents. And from an Agile
perspective, thoroughly detailing requirements early in a project is wasteful. It's too soon at
that point for customers to know what they really want at a detailed level. So requirements are
likely to change.

We know that early on in a project is the point where we know the least that we are ever going

14 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

to know about that project. That's the worst point in the project life cycle to try and create very
detailed comprehensive documents about what's required.

With all of that being said, there are of course valid types of documentation that are quite
useful and contribute to the success of an Agile project. For example, the Vision Statement
de�nes the ultimate goals of a project and the why. Why we're building this project.

A Project Overview summarizes critical information about a project such as the Vision,
Technologies used, and Operating processes. It should be just a few pages long.

Requirements Documentation, of course, are helpful, even essential to have. Product

requirements may be documented in many different forms, including for example the Product
Backlog.

Acceptance Testing Documents are also helpful. Acceptance criteria is used by testers to
determine whether the requirement has been met. Acceptance Testing Documents specify
those acceptance criteria, and they help tell developers whether their work is complete, and
whether it meets expectations of stakeholders.

Support Documentation is designed for those who will become responsible for supporting a
project and a product once it's released. It may include Problem Escalation Procedures, a list of
Important Contacts, and a Troubleshooting Guide.

User Documentation may include Training Manuals, User Manuals and Quick Reference Cards.
It's designed to equip users to use a product and to �nd answers to their questions about it
without having to call support staff.

So in Agile environments, there are still documents that are generated. However, the focus is
on creating really effective communication, not documenting what doesn't need to be
documented. And not spending too much time documenting things that you know will change
later on in the project.

In summary, helpful documentation to create for an Agile project includes the Vision
Statement, the Project Overview, Requirements Documentation, Acceptance Testing
Documents, Support Documentation, and User Documentation.

1 2 . K n o w l e d g e C h e c k : Ke y A g i l e C o n c e p t s
Agile projects use short work iterations and incremental development of products that focus on
business priorities and customer value.

In this course, you'll learn about Agile concepts that are fundamental when managing projects,
including the four Agile values and twelve Agile principles. This course also covers the �ve phases
of the Agile project management model, and introduces you to the most common Agile
methodologies and frameworks. Finally, this course introduces key activities for managing Agile
projects, including creating a product vision and project charter, and best contract and
documentation types.

This course is one of a series in the Skillsoft learning path that covers the objectives for the PMI
Agile Certi�ed Practitioner (PMI-ACP)® exam. PMI-ACP is a registered mark of the Project
Management Institute, Inc.

O b j e c t i ve s

• identify characteristics of the Agile method

• distinguish between primary and secondary Agile values
• identify the �ve phases of the Agile project management model

15 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

• identify some of the methodologies that can be used for Agile project management
• recognize the four Scrum inspect and adapt events
• identify the �ve ADAPT steps required to transition to Agile
• identify the recommended components of a business case
• recognize the elements of a project charter
• identify the contract types suitable for Agile projects
• identify helpful types of documentation for Agile projects

Question 1: Multiple Choice

W h a t a r e � v e c h a ra c t e r i s t i c s o f t h e A g i l e m e t h o d ?

Options:

1. Agile is iterative

2. Agile focuses on highest-value items �rst

3. Agile identi�es issues earlier, and changes are easier to implement

4. Agile allows for feedback to be obtained early and often

5. Agile is non-repetitive

6. Agile focuses on the easiest requirements �rst

7. Agile is incremental

Answer

1. Agile is iterative

2. Agile focuses on highest-value items �rst

3. Agile identi�es issues earlier, and changes are easier to implement

4. Agile allows for feedback to be obtained early and often

7. Agile is incremental

Feedback:

Option 1: That option is correct. The Agile methodology is iterative and processes and
phases may be repeated as necessary for each deliverable as required.

Option 2: This option is correct. Agile best practice is to focus on the highest-value
requirements �rst to ensure they are completed and developed as required
for the project.

16 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

Option 3: This option is correct. In Agile projects, issues tend to surface early in the
process, making it easier to address them as required.

Option 4: This option is correct. A key characteristic of the Agile method is constant
feedback as project work is completed, allowing for any necessary tweaks
to be implemented so the �nal product meets requirements.

Option 5: This option is incorrect. In an Agile environment, project work and phases
may be repeated as many times as necessary to ensure the project meets
requirements.

Option 6: This option in incorrect. In an Agile project, the highest-value requirements

are addressed �rst, rather than on requirements that might be fastest to
complete.

Option 7: That option is correct. Agile is incremental in nature, meaning work done in
one phase is built upon in the next.

Question 2: Multiple Choice

What are the four primary values identi�ed in the Agile Manifesto?

Options:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

5. Planning over �exibility

6. Master processes over individual interactions

Answer

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Feedback:

17 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

Option 1: This option is correct. One Agile value is to value individuals and
interactions over processes and tools. Sometimes we mistakenly value
certain mechanisms more than the individuals and interactions that create
success when we should be thinking more about fostering greater
communication.

Option 2: This option is correct. Working software should be the measure of progress.
The ability to start a project and quickly prototype something, or come up
with something that works, is more valuable than working farther forward
and documenting everything comprehensively.

Option 3: This option is correct. In an Agile environment, it's understood that change
is constant. So, the focus should be on collaboration with the customer to
make sure that you understand the impact of the change, the need for the
change, and the value that comes out of the change, instead of trying to
negotiate whether or not to make changes.

Option 4: This option is correct. You need to be able to respond to change and have a
system that allows you to do so dynamically versus following a linear
de�ned plan where you try to de�ne everything upfront. Things are
typically going to change over the course of a project.

Option 5: This option is incorrect. In fact, the opposite is true. The strength of the
Agile method is the ability to be �exible and adapt to changing needs and
circumstances as they arise.

Option 6: This option is incorrect. The Agile method values the individual and
interactions over processes and tools. If a process is ultimately hindering
creativity and innovation, it must be rethought or replaced.

Question 3: Multiple Choice

W h a t a r e t h e � ve p h a s e s o f t h e A g i l e p r o j e c t m a n a g e m e n t m o d e l ?

Options:

1. Exploring

2. Adapting

3. Closing

4. Monitoring

5. Planning

18 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

6. Speculating

7. Envisioning

Answer

1. Exploring

2. Adapting

3. Closing

6. Speculating

7. Envisioning

Feedback:

Option 1: This option is correct. Exploring is the third phase of the Agile project
management model.

Option 2: This option is correct. Adapting is the fourth phase of the Agile project
management model.

Option 3: This option is correct. Closing is the �fth and �nal phase of the Agile project
management model.

Option 4: This is an incorrect option. Monitoring is not one of the phases of the Agile
project management model, which includes envisioning, speculating,
exploring, adapting, and closing.

Option 5: This option is incorrect. Planning in any project is important, but it is not
one of the �ve phases of the Agile project management model, which
includes envisioning, speculating, exploring, adapting, and closing.

Option 6: This is a correct option. Speculating is the second phase of the Agile project
management model.

Option 7: This option is correct. Envisioning is the �rst phase of the Agile project
management model.

Question 4: Multiple Choice

Documentation is a secondary priority for Agile projects, but still valuable. What are
t h e � v e t y p e s o f d o c u m e n t a t i o n b e s t s u i t e d f o r A g i l e e nv i r o n m e n t s ?

Options:

19 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

1. Support and user documentation

2. Acceptance testing documents

3. Requirements documentation

4. Detailed timeline plans

5. Historical performance data

6. Project overview

7. Vision statement

Answer

1. Support and user documentation

2. Acceptance testing documents

3. Requirements documentation

6. Project overview

7. Vision statement

Feedback:

Option 1: This is a correct option. Documents that help and support project work are
important so work can be completed ef�ciently.

Option 2: This is a correct option. It's important to document how project deliverables
will be measured, and how they will be tested, to ensure the project meets
the expected outcomes.

Option 3: This option is correct. Requirements documentation is necessary so project

work focuses on what the �nal product should look like, how it will work,
and what it will do.

Option 4: This is an incorrect option. Having a project timeline is important, but in an

Agile environment, highly-detailed timeline plans are considered a
hindrance rather than an effective aid.

Option 5: This option is incorrect. Agile projects focus on completing tasks that
contribute to the �nal project deliverable and addressing issues as they are
identi�ed, rather than documenting past results.

Option 6: This is a correct option. While highly-detailed documentation is not useful

in an Agile environment, having an effective project overview helps focus
project work and priorities.

Option 7: This option is correct. The vision statement is a valuable type of

20 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

documentation as it guides the project work and outlines what the project
is trying to achieve.

Course HTML Resources

• Glossary: Agile Principles and Methodologies

The third ADAPT step, where the actual ability for an organization to
support an Agile approach is assessed. Factors that can impede change
Ability
include issues with collocation of teams, engineering structure, or just not
currently having people with the right skillsets to adopt Agile.
The �ve necessary requirements for successfully transitioning to Agile:
ADAPT steps
Awareness, Desire, Ability, Promote, and Transfer.
Phase 4 of the Agile project management model, where changes or
modi�cations to the plan take place as a result of what was learned in
adapting
earlier phases. Changes may include reordering priorities or altering
methodology to optimize teamwork.
Agile project
A �ve phase model that is cyclical, rather than linear. The phases are
management
envisioning, speculating, exploring, adapting, and closing.
model
The �rst ADAPT step, where an organization seeks to become aware of its
Awareness problems or goals and how Agile methodologies can help to achieve goals
or �x issues.
Phase 5 of the Agile project management model, where a speci�c iteration,
closing
or the whole project, ends.
An opportunity to inspect and adapt as a team via a daily stand-up meeting,
typically 15 minutes maximum, in which team members discuss what
daily scrum
they've done, what they are going to work on, and any roadblocks or
impediments to their work.
The second ADAPT step, where there is clear determination from the
Desire organization, or from enough people in the organization, to make a change
and shift toward Agile methodologies.
Phase 1 of the Agile project management model, where initial
envisioning consideration is given to determine the project or product, business value,
and vision for the overall project or produc
Phase 3 of the Agile project management model, where iterations of
exploring learning take place as a product is developed, tested, reviewed, and
reworked in order to ful�ll the vision created in the envisioning phase
The fourth ADAPT step, where a concerted effort is made to advocate for
Promote Agile across the organization, including the bene�ts that the organization
can expect to gain.
A lightweight framework for Agile project management that utilizes an
iterative, incremental approach which allows for predictability and better
scrum
risk management. It consists of four events: sprint planning, daily scrum,
sprint review, and sprint retrospective.
Phase 2 of the Agile project management model, where creative thinking
speculating starts with regard to how to implement different features or functionality
in order to ful�ll the vision created in the envisioning phase.

21 of 22 10/7/2024, 2:26 PM
Course Transcript [Link]

A meeting in which the team commits to a set of deliverables for the sprint.
The product owner provides the team with feedback, which allows the
sprint planning
opportunity to potentially reorder or reprioritize the requirements
backlog.
A meeting in which the team assembles to discuss what went well, what
sprint
didn't go well, and what action items they can take in order to improve as a
retrospective
team.
A meeting held at the end of a sprint that allows the team to review and
sprint review demo the product of their work to their stakeholders and to the product
owner.
The �fth ADAPT step, where the transition is made to begin implementing
Transfer
Agile methodologies or frameworks in the organization.

© 2023 Skillsoft Ireland Limited - All rights reserved.

22 of 22 10/7/2024, 2:26 PM