PROJECT PHASES IN AGILE

Concept
The first step in using the Agile approach is to determine the scope of the projects and
prioritize them. Begin by sitting down with your stakeholders and your team to discuss and
brainstorm business opportunities and estimate the cost and time for each project. You can
then identify what tasks are viable and worth the effort and prioritize your backlog of
projects by analyzing the backlog.

Inception
Once you have a clear idea of the scope of your project, then the second step will be
to determine the best way to finish it. What kind of people do you need on your team? What
are the customer’s initial requirements? Make a diagram to outline team roles and the work
that must be completed throughout each sprint.

Iteration
Once your initial plan is defined and accepted by the development team, you will
begin to work on the initial iteration.

The fundamental workflow in this phase is:

 Requirements – Confirm requirements based on the product backlog and stakeholder
feedback.
 Development – Design the product on the specifications.
 Testing – Perform QA tests to verify the functions and find any problems.
 Delivery – Produce a functional product.
 Feedback – Collect feedback from customers and stakeholders to determine the
specifications for the next version.

Release
After several repetitions, you’re ready to decide to release the final product. In the
release phase, you’ll perform final testing and quality control to discover any issues or
defects, address them, and complete the user manual before the release into production.

Production
Your product is now available to the world! The production phase indicates that your
product is now live. Ensure your team provides ongoing monitoring and support to ensure
that your system is in good working order and that users know how to use it.
Retirement
When your system has become outdated or needs replacement, it enters the retirement
phase. All end-of-life actions, such as contacting customers and transferring the system
release out of production, are included in this stage.

AGILE ESTIMATION:
What is Agile Estimation?

Agile estimation gauges the effort needed to achieve a prioritized task in the
product backlog. Usually measured concerning the time needed for task completion, this
effort leads to accurate sprint planning. Agile estimates are also made with reference to story
points– a number that enables evaluation of the difficulty of successful completion of a user
story successfully.

Principles of Agile Estimation

Some of the basic principles of Agile estimation techniques are as follows:

 They are collaborative: Involving everyone on the Agile development team is one of the
best practices because collaborative efforts lead to better estimates. Collaborative
techniques put an end to the blame game for an incorrect estimate.

 They are designed to be fast: Faster than any traditional techniques, Agile estimation is
not about predicting the future. Rather it recognizes that estimations are a non-value-
added activity and tries to minimize them.

 Use of relative units: Estimation is not in terms of dollars or days; instead, “points” or
qualitative labels are employed for estimating or comparing tasks.

Common Agile Estimation Techniques

 The number of tasks and items you have to estimate

 Your team size

 Presence of members - co-located / all-in-one office

 Available tools that would facilitate the process

 Working style and personalities of the team members

1. Three-point Estimate

When faced with inaccuracy problems due to commitment to a particular estimate before
any work began, the three-point estimate technique was introduced.

No matter if the same team is working on the same type of work, estimates can turn
unrealistic when you fall into the trap of thinking that because you have done well before,
you will be able to do it again.

Method: The three-point estimation technique requires the creation of three values and
finding their mean:

 Most likely estimate

 Optimistic estimate

 Pessimistic estimate

For example: For Activity A, the three values for the estimated time are as follows:

 Optimistic (o) = 4 hours

 Most likely (m) = 8 hours

 Pessimistic (p) = 16 hours

Calculating the mean will give us the estimated time:

E = (4 + 8 + 16 ) / 3

E = 28 / 3 = 9.3 hours

2. Planning Poker

One of the most commonly adopted Agile estimation techniques is planning poker.

Method: The team members vote for an estimate of an item using specially-numbered
playing cards. Anonymous voting takes place, and discussions are held regarding large
differences. The process is repeated until the entire team reaches a consensus about the
accurate estimation. The technique is suitable for estimating a relatively small number of
items (maximum 10) in a team of 5-8 people.
3. Dot Voting

Another simple, Agile estimation technique is ideal for a relatively small set of items. It
originates from decision-making and suits both small and large teams.

Method: Every participating member gets a small number of dot stickers to vote for the
individual items. More dots correspond to more effort and time requirements. On the other
hand, fewer dots indicate that the task is fairly straightforward and quick to achieve.

4. Random Distribution/ Ordering Protocol

The Relative Mass Valuation and the Challenge, Estimate, and Override methods are
variations of this technique.

Method: This technique sets items in order from low to high. The member participating in
the estimation process takes turns to either move an item up or down one spot, hold
discussions, or pass. The process gets completed once everyone passes on their turn.

5. T-shirt Sizes (Estimation units)

One of the simplest ways is to categorize items into t-shirt sizes: XS, S, M, L, and XL. It is
an informal technique that can be used with many items for a quick estimation.

Method: Extra Small (XS), Small (S), Medium (M), Large (L), and Extra Large (XL) act as
units for this Agile estimation technique. The sizes can be assigned numerical values
postestimation. The decisions are based on open and collaborative discussions. An
occasional vote can be made to break a stalemate.
6. Buckets

This technique is similar to planning poker but aims for consensus via discussion and
assigning values to every task.

Method: The facilitator begins by placing a task in the middle, and they continue to read and
add tasks into the buckets relative to the first one. Team members can divide tasks, bucket
them, and come back together for review. Discussions are held before finalizing the
estimates.

7. Large, Small, Uncertain

It is a fast and productive agile estimation technique like bucketing.

Method: There are only three possible values to assign. You begin by discussing and then
divide and conquer to add up tasks to the large, small, or uncertain groups.

8. Affinity Grouping

Method: The team members group similar items. In case of related tasks in scope and effort,
you must place them together to get a clear set of groups.

PLANNING GAME:

Definition of Planning Game:

A Planning Game is a planning meeting held in order to decide which items and user
stories to work on in the next iteration or release.

Use of Planning Games:

The planning game is attended by project, IT, business and maybe other stakeholders.
Those present (including the product owner) consider which user stories will deliver the
most value to the product or project, taking into account current estimates.
Benefits of the Planning Game:
 Improves communication between development team and stakeholders.
 Improves likelihood of delivering working software or products with
each release or iteration.
Agile Product Backlog
The agile product backlog in Scrum is a list of prioritized features. It contains a short
description of all the functionalities desired in the product. In usual scenario, items should be
broken down into user stories. Commonly, a Scrum team and its product owner write
everything that they can think for agile backlog prioritization.

Why Product Backlog is Important?

o The backlog is prepared to provide an estimate of each feature.
o It helps in the planning of the product's roadmap.
o It helps in the re-ranking the features of the product by adding more value to it.
o It assists in determining the priority of the product first. The team member works first
on the higher prioritize product.

Characteristics of Product Backlog

 Each product should have its own product backlog. It can be a set of large to very
large features.

 Multiple team members can work on a single product backlog.

 Ranking of product is based on the technical value, business value, risk management,
or strategic fitness.

 Highest priorities items are decomposed into smaller stories during release planning.
This is because they can be completed in future iterations.

Think of a product backlog as a wish list — not a to-do list.

Why?

When we think about the backlog as a wish list, we invite flexibility and change. In doing so, we enable
true agility and give the organization a power that’s necessary to win in the marketplace today: the
power to change its mind.

In this context, the purpose of the backlog can be reduced to three simple goals.

 Develop a common ground to align stakeholders and teams, so that teams implement
the most valuable user stories.
 Provide flexibility to adapt to new needs and realities.
 Improve the accuracy of product release forecasts by creating a common denominator
across many teams collaborating on one product.
SPRINT BACKLOG:
Sprint Backlog is a set of Product Backlog items selected for the current Sprint, plus
plans for delivering product increments for achieving Sprint goals.

The Scrum master or product owner, it’s your responsibility to create the sprint backlog
and distribute it to all project stakeholders. With the help of the product owner, you will
choose backlog items based on priority. Then, document each task’s needs in the form
of user stories. These are software features written from the perspective of the end user within
a workflow.
 The purpose of a sprint backlog:

The purpose of a sprint backlog is to define work items to tackle within the sprint. This
keeps information in one shared space in order to streamline communication and create one
central source of sprint information.

COMPONENT OF SPRINT BACKLOG

 User story: A user story is a software feature written from the perspective of the end user.
It’s an important piece to include in order to understand the effect each feature has on the
end user.
 Task name: While obvious enough, keep your backlog organized by starting each task with a
clear, action-oriented name. Ensure each task title starts with a verb—for example, “Design
new mobile component for web app” is more descriptive than “New mobile component.”
 This will help stakeholders quickly understand the backlog and deliverables that each team
member is working on.
 Task description: Along with an actionable name, include a brief description of each task.
This creates clarity around tasks so stakeholders are aware of upcoming steps.
 Task prioritization: Since there are a number of tasks in a given project, it’s important to
prioritize your most important objectives. This ensures you meet deadlines and your sprint
stays on track.
 Sprint burndown chart: A burndown chart is a graph that represents the work left to do
versus the time it takes to complete it. During a sprint, your team will use these charts to
estimate how long each iteration will take.
 Daily time allocation: In order to track your time estimates against the actual time on your
burndown chart, you need to track daily time allocations. Analyze how long each task takes
in minutes or hours. At the end of the week, total up your weekly time allocations for each
task to complete your burn down chart.

ITERATION PLANNING:

The purpose of iteration planning is for the team to complete the set of top-ranked
product backlog items. This commitment is time boxed based on the length of iteration and
team velocity.
Who is Involved?
 Scrum Master − The scrum master acts as a facilitator for the agile delivery team.
 Product Owner − The product owner deals with the detailed view of the product
backlog and their acceptance criteria.
 Agile Team − Agile delivery defines their tasks and sets the effort estimates required
to fulfil the commitment.

Prerequisites of Planning
 Items in product backlog are sized and have a relative story point assigned.
 Ranking has been given to portfolio items by the product owner.
 Acceptance criteria has been clearly stated for each portfolio item.

Velocity Calculation
An agile team calculates velocity based on past iterations. Velocity is an average
number of units required to finish user stories in an iteration. For example, if a team took 12,
14, 10 story points in each iteration for the last three iterations, the team can take 12 as
velocity for the next iteration.
Planned velocity tells the team how many user stories can be completed in the current
iteration. If the team quickly finishes the tasks assigned, then more user stories can be pulled
in. Otherwise, stories can be moved out too to the next iteration.
Task Capacity
The capacity of a team is derived from the following three facts −

 Number of ideal working hours in a day

 Available days of person in the iteration
 Percentage of time a member is exclusively available for the team.
Suppose a team has 5 members, committed to work full time (8 hours a day) on a project and
no one is on leave during an iteration, then the task capacity for a two-week iteration will be
−
5 × 8 × 10 = 400 hours

Planning Steps
 Product Owner describes the highest ranked item of product backlog.
 Team describes the tasks required to complete the item.
 Team members own the tasks.
 Team members estimate the time to finish each task.
 These steps are repeated for all the items in the iteration.
 USER STORY:
What is a User Story?

A user story is a requirement for any functionality or feature which is

written down in one or two lines and max up to 5 lines. A user story is usually the
simplest possible requirement and is about one and only one functionality (or one
feature).

The most commonly used standard format for a User Story creation is stated
below:

As a <user role/customer, I want to < goal to be accomplished> so that I can

<reason of the goal>.

EXAMPLE OF USER STORY:

 User Story 1:

As a user on social media, I want to be able to modify my profile information, So

that I can keep my expertise current.
By doing so, Users can easily alter their profile information to maintain their
knowledge and personal details on the platform, focusing on their motivation and
desired outcome.

 User Story 2:

As an online shopper, I want to limit search results by price to select items within
my budget.

This user story reflects online customers’ needs to specify a price range when
looking for items. This feature allows customers to filter search results by price,
improving the browsing experience by allowing them to exclude goods outside of
their specified price range.
 ACCEPTANCE TEST AND VERIFYING STORIES

 An acceptance test is used to verify whether or not the requirements

of a user story have been completed.

 Acceptance tests are often used in the testable part of the mnemonic
INVEST model.

 A user story is considered satisfied if the test is passed.

 Acceptance tests are evaluated based on a set of acceptance criteria.

 Acceptance criteria are simple specific conditions used to check if a

user story has been implemented correctly.

 Clear, straightforward language should be used in creating acceptance

tests.

Who will determine the acceptance criteria of a User Story?

Acceptance criteria are usually determined by the client’s specific needs.

How to turn acceptance criteria to acceptance test?

 We can turn an acceptance criterion into acceptance test by breaking

down it into few steps

 Then to verify the criterion we will go through each steps during

acceptance test
Example:

User set the acceptance criterion as “Payment can be made using a VISA
credit card.”

Now we further break down this criterion into few steps-

 Insert a VISA card into a chip reader

 Enter the VISA’s PIN number

 Confirm the payment was accepted

To verify the criterion we’ll go through these steps. Our test will be as
follows-

Here we written the test into GIVEN — WHEN — THEN format but to
test the format we have to execute above three steps i.e.-

 Insert a VISA card into a chip reader

 Enter the VISA’s PIN number

 Confirm the payment was accepted

When we confirm our acceptance test of a user story is passed?

 If all tests for a criterion is passed then the acceptance criterion is

passed
  If all tests for all acceptance criteria of a user story are passed then the
story is considered successfully tested.

Benefits of using Acceptance Test

 Allow development team to view requirements from users perspective

 Determine the functionality of the product (as requirement details are

not present in user story)

 As we write the step by step details of a test, so these details can help
outline developer tasks and how those might be finished.

 Helps to avoid epic user stories

 Excessive number of acceptance criteria of an user story suggests that

a user story should be broken up into smaller pieces

Who will create the Acceptance Test?

Acceptance tests should be developed by the client with help from the
software product manager and development team.
PROJECT VELOCITY:

Velocity in agile is an important metric that helps the team improve efficiency by
determining how much it can achieve over time. After every iteration, the team
adds up effort estimates associated with user stories that were completed.
In project management, this helps in determining how long it will take to complete
the project.
 PROJECT VELOCITY

What is velocity in Agile?

Velocity in agile is a measure of how much work an agile team can deliver on
average in a sprint.

It takes a view at measuring:

 How much work an agile team has delivered in the past sprints
 How long it took the team to get the work done

With this in mind, the agile team and its stakeholders can accurately estimate the
agile team’s capacity, i.e. how much work they can achieve in a specific duration,
i.e. in a sprint.

In essence, velocity in agile offers agile teams a way of calculating how fast
they’re getting work done, and as a result, how many sprints will be required to
get a project to a certain degree, and overall, create significant change.

Key factors to consider when measuring agile velocity for your projects

1. Sprint workload
How much work are we delivering in this iteration? Specifically, how
many backlog items, user stories are we moving from to-do to done within this
sprint?
2. Sprint length
How long is this sprint going to last for? How long do we have to deliver our
outlined workload? Is it feasible based on previous sprints?

3. Burndown chart
The burndown chart shows the action items the team has to execute, plotted
against the amount of time remaining in a sprint.

How to calculate velocity

Within each iteration, there are units of work called user stories. These can be broken
down further into metrics known as story points. For example, a relatively small user story
might require two story points, while a more complex one will take eight story points.

If you want to calculate your Agile velocity, your team will first need to complete a
number of sprints. Then you can add up the story points for every sprint. For example, let’s
say you achieve two story points in sprint one, five story points in sprint two, and eight story
points in sprint three. You would simply add them all together and divide by the number of
sprints to get your average Agile velocity.

In this example, the calculation for determining Agile velocity is:

(2 + 5 + 8) ÷ 3 = 15

Sprint Burndown Chart:

Burndown charts today have become more popular in providing stakeholders as well as the
team members the status whether a sprint goal is accomplished in an easy, understandable
way or not.
What is a sprint burndown chart?

Sprint burndown is a graphical representation of the estimated effort-hours remaining for a

given period of time during a Sprint. Plotting the total effort-hours remaining for each
incomplete task on a given day, on a graph, results in the sprint burndown chart which is
significant for communicating progress as shown below.

The horizontal axis of the sprint burndown chart represents the days within a sprint, whereas the vertical
axis represents the remaining estimated effort-hours. The chart should be updated every day to exhibit
the total estimated effort remaining across all the uncompleted tasks.

Who all are involved in sprint burndown chart?

The following individuals will be involved in Sprint burndown chart:

 Developers (the team)

 Product Owner and
 Scrum Master
The team is responsible for making the ‘work in progress’ transparent to the stakeholders. The Product

Owner decides whether the release plan needs to be updated or the project is on schedule. The Scrum

Master supports, coaches, and reminds individuals of the rules underlying Agile software development.

What does a sprint burndown chart depict?

Total estimate of te efforts in hours in a sprint:

 It is the calculation of total work in hours for User Stories and other work items which
the team is committed to.

Total amount of effort remaining in a sprint:

This is what sprint burndown chart depicts and this is why this graph got its name
which simply means “effort burndown chart”. Every day the team will burn down
some effort, so definitely no work effort remains on last day of the sprint.

Total number of working days in a sprint

The graph shows this because it is essential for a team to estimate and thoroughly
work on the committed work every day. In fact, this is nothing but your sprint
duration.

Ideal Effort

It is drawn by evaluating the accurate amount of effort remaining which needs to be

burnt down by the team in a sprint. This serves as a reference for a team and this is
why we see it as a very straight line from the top of Y-axis to X-axis.

Real Effort

Real effort line shows the effort remaining. This line varies from day to day and team
to team as it completely relies on the effort remaining every day. For instance, if more
items are added once the sprint started, this appears as an upward spike. Similarly, the
line comes down on finishing the tasks every day.
Benefits of using sprint burndown charts:

Perfect Planning and tracking:

The team updates the ‘estimated effort’ and ‘effort remaining’, and also performs task
breakdown using this burndown tool, which is the great advantage of using it.

Risk reduction:

This chart provides feedback on schedule and effort on a daily basis, thus reducing
risks and alerts the team instantly if anything goes wrong, instead of waiting until the
end.

Effective communication:

Sprint burndown chart provides visibility of the progress of a project each day. It can
be represented physically using a chart paper/whiteboard for better communication if
in case we are not able to access the online tool.

SPRINT PLANNING AND RETROSPECTIVE

A sprint retrospective is a way to bring scrum teams together and
plan the best ways to increase quality and effectiveness in regard to
people, interactions, processes, tools, and each person’s definition of
done
What is the purpose of a sprint retrospective?

The purpose of the sprint retrospective is a scrum time boxed meeting

that takes place after the sprint review and before sprint planning.
 Agenda.

While the agendas for sprint retrospective meetings can vary, they
generally cover these common steps:

 Setting the goal — Establish the objectives of the meeting up front, such as aiming to
improve daily Scrum stand-ups, enhance communication with stakeholders or product
owners, change operating rules, or something else.
 Gathering essential data — Draw on everyone’s experience and perspective to create a
shared body of information.
 Developing insights — From the amassed data, identify useful patterns and see the big
picture, always asking why things happened the way they did.
 Deciding on the next steps — Identify the issues and challenges the team will tackle,
and put in place a concrete plan of how to achieve success for each one.
 Closing the retrospective — Clarify and summarize the meeting, thank participants, and
consider how future retrospectives could be improved.

Questions to ask after a sprint retrospective:

 What went well in the sprint? Success in an iteration can be analyzed by looking at
what was done differently to achieve it; who contributed to it and how; and what skills,
training, or knowledge made a difference.
 What went wrong in the sprint? The point is not to penalize the team or individual
members but look at things that didn’t go according to plan, with a view of improving
performance in the future.
 What did we learn? What did the team learn in the sprint so that they can improve their
way of working?
 How should the next sprint play out? This will determine corrective actions to take in
the next sprint, preventing the same mistakes from occurring, and making successful
actions a repeatable outcome.
DAILY SCRUM:
What is a Daily Scrum?

Daily scrums are quick meetings held each day at the same time for members of the
product development team working on a particular sprint. The team collectively reviews the
progress made toward achieving the Sprint Goal.

Benefits of daily Scrum meetings

For Agile teams focused on cultivating supportive working environments, achieving
the sprint goal, and ensuring efficient collaboration, daily Scrum meetings are very
beneficial. When appropriately planned, daily Scrum meetings have the following benefits:

Daily Scrum meetings help sync team progress

Team members can share the progress they’ve made toward the sprint goal, what they’re
working on for the day, and get feedback on whether they are moving at a proper pace or
not. They can also gain a clear understanding of what other team members are working on,
ensuring clarity and visibility throughout the sprint.

Daily Scrum meetings promote teamwork

During the session, everyone shares their progress and addresses whatever issue may have
arisen. Scrum team members can help each other overcome challenges and employ Agile
values and principles.

Daily Scrum meetings can be a problem-solving platform

Run into an Agile impediment? Scrum teams can communicate their concerns or issues so
that other members can share possible solutions.

Daily Scrum meeting three questions and agenda

Every daily Scrum meeting revolves around three questions — also known as the daily
Scrum questions. The questions are simple but necessary for every session. The three Scrum
questions are:

 What did you do yesterday?

 What are you doing today?

 Is there any issue affecting the delivery of your tasks?

SCRUM ROLES:

The roles in Scrum are quite different from the traditional software methods.
Clearly defined roles and expectations help individuals perform their tasks efficiently. In
Scrum, there are three roles: Product Owner, Development Team, and Scrum Master.
Together these are known as the Scrum Team.

Scrum Master: Roles and Responsibilities

The Scrum Master helps the product group learn and apply Scrum to achieve business
value. The Scrum Master does whatever is in their power to help the Team, Product
Owner and organization be successful.
 A Scrum Master is a facilitator and Servant Leader who encourages and demands
self-organization from the development team.
 A Scrum Master enables close cooperation across all roles and functions, addresses
resource issue and disobedience of scrum practices.
 A Scrum Master protects the team from external and internal distractions.
 A Scrum Master removes impediments so the team can focus on the work at hand
and follow scrum practices.
 A Scrum Master is not typically a manager or lead, but he is an influential leader
and coach who does not do direct command and control.

Scrum Product Owner: Roles and Responsibilities

The Product Owner is responsible for maximizing return on investment (ROI) by

identifying product features, translating these into a prioritized list, deciding which should
be at the top of the list for the next Sprint, and continually re-prioritizing and refining the
list.
  A Product Owner owns the Product backlog and writes user stories and acceptance
criteria.

 A Product Owner is responsible for prioritizing the Product Backlog is prioritized

and decides the release date and the content.
 A Product Owner accepts or rejects product backlog item.
 A Product Owner has the power to cancel the Sprint, if he thinks the Sprint goal is
redundant.

Development team: Roles and Responsibilities

A Development Team is a collection of individuals working together to develop and
deliver the requested and committed product increments. It comprises of cross-functional
members who are capable of achieving the sprint goals.

 The Development Team is self-organizing, with a very high degree of autonomy

and accountability.
 The Development Team decides how many items to build in a Sprint, and how best
to accomplish that goal.
 The Development Team is a cross functional, small and self-organizing team which
owns the collective responsibility of developing, testing and releasing the Product
increment.
SCRUM CASE STUDY:

What is the Importance of Case Studies in Scrum?

Case studies play a crucial role in Scrum as they provide valuable real-world examples
and insights into the practical implementation of the framework.

 Learning from Experience: Scrum master case study examples offer an opportunity to
learn from the experiences of others who have already implemented Scrum. They
provide valuable insights into the challenges faced, solutions implemented, and the
overall journey of organizations in adopting Scrum.
 Practical Application: Scrum case study examples demonstrate how Scrum principles
and practices can be applied in real-world scenarios.
 Identify Challenges: Scrum case study examples can also help teams to identify
potential challenges and pitfalls that they may face when implementing Scrum. This
can help them to plan and develop strategies for addressing these challenges.

Scrum Methodology as Used by a Capstone Team

Below is a scrum master case study example that shows the effectiveness of forming a
scrum team:

Problem:

The capstone team faced the challenge of managing their project effectively and
maximizing their velocity. They needed to find a way to improve their project
management processes to increase productivity and ensure successful project completion.

How it was Solved:

The team decided to adopt the Scrum methodology to address their project
management challenges. They implemented specific process modifications and utilized
Scrum practices to improve their velocity. Some key solutions they implemented include:
 Scrum Framework: The team embraced the Scrum framework, which provided a
structured approach to project management. They defined roles (Scrum Master,
Product Owner, Development Team) and implemented Scrum ceremonies (Daily
Stand-ups, Sprint Planning, Sprint Review, Retrospective) to facilitate effective
communication and collaboration.

 Asynchronous Daily Meetings: Instead of traditional synchronous daily stand-up

meetings, the team conducted asynchronous daily meetings. This allowed team
members to update their progress and communicate asynchronously, reducing
scheduling conflicts and improving flexibility.

 Sprint Reviews: The team conducted regular sprint reviews to showcase their work
and gather feedback from stakeholders. These reviews helped ensure that the project
was on track and met the expectations of the stakeholders, leading to course
corrections and improvements.

 Velocity Tracking: The team tracked their velocity, which is a measure of the
amount of work completed in each sprint. They analyzed their velocity at different
points in the project and compared it to the process modifications they made. This
analysis allowed them to identify correlations between their process modifications and
improvements in velocity.