Deep Dive into the Project Scope (2021 Update)

Keeping your project focused, on time, and on budget means keeping a close eye on project
scope. Project management requires understanding project requirements and the project
lifecycle.
In this course, you'll learn about planning and management of the project scope from
traditional and Agile project management perspectives. You'll explore how the product scope,
vision, and minimum viable product (MVP) play into the planning process. Finally, you'll
learn different methods and tools for scope planning.
Table of Contents
1. Deep Dive into the Project Scope (2021 Update)
2. Shared Product Vision
3. Traditional Approach to Requirements Gathering
4. Traditional Approach to Planning the Scope
5. Traditional Scope Baseline
6. Scope and the Agile Mindset
7. Minimum Viable Product
8. Agile Approach to Prioritizing Requirements
9. Agile and Evolution of Scope
10.Scope Validation
Deep Dive into the Project Scope (2021 Update)
[Video description begins] Topic title: Deep Dive into the Project Scope (2021
Update). Your host for the session is Barb Waters, MBA, PMP. [Video description
ends]

When managing a project, defining and controlling the scope is critical. The way a
project team defines the scope can vary greatly depending on whether they are
using a traditional approach, an Agile approach or a hybrid of the two. In this
course, we'll discuss creating a shared vision for the project and any deliverables.

Next, we'll discuss the traditional approach to requirements gathering and

planning the scope. From there, we'll address scope in the Agile mindset,
including defining the minimum viable product, the Agile approach to prioritizing
requirements, how the scope evolves in an Agile project, and finally, scope
validation. Within the process domain, we will focus on the task, plan and manage
scope.

The enablers include: determine and prioritize requirements, break down scope
and monitor and validate scope. This is a thorough list of the various tools that a
project manager can use to plan and manage the scope, as well as the
deliverables that may be created during the process. Throughout this course, we
will highlight some of these key tools and deliverables, particularly those which
are more complex or require memorization.
Shared Product Vision
[Video description begins] Topic title: Shared Product Vision. Your host for the
session is Barbara Waters. [Video description ends]

One of the key objectives when defining the scope of your project is to ensure
that everyone has the same expectations. Since we have no way of reading each
other's minds, we have to make sure that there is as much transparency as
possible and that everyone has the same idea when it comes to the scope of the
project. This can be particularly challenging in traditional project management,
where the product is delivered once at the end of the project. So if you can
imagine that every single stakeholder has their own thought bubble, our goal is to
make sure that the thought bubbles all match.

I enjoy sharing this particular cartoon with my classes because I think it does a
great job of showing how completely differently we may all think about the same
deliverable. [Video description begins] The cartoon shows a tree swing in 12
different ways: how the customer explained it, how the project leader understood
it, how the analyst designed it, how the programmer wrote it, what the beta
testers received, how the business consultant described it, how the project was
documented, what operations installed, how the costumer was billed, how it was
supported, what marketing advertised, and what the costomer really
needed. [Video description ends]

As we gather requirements for our project deliverables, we're trying to determine

what the project should be like. We collect requirements usually from our key
stakeholders to give us a good understanding of the customer needs.

Requirements gathering will allow us to start to paint a picture of the features

and functionality that the product must have. Of course, when you ask key
stakeholders what they would like to see in the final product, you're going to
receive many different answers. When you first collect requirements, you'll end
up with a list of functionality and features that is unrealistically large. You
wouldn't be able to develop everything that everyone wants. The result would
likely cost too much and take too much time. And also some of the features are
likely to conflict with one another.
For example, have you ever noticed how different our preferences are for the
screen size on our phones? Some people like their phone screen to be extremely
large, while others prefer a phone that's small enough to fit in their back pocket.
If we're only developing one choice of phone, we'll have to decide which screen
size suits most of our stakeholders. This means narrowing down to a final set of
requirements. It's not easy to do and we know that we won't be able to please all
of the stakeholders, but it is necessary to define a realistic scope for the project.
There are three categories of requirements: business, functional and
nonfunctional.

The business requirements include big picture business goals and benefits in
terms of profit or metrics. The functional requirements include how it works. For
example, if you push this button, this will happen and the nonfunctional
requirements include the characteristics such as appearance. For example, the
power button will be green. As long as we provide as much detail as possible
about the final deliverable, at least we can be certain that everyone understands
what the deliverable will be like. We'll have achieved transparency for the scope
of the project and there will be a shared vision by all stakeholders.
Traditional Approach to Requirements Gathering
[Video description begins] Topic title: Traditional Approach to Requirements
Gathering. [Video description ends]

Next, we're going to review some common tools and techniques that are used in
traditional projects in order to collect requirements from stakeholders. Meetings
are a great way to interact with your stakeholders and get an understanding of
their needs. Meetings may be in person or virtual, and two types of meetings are
focus groups and facilitated workshops. Keep in mind that you may not have this
personal level of interaction with every stakeholder on your project. You'll analyze
your stakeholders to determine what level of interest and impact they may have
on the project.

Stakeholders with a high level of interest and impact will likely be the ones that
you would invite to these meetings. A focus group is an interactive discussion
where you ask stakeholders "What are your expectations or concerns for this
project?" We'll also ask "What specific requirements do you feel need to be
included or excluded?" Generally, the opinion of our customer, who is the one
paying for the project, will help to drive this discussion. However, it is important
to listen to everyone, including stakeholders who may be against the project.
Why? Because a stakeholder who is against the project could potentially work
against the project team or introduce risk.

For example, let's say that you're proposing a new affordable housing
development into a community. The existing property owners may say "We don't
want additional housing here. The added population will cause extra traffic. And
what about that land you're thinking of using? Clearing it will be bad for the
environment." We do need to listen to all stakeholders and give them a voice.
Eventually the project team will need to make decisions and some of the
decisions will be very difficult. But all stakeholders opinions should be welcome.
Facilitated workshops are a bit different than focus groups because they generally
result in an output.

A facilitated workshop consists of cross-functional team members that represent

different skill sets and backgrounds. They may work together to identify
requirements for the deliverable. A facilitated workshop could involve decision
making, ranking requirements to determine which features and functionality are
most important, or any other type of output. So the participants in a facilitated
workshop have somewhat of an assignment. Questionnaires and surveys are
another great way to gather responses to questions and reach a large number of
stakeholders at once. You may not have the opportunity to meet with every
stakeholder in a meeting or a personal setting, but you may still want to learn
their opinions.

Once you've distributed the questionnaires and surveys and collected the
responses, you can analyze the data to gain meaningful information. You may
want to consider leaving at least one open ended question to allow your
respondents to include free form responses, so that if they want to share a
comment, they can. There can be a lot of value in stakeholder feedback, and you
may learn something about a topic you didn't even think to ask about.

When selecting requirements for the scope of your project, one technique you
might consider using is multi-criteria decision analysis. This type of analysis
evaluates each feature based on multiple criteria. [Video description begins] A
table displays. The columns are Requirement, Difficulty, Cost, Resources, Risk,
Value, Skill Level and Total score. Each requirement has ratings in each
columns. [Video description ends]

Both stakeholders and the project team can contribute to this model. Ratings may
be based on the value of having a feature, the risk of not having it, the cost of the
feature and the resources or skill sets necessary to implement the feature. A
weighted formula may be used in order to give some criteria more importance in
the final priority score. This is a technique that uses selection criteria to make
decisions about ranking requirements or the features and functionality for the
product. The requirements are entered into a table, you then evaluate and score
each one based on the established selection criteria. In this example,
requirements X and Y are the top two requirements that should be developed for
this project.

Reaching consensus is necessary for a project team to commit and move forward
with product development. This is where group decision making comes in handy,
and the project manager will often facilitate a decision making session. Four ways
to reach a group decision include unanimity, majority, plurality and dictatorship.
Unanimity means that a decision is reached whereby everyone agrees on a single
course of action. This can be quite a challenge, especially with larger groups. With
majority, a decision is reached with the support obtained from more than 50% of
the members of the group.

Plurality means that a decision is reached whereby the largest block in a group
decides. Even if a majority is not achieved, perhaps the team has to choose the
best option out of five choices, the votes are split and the highest block of votes
for one of the choices is 35%. With plurality, that ends up being the best option
for the group.

And finally, dictatorship may guide the decision making. In this method, one
individual makes the decision for the group. This may not sound ideal or even fair,
but at times dictatorship is the best approach for making a decision. For instance,
let's say that the team is deciding on a feature to store customer credit card
information on file. A member of the organization's risk management team may
decide on behalf of the group that this particular feature carries too much risk,
and the organization has already decided that storing credit card information on
file isn't something they're willing to do. In that case, the decision is already made
for the team.

Once requirements are collected, the project team will create requirements
documentation. Requirements documentation quantifies and prioritizes the
needs, wants and expectations, and it includes how each requirement satisfies a
business need.
For example, for a new drug development, the requirements might be 'use three
dimensional animations in training' or 'implement updated Food and Drug
Administration regulations'. Detailed project requirements could include the level
of service, performance, safety and compliance, reporting, quality, acceptance
criteria and assumptions and constraints. Requirements documentation includes
all the details about the requirements that you recorded during the meetings with
stakeholders, details like the rationale behind why they were prioritized like they
were, and all the agreed upon attributes for each requirement. This gives a
baseline you can use to monitor and control a project throughout its lifecycle.

The level of detail in the requirements documentation will differ for different
projects, but the documentation should do four things. It should organize the
requirements by stakeholder and priority, it should describe what objectives the
requirements meet, it should classify the requirements by type, and it should
identify assumptions and constraints.
Traditional Approach to Planning the Scope
[Video description begins] Topic title: Traditional Approach to Planning the Scope.
Your host for the session is Barbara Waters. [Video description ends] Value
engineering and value analysis are used to identify the best value in product
design and development. This can include seeking alternative designs and
materials in order to cut costs while increasing efficiency or quality. We'll start
with a focus on value engineering. Value engineering analyzes each feature of a
design and determines the value that the feature delivers and whether that
feature can be delivered more efficiently or at a lower cost. It asks the questions:
what can be optimized? Including processes, technology or using more
experienced resources. What can be eliminated? Including unnecessary steps and
features. And finally, what can be substituted? This can be in terms of materials or
vendors.

And it should be understood that value engineering does not seek to reduce
quality unless the added quality did not result in greater perceived value. Let's
explore a case study. In 2017, Microsoft released a major redesign of Skype that
included a feature called Highlights. With Highlights, Skype users could decorate
their photos with emojis and text that would automatically disappear after 7 days.
After about a year, Skype determined that Highlights isn't something that would
resonate with the majority of users, because it overcomplicated things. At least
that's what the company wrote in a blog post. They also said "We need to take a
step back and simplify." When Skype first introduced the Highlights feature, they
did so because they had reason to believe it would add value for the user, in this
case through new functionality. Once the product was released, the ongoing
value analysis revealed that this feature did not contribute to value. Value
analysis can also be used to reveal changing customer demands, a changing
marketplace or other environmental factors that can affect value. These can even
include changes within the organization itself.

For instance, let's take the example of a large tech company and the benefits
package that this organization has offered its employees over the years. Many
years ago, the company may have offered a pension to employees who plan to
spend their entire career with the company. Over time, the company noticed that
the pension plan was quite a burden to administer, and it came with many rules
and regulations. Not only that, the market was changing. Employees don't tend to
stay with one employer for their entire career. So with a little value analysis, the
company decided to reevaluate the benefits plan, cut the features that no longer
added value and introduce new benefits that did. Although the concepts are quite
similar, value engineering is generally used when designing a new product or
process for the first time. While value analysis focuses on continuous
improvement of a product or process while it's already in use.

The purpose of both value engineering and value analysis is to eliminate or reduce
costs that don't add to the value of the product or service. Although this approach
began in manufacturing in the 1940s, it has applications in any industry. When
defining the scope for your project, you'll create a detailed list of the
requirements for the deliverable. Exactly which features and functionality will be
included in the final deliverable make up the scope of your project. What you may
not have thought about though is listing the exclusions. Why would we do that?
And in reality, wouldn't this list be infinite? What is the purpose of listing the
excluded requirements for your project? Here's an example where you might
consider listing an exclusion. Your project team is creating a training video for
new hires of a restaurant chain.

The included requirements will be the scripting of the video, the actors and
actresses, the studio, video production and more. However, there's one thing you
prefer that your customer would supply, and that is the uniforms to be worn by
the participants in the video. Since your client has a readily available supply of
restaurant uniforms, it makes sense to use them. But what if you didn't list this as
an exclusion for what you would include in the scope? It could end up being a
source of confusion or disagreement between you and your customer.

So when we talk about listing the excluded requirements, that is not intended to
be an endless list of everything you won't do or won't create. It's really just to
define any features or functionality that won't be included in order to make sure
there's an agreement before you begin to perform project work. Another benefit
of defining the boundary for the project scope is to protect the project from
scope creep. Any uncontrolled increase to the scope can result in increases to the
project budget and schedule. So a well-defined project scope can help to control
spending and deliver on time. Some changes seem so minor that we may be
tempted to include them without going through a structure change control
process.

But over time they may add up and either contribute to scope creep or a
confusing scope, or some requirements may seem to disagree with others. In
project management, an assumption is a factor in the planning process that is
considered to be true, real or certain, without actual proof or demonstration. We
have to make certain assumptions during planning in order to be able to move
forward in the project. For example, we may need to assume that the price of raw
materials will remain steady, that vendors will follow through on commitments,
or that resources will remain available. Inaccurate assumptions contribute to risk,
so the project team may want to keep an assumptions log. This can help remind
the team to monitor assumptions regularly and make updates as they prove to be
correct or incorrect.
Traditional Scope Baseline
[Video description begins] Topic title: Traditional Scope Baseline. Your host for the
session is Barbara Waters. [Video description ends]

A project scope statement in traditional project management is a detailed

description, often in paragraph form, that includes the following information: the
project objective, the project description, acceptance criteria, key deliverables,
scope exclusions, time and cost estimates, project constraints and project
assumptions. When defining the project scope, it helps to decompose the work
from the project level all the way down to the smallest increment of work called
the work package.

The resulting structure is known as the work breakdown structure, or WBS. [Video
description begins] A WBS graph displays, with the Project name on top, levels
such as Phase, Deliverable and Sub-deliverable underneath, and the Work
package in the lowest level. [Video description ends]

A WBS can be tailored as you and your project team see fit. Through the levels of
the WBS, you can arrange the work chronologically into phases, by each
department performing the work, or even by components of the final deliverable.
The way you arrange it is completely up to you. One thing that always remains
consistent, though, is that the project name is at the top and the smallest level
known as the work package is in the bottom row. One helpful rule that you can
follow is called the 8/80 or 4/40 rule. This basically states that the work package
should be between 8 and 80 hours worth of work if the work is performed by one
full time employee.

For organizations on a biweekly payroll, this helps to ensure that the work is small
enough to fit into one pay period. This can be modified to a 4/40 rule for weekly
payrolls. Control accounts may be built into a WBS for accounting purposes. This
helps to monitor spending and cost performance across the project and to
identify at a local level where there may be overspending or issues with cost
control. Without control accounts, it can be difficult to identify the source of
overspending. So this is a great measure that you and your project team can
implement to make sure you are adhering to the budget or quickly identifying
problems or issues.

You may have noticed that the WBS leaves only enough space for the title of a
work package or component - there isn't much room to elaborate. That's where
the WBS Dictionary comes in handy. The WBS Dictionary is a reference document
that accompanies the WBS. It includes detailed information about each work
package. Your team can tailor this document as you see fit, but examples of what
it might include could be the corresponding control account, the assignment of
the work, and approvals.

Although it may sound like a singular item, the scope baseline consists of three
parts: the scope statement, the WBS and the WBS Dictionary. Once the scope
baseline is established, it will be used to make decisions about the project's
schedule and budget. In a traditional project, we define the project scope first.
Then, the project scope drives decisions around time and cost, also known as the
schedule and budget. It's possible that what we learn about the time and cost
may cause the project team to revisit the scope and make necessary adjustments.
But it is the scope that is well defined upfront and everything else follows.
Now we'll discuss rolling wave planning. What if you were taking a one week road
trip with some friends? Certain aspects of the trip will need to be decided ahead
of time. You've probably decided on the destination and maybe where you'll be
staying on certain nights of the trip. However, is it possible that you can begin
your road trip without necessarily knowing every detail and just allow the plan to
develop as you go?

For instance, can you start your trip without knowing exactly what you'll eat for
breakfast on day 3? This is known as rolling wave planning. With rolling wave
planning, you plan each task as it gets closer. This can also be called progressive
elaboration. You add more detail to the plan as additional project information
becomes available. And this allows the plan to evolve, but in a controlled way.
This is an iterative process so you can revisit the plan and adapt as you go.

This shouldn't be confused with scope creep, though. Just because you don't
know yet where you'll eat breakfast on day 3 doesn't mean that you're permitted
to go to a fancy restaurant that would exceed your budget. You must still use
proper budget and schedule management as you elaborate the scope. Rolling
wave planning, or progressive elaboration, means that the project plan is
continuously and constantly modified, detailed and improved. It helps us account
for changes in scope or requirements or even priorities. So as the project evolves,
we're actually able to manage better because we understand more detail about
the requirements, about the users and about how they're going to use our
product.
Scope and the Agile Mindset
[Video description begins] Topic title: Scope and the Agile Mindset. [Video
description ends]

We've already been introduced to the triple constraints of a project from a

traditional perspective, where the scope drives the cost and time on a project. In
Agile projects, this triangle is inverted or turned upside down. This means that we
start with a certain amount of money and a fixed amount of time and we
determine how much work can fit into this time box.

Agile teams often work by blocking a few weeks at a time and setting short term
goals that can be met just during the next iteration or sprint. In this type of
project, the scope is created incrementally with the highest priority items being
developed first. Then the product becomes more robust with each iteration of
work. The customer doesn't have to wait for the end of the project to have a "ta-
da" moment. They are able to see the product evolve and they can provide
regular feedback that will guide the development along the way. There are five
commonly recognized levels of planning.

Let's explore each level and how the details become more defined and specific.
This is also known as the level of abstraction. Let's start with the product vision.
This high-level concept is initially developed by the product owner, who serves as
the voice of the customer or key stakeholders. This is the highest level of planning
and the details are very coarse grained and subject to change and evolve. There's
no exact plan for how to go about creating the deliverable.

The next level of planning is the product roadmap. This starts as a story map with
the minimum viable product in line to be developed first, followed by other
features that can be added later in the order of their priority. Once the timing of
deliverables is added to the story map, it's called a product roadmap.

The third level of planning is known as release planning. With each release, the
product becomes more robust. Usually, releases are scheduled ahead of time
before the development team even knows what will be released. This helps the
team to establish a cadence of continual value delivery. During iteration planning,
a realistic number of user stories are pulled from the product backlog and
translated into specific development tasks. The development team estimates
these tasks and commits to completing them during the next sprint or iteration.
Then, during the sprint or iteration, every day counts.

What started as a high level product vision is now decomposed to specific tasks
and fine detail, and the development team is taking more of a microscopic
approach to the work.
Minimum Viable Product
[Video description begins] Topic title: Minimum Viable Product. Your host for the
session is Barbara Waters. [Video description ends]

Managing stakeholder expectations can be tricky in Agile projects. The scope is

constantly evolving, so the project team must work on establishing and
maintaining a shared vision. In this topic, we'll introduce some helpful tools and
techniques for establishing that shared vision. And then, in a later topic in this
course, we'll discuss the definition of done.

An elevator statement is a brief description of a product including its target

customer, the need it meets, the product's name and purpose and the benefits it
can have for the customer. This statement is referred to as an elevator statement
because it shouldn't take longer than a short elevator trip, or less than two
minutes, to explain. An elevator statement should include who the product is for,
what need or problem it solves, the product or service to be provided and its
unique features or benefits.

The statement may also include a differentiator, or what makes this product or
service better than a competitor's product or service. So it might read something
like this: For: a customer, Who: has a need or problem, Our: product or service,
Provides: certain unique features or benefits, As opposed to: the competitor
product, We: offer a differentiator.

Here's an example. For customers who need immediate answers to their

questions, our Clients Support Department includes 24/7 live coverage. Unlike the
average company's 24 hour email response, we are always here to take your call.
A product vision box is sample packaging that visually describes the product.

Stakeholders are divided into cross-functional groups of four to six individuals

who design a product vision box. For the front of the box, you can think of the
product name or relevant graphic, and bullet points summarizing the key benefits
that the product can provide. For the back of the box, you provide a detailed
product description and product requirements. Let's use the example of a video
streaming service. The front of the box says that our video streaming service is
called Click and View Movies on Demand. We include a relevant graphic and the
key benefits are that we carry the largest library of titles, we can suggest titles by
your user profile and you can pause your subscription if you'd like to.

A tweet is a technique that can be used to filter just the necessary requirements
for a product. In a tweet, stakeholders describe objectives using a limited number
of characters. The tweet must be 280 characters or less. This provides a high-level
understanding of the project without getting into too much detail, and it can also
be useful to help create the project charter.

If you've been keeping up with cell phone technology over the past several years,
you've probably noticed how the available features and functionality just keep
growing. What used to be a device for making phone calls has evolved to having a
personal assistant available to provide real-time answers and information as you
need it. When creating a new product, how do we know which features our
product must have? You can work with your customer and key stakeholders to
define the minimum viable product or minimum marketable features for your
product. A minimum viable product will be complete enough to be useful.

For instance, if we're providing GPS navigation on the cell phone, it must be able
to help us get from point A to point B. This minimum marketable feature must
also be small enough that it is not the entire project scope. So maybe in the future
the GPS navigation will include real-time traffic reporting or suggestions for
restaurants along your route. But these can be added later. By releasing the
minimum viable product early, we can collect rapid feedback and adapt and
incorporate changes. Also, additional functionality can be included with future
releases.
Agile Approach to Prioritizing Requirements
[Video description begins] Topic title: Agile Approach to Prioritizing Requirements.
Your host for the session is Barbara Waters. Relative prioritization and scope
changes. [Video description ends]

In Agile projects where the scope is developed incrementally, the features and
functionality of a product can be prioritized into a list called the product backlog.
If you happen to keep a to do list for yourself and you constantly re-prioritize it or
add new things to do as your needs and obligations change, you are maintaining a
backlog. In Agile projects, there's usually a product owner who is responsible for
this backlog. They work closely with the development team to estimate the effort
involved in developing the new features.

There are a number of tools available to prioritize features relative to one

another. Relative prioritization helps us to determine which features and
functionality are valued the most in the eyes of the stakeholders. Some popular
prioritization techniques include the MoSCoW method, Play money, the 100-point
method and Dot Voting, which is also known as multi-voting.

n Agile product development, all work should be included in this backlog,

including bug fixes and changes, and they are all prioritized together in one single
list. The MoSCoW method is a tool that's used to help a team prioritize its user
stories. It's a technique for helping to understand priorities and ensure that a
common understanding exists across the different team members. The MoSCoW
method is usually used by analysts and stakeholders when they're coming up with
user stories or requirements for a project. It can help to determine a clear set of
requirements and a clear priority for those requirements by categorizing each
user story or requirement. Once you establish which category each of the
requirements falls within, you can determine which requirements are important,
which aren't as important, and which can be excluded from the scope of your
project altogether.

The first category in MoSCoW is Must have, which is the minimum usable subset.
These are the requirements that must be included for us to move forward with
releasing anything. The next category is Should have, which are the requirements
that aren't critical but are still deemed important for the project. The third
category is Could have, which are the requirements that would be useful and
would add value to the project. And the final category is Won't have, which are
the requirements that are explicitly excluded from the scope of this project.
Sometimes we also think of these as the requirements we would like to have in
the future, but that we know for sure we will not have in this release.

The process for rating requirements using the MoSCoW method is that we assign
a priority letter of either M, S, C or W to all requirements in our project. Once
we've created a backlog, whether it's on a whiteboard or a wall or an Excel
spreadsheet, the project team works together taking a look at the priorities that
have been assigned to each of the requirements and identifying or discussing any
issues that may happen or may come up in discussion when they're looking at the
priorities.

With Play money, features are priced based on the amount of effort it will take
the development team to produce them. Participants use money to buy features.
The features with the most money are considered the priorities. Participants will
use the money to buy a feature. Features with the most money are considered
the highest priority, and feature prices may also be set based on story points,
hours of effort or complexity.

Another way to prioritize requirements in terms of the customer's perspective is

the 100-point method, which assigns every customer 100 points that they can
then distribute amongst the requirements for the project. Each stakeholder has
100 points to spend on the requirements. The points can be allocated in any way
and the requirements are then prioritized by points. So let's say we give one of
our stakeholders 100 points and say "Assign these to the requirements according
to which ones are most important to you." The stakeholder may give one of the
stories 50 points and then distribute the rest of their 50 points amongst five other
requirements, or two other requirements. This gives us a strong indication that
the requirement that was given 50 points is really the highest criticality or the
most important feature for that stakeholder.

What if you've tried play money or the 100-point method and there are no clear
winners? All of the choices seem to have an equal distribution. You may consider
trying Dot Voting, also known as multi-voting. With this method, each person can
vote for only 20% of the choices. For example, if you have 20 items that must be
prioritized, with Dot Voting each person only gets 4 votes. The results show which
features are valued by the most stakeholders.
Agile and Evolution of Scope
[Video description begins] Topic title: Agile and Evolution of Scope. Your host for
the session is Barbara Waters. Agile and increment delivery. A graph displays,
with time in the x-axis. The steps are: Starting the project, Planning, Carrying out
the work, Planning, Carrying out the work, Planning, Carrying out the work, and
Closing the project. The curve starts down and goes up in the carrying out the
work steps and down in the planning steps. [Video description ends]

You may recall that the Agile project management lifecycle is characterized by
iterations or repeating cycles of planning, execution and delivery. Each phase of
planning is brief and only includes enough information to proceed with a small
increment of work. At the end of each iteration, the project team can
demonstrate what they've been working on, collect feedback, adapt and do it
again. The flow from beginning to end is driven by the customer feedback, and
change is welcome throughout.

Story mapping, originally introduced by Jeff Patton, is a powerful visual way to

plan agile projects. Story maps are a way to organize and present information
similar to the concept of a road map. However, in story maps, we order the user's
activities and tasks as they interact with our system. Story maps depict users
activities over time or sequentially. User stories help us to really focus on the user
in our planning efforts. When we put them in the context of a story map, it also
helps us focus on business value, since that's what helps us determine priorities.
Story mapping has many benefits.
First, it helps with knowing what to build first. It also helps us to build using an
iterative approach. It helps us to consider things in terms of building release 1
based on what's most necessary and then release 2 what's necessary for this
iteration, and then release 3 and so forth. And the product becomes more robust
with each release. Story maps help us to visualize the scope of a project and also
plan these releases at a high-level. It also helps us to continue to prioritize the
products backlog as things may shift in between releases as we're implementing
or executing on the plan.

In story mapping, the horizontal axis shows a high-level overview of the system,
meaning if we were to read the cards at the very top, we'd have a high-level
understanding of what this system does. So, for example, the gold cards in the
pink row on this diagram may say something like: search for a class, register for
the class and submit payment. We can guess that this is probably some type of
software for an education provider. The backbone shows the user's perspective
and the activities that will be required sequentially to use the product. These
activities may be rearranged or new activities may be added.

The next horizontal row just below the backbone is called the walking skeleton.
It's considered the minimum viable version of the system that can provide value
to a user. Along the vertical axis of a story map, we start to get deeper into
additional scenarios, more sophisticated use cases and more robustness. As we go
further down this vertical axis, the functionality becomes less necessary, but we
may see these features or functionality in future releases.

So in summary, in Agile projects the product will evolve and become more robust
with each iteration or sprint. There is a product evolution: moving through the
levels of planning, prioritizing and decomposing the work until the product
features become specific enough to develop and deliver incrementally.
Scope Validation
[Video description begins] Topic title: Scope Validation. Your host for the session is
Barbara Waters. [Video description ends]

The Agile value proposition is based on four parts: visibility, adaptability, business
value and risk. In this illustration, we're able to determine that Agile has higher
visibility, higher adaptability, we gain business value earlier and we reduce risk
faster than we might in a traditional project. Let's explore each element of the
value proposition, starting with visibility. The development team is creating
deliverables every few weeks and deploying new features and functionality that
the stakeholders can use. This is how they demonstrate progress.

These rapid deployments are contrary to traditional project management

stakeholders might have to wait until the entire product is complete. The visibility
and transparency creates trust, and it helps to keep the stakeholders interested
and engaged throughout the project. Next, we'll review adaptability because work
is performed incrementally in Agile projects. The development team has an
opportunity to collect feedback and adapt between each sprint or iteration. The
team can also welcome change into the project, even late in development.

The next aspect of the Agile value proposition is how business value is delivered.
As opposed to traditional project management, where the value is delivered all at
once at the end of the project, Agile projects start to deliver value almost
immediately. This is due to the incremental delivery of features and functionality
every few weeks. And finally, risk. In traditional project management, risk and
uncertainty remains high until the deliverable is accepted by the customer at the
end of the project.

Agile projects provide an opportunity to gather information and reduce

uncertainty as soon as we start developing features and functionality. During
planning, the development team will need to discuss acceptance criteria and a
Definition of Done. This is so that everyone can agree when the product
increment meets the team shared vision. This becomes very important at the end
of each sprint or iteration.

At this time, the development team will determine if the increment of work
meets requirements and is considered done based on criteria established during
planning. The acceptance criteria should accompany a user story. A user story is a
feature or functionality described from the user's perspective that they would
want in order to fulfill a business need. The acceptance criteria helps the
development team to translate the user story into tasks.

Next, we'll discuss the Definition of Done. The Definition of Done helps to avoid
stalling at 95% because we need just one more thing before this is really done.
The Definition of Done is also known as "done done". We can use a separate
Definition of Done for each level of project work, from the high level vision all the
way down to the user story. A Definition of Done makes progress easier to assess,
and it helps to prevent disagreements and scope creep in the project. A Definition
of Done should not be based on opinions. It should be objective and based upon
set criteria.

The Definition of Done has a close relationship with quality. The definition of
quality is the degree to which a set of inherent characteristics of an object fulfills
requirements. So in order to ensure quality is met in the deliverable, we have to
start by planning it in. The Definition of Done should be developed through a
thoughtful conversation among all team members. This conversation should
happen during planning and it continues every day during the iteration or sprint,
especially if the team needs to clarify requirements. At the end of a sprint or
iteration, the team will use the Definition of Done to assess the quality of the
product increment.

Let's assess Acceptance Criteria versus the Definition of Done side by side to
determine how they are alike and where they differ. Acceptance Criteria and the
Definition of Done are alike in that they both are agreed to as a team, they're
updated as new learnings come to light, they're testable and they are clear and
concise. However, the Definition of Done and acceptance criteria are also
different in some important ways.

Let's contrast them. Acceptance Criteria is specific to a user story as told by the
customer. As long as the product meets user needs and delivers functionality, the
Acceptance Criteria is met. However, the development team knows that there are
many other elements of work that they must address behind the scenes in order
to responsibly create the product, whether the customer sees it or not.

The Definition of Done applies to all work, including the work that the customer
may not see or even know about. For instance, the images that are used in this
course are stored in a graphics library with key words so that they can be located
as needed for future courses. You may not see that from your point of view. The
Definition of Done also includes the team shared vision for the increment, and it
also includes nonfunctional and quality requirements in addition to the
functionality for users. For instance, each course contains specific learning
objectives that follow best practices for instructional design.