MOOC 02:

Agile Software Development

Agile Model
Agile Manifesto (2001)

“On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski,
relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto.
Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development,
Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software
development processes convened.“

1. Individuals and Interactions Over Processes and Tools

Cá nhân và tương tác hơn là quy trình và công cụ
2. Working Software Over Comprehensive Documentation
Phần mềm hoạt động tốt hơn là tài liệu đầy đủ
3. Customer Collaboration Over Contract Negotiation
Hợp tác với khách hàng hơn là đàm phán hợp đồng
4. Responding to Change Over Following a Plan
Ứng phó, phản hồi với các thay đổi hơn là làm theo kế hoạch

That is, while there is value in the items on the right, we value the items on the left more.
Agile Principles
Big batch vs Small bite-size
Hand-off vs Collaboration
Culture change
Agile project journey
Advantages Vs Disadvantages of Agile model

Advantages: Disadvantages:
• Ability to rapidly and flexibly respond to change • Highly dependent upon the motivation and expertise
• Minimal formal processes of the developers
• Communication between project team members • Difficult for new team members to enter the project
is encouraged • Need good communication skills to interact with the
• Customer feedback is provided throughout the client regularly
entire development process • Difficult to use during large projects due to the
• Development is broken into short intervals with emphasis on real-time communication
frequent software releases
When to use Agile model
 Discovering user needs

Customers often don’t have a clear

idea of what they want. They can’t
articulate or predict what they really
want.

So a good user requirements process

will help us get what’s in their mind
and help us build exactly what they’re
looking for.
 Hand-off Requirements Document

When you use documents to

communicate requirements is that
what the user wrote in the document or
what they meant, the architects or the
other stakeholders or the developers
understand it differently. What that
does is that what you build is
something different than what the user
originally wanted.
 Agile Approach

In an agile approach, this is done

by two key things. One is to
encourage conversation and then
to be adaptive in the
requirements. So make
conversation as the primary form
of communication and then allow
the process to explore user needs
rather than gathering all user
needs in one shot.
 Story Process

Conversation

Adaptive
 User stories

 A user story is a brief description of what

a product needs to do.
 A user story is an informal, general
explanation of a software feature written
from the perspective of the end user or
customer.

User story template:

As a _______(role)_______,
I want _____(goal)________,
so that ____(benefit)_____.

 Every user story needs a Definition of Done (acceptance criteria)

User stories Example

Another example of a user story in Mike Cohn’s format could be as follows:

“As a customer, I want to add a product to my shopping cart to save

time and get the product I want quickly.”
Acceptance criteria for this user story could be
• The product is successfully added to the shopping cart.
• The total amount in the shopping cart is updated automatically.
• The customer can change the quantity of the product in the shopping cart or remove the
product from the shopping cart.
• When the customer completes the order, the shopping cart is emptied.
User stories

A good user story should be — INVEST:

Bad vs Good User stories example
User stories Example

• As a mobile commerce customer, I want a shopping cart button, so I can easily store items that
I’m interested in purchasing.
• As a dry cleaning customer, I want to receive a push notification when my order is done, so I
can pick it up right away.
• As a student, I want to invite my classmates to download the app, so we can work together on a
project.
• As a manager, I want an option for anonymous feedback, so my employees feel comfortable
sharing information with me.
• As an HR rep, I want to generate a report on employee feedback, so I can understand which
departments need better training materials.
• As a basketball player, I want a court reservation feature, so I can book a private time to
practice at the gym.
 Epic user stories

• The epic is the large item of the work that can be broken down into
smaller user stories or tasks.
• Epic stories help you paint a broader picture by summarizing a complex
action composed of smaller actions. In this sense, the epic user story is
like an overview of a product feature
Epic user stories Example
User Story Mapping

Story Maps were first introduced by Jeff Patton in

2005. The main idea behind Story Maps is that single-
list product backlogs are a terrible way to organize
and prioritize the work that needs to be done. A richer
structure is necessary.
User Story Mapping (USM) is used to create,
organise and visualise tasks in a software
development project. Its main purpose is to show what
user interaction with the product looks like. First of all,
it helps the development team to understand what
features should be implemented in the final product
and how they can be related to the users' needs.
It is worth noting that the User Story
Mapping technique was proposed by Jeff Patton, who
is one of the founders of the Scrum methodology. This
tool is a way to organise and map user stories, which
helps the team to have a common understanding of
the product, its components and user needs.
 User Story Mapping

A user-story map depicts 3 level:

1. Activities represent the high-level
tasks that users aim to complete in the
digital product — for example, Check
account balance or Deposit a check.
2. Steps (Task) sit directly underneath
activities and also display in sequential
order. They represent the specific
subtasks that users will go through in the
product to complete the activity above.
3. Details User stories are the third
level of the story map and describe the
lowest-granularity interactions that the
team anticipates users will experience to
complete the step above.
How to Create a User Story Map

The process of creating a user story map can be broken down into seven distinct steps that we recommend you
take collectively with your team during a communal planning session

Step 1: Main users, the journeys

"As a user, I want to buy a product
easily on this website."
The first step in our user story mapping example is to
identify main product users.
Here are some questions you should be asking:
• What problem are we trying to solve?
• How does this feature add value?
• Who is the audience subset we are building for? (If any)
In this example, the user story is as follows: "As a user, I
want to buy a product easily on this website."
How to Create a User Story Map

The process of creating a user story map can be broken down into seven distinct steps that we recommend you
take collectively with your team during a communal planning session

Step 2: Identify User activities, the backbone

The next step is to build the backbone of the story map. In

other words, we want to identify the activities that main
users will perform by using the product. Following the same
example from the previous section, here's how it could look:
Activities:
• Search for products.
• Review product details.
• Check out.
How to Create a User Story Map

The process of creating a user story map can be broken down into seven distinct steps that we recommend you
take collectively with your team during a communal planning session

Step 3: Identify user tasks, the epics

The next step consists of identifying tasks that the user
would execute in order to perform each of the activities.
The question to ask is: What sequence of tasks does the
user execute to complete this job?
The main tasks are:
Steps:
• Type into the search bar and head to the results page.
• Scroll through search results in search of specific
information.
• Select the filtering option to narrow down options by cost.
• Review the search results page again with updated
options.
• Select item and place in cart.
• Complete purchase.
How to Create a User Story Map

The process of creating a user story map can be broken down into seven distinct steps that we recommend you
take collectively with your team during a communal planning session

Step 4: Identify task details, the user stories

The next step in the user story mapping example is to go
through the vertical direction. It is time to look at the details
of how users will actually experience the product.
Practically, this comes down to defining the details that
compose each task. The question to answer is: How does
the user use our product to complete each task?

Differently from activities and tasks, where we think in

terms of customer needs, task details are all about product
functionalities, UI and UX. This is where the translation of
customer needs to actual product specification really
happens. In fact, in the agile world details are synonyms
for user stories. A user story is the specification of a
product functionality described from the perspective of the
user.
How to Create a User Story Map

The process of creating a user story map can be broken down into seven distinct steps that we recommend you
take collectively with your team during a communal planning session

Step 5: First release, or MVP

By the team you reach this point, your map has become
quite big. In fact, you may need an entire wall or floor rather
than just a piece of paper. If size is a problem, digital tools
may come to rescue. Even more, while the team proceeds
with product development and new customers feedback
becomes available, the map grows with new ideas and
discoveries.
For instance, in this example, the first slice would skip two
tasks in the "Search" activity, skip three in the "Get product
details" one, and three in the "Check out" section.
The second slice would include features like "Search by
category" and "See product in AR." Once you have all your
slices, your team is ready to get to work.
User story map Example

https://prodmapping.com/guides/user-story-mapping-in-product-discovery-with-an-example/
 User story map Example

In our doctor appointment app, for example, we would

have two backbones, one for each main user. For the
sake of the example, let us focus on the patient user.
The activities composing the backbone are: “Register“,
“Find Doctor”, “Schedule Appointment”, “Review
Consultation”, “Share Experience”.
These are the sequential activities that the patient
would perform to get value out of the product. You may
notice that “Share the Experience” is an activity that
does not really reflect the need of the users, but rather
the needs of business stakeholders. Indeed, sharing
their experience with the doctor is an activity that not
everyone would like to do. Nevertheless, we include
this activity for two reasons. First, research shows that
sharing experience creates personal gratification, so
some users may want to share their experience with
others. Second, having users sharing their experience
can help acquiring new users through network effects
 User story map Example

In the doctor appointment app example, let’s look at the

“Find Doctor” activity. To search for a doctor, the patient
may perform three tasks, possibly in sequence: “Login”,
“Search Doctor”, “Check Doctor’s Profile”. In order to
“Schedule Appointment”, the user would perform two main
tasks: “Review Availability”, “Plan Appointment”. So, if we
consider only these two activities, we would have five
epics, as shown in the picture below.
The picture does not show tasks for the other three
activities, but it is straightforward to come up with them by
answering the question above. Of course, anyone can
come up with a different set of tasks, as there is no single
way to satisfy customer needs. Creativity, customer
knowledge and a good sense of what is feasible and what
is not (a task like “Search Doctor on Mars” may provide
value to some customers but would be less technically
feasible) are the only boundaries here.
 User story map Example

Differently from activities and tasks, where we think in

terms of customer needs, task details are all about product
functionalities, UI and UX. This is where the translation of
customer needs to actual product specification really
happens. In fact, in the agile world details are synonyms
for user stories. A user story is the specification of a
product functionality described from the perspective of the
user.
For the doctor appointment app example, let us take the
five tasks previously identified and split them into
functionalities that can help patients complete their
activities. For the “Check Doctor Profile”, we can come up
with the following user stories: “Open the doctor details
page”, “Review the doctor public profile“, “Scroll through
list of services”, “Expand ratings section”, “Scroll through
comments from other patients”. Clearly, stories are more
concrete actions than epics. They correspond to actual
functionalities on the doctor profile page.
 User story map Example

By the team you reach this point, your map has become quite big. In
fact, you may need an entire wall or floor rather than just a piece of
paper. If size is a problem, digital tools may come to rescue. Even
more, while the team proceeds with product development and new
customers feedback becomes available, the map grows with new
ideas and discoveries.
Sooner than later, the product manager will need to prioritize user
stories according to value for the customer and the business.
Practically, this consists of shuffling user stories so that the high
priority ones are on top. Moreover, prioritization requires to look at the
full customer journey, the horizontal direction, so that value spans the
full customer experience. This is why prioritizing on a story map is
better than doing on a backlog. Indeed, a story map allows to prioritize
not only vertically (across user stories), but also horizontally
Once prioritization is done, the whole product team needs to literally
“draw a line” between functionalities that will be delivered in the first
release and functionalities that will go to future releases. The first
release of a product, sometimes called Minimum Viable Product
(MVP), should focus on the core features of the app, so that the
product team can go to market relatively quickly and get early
feedback from users on those stories that matter most for them. Story
mapping can be applied to scoping minimum viable features (MVF),
the equivalent of MVPs for single product features.
Here is how the MVP looks like on the story map of our example.
User story map Example

Example story mapping with the user need to find a book and reserve
User story map Example

Example story mapping with the user need to find a book and reserve
User story map Example

Example story mapping with the user need to find a book and reserve
Product backlog

What is a Product Backlog?

A product backlog is a list of tasks, features, user stories, and
bug fixes the development team will work on while executing the
product roadmap. It is characterized by the following.
• Acts as the single source of requirements for the development
team
• Breaks down the high-level organizational vision into tasks
• Prioritizes the items and features on the product roadmap
• Stays dynamic, evolving with the needs of the market, consumer,
and organization

What does the product backlog contain?

Essentially, a product backlog contains everything that agile teams
need to work on. This can be:
• New features
• Existing feature enhancements
• Bug fixes
• Customer requests
• Action items from the retrospective
• Technical debt
• Infrastructure updates
Agile Frameworks

Agile is a philosophy and a mindset. Agile is not a methodology. Agile consists of a set of
methodologies and frameworks which fulfill certain aspects of the Agile Manifesto described
earlier. I look at Agile as a umbrella with various agile methodology and frameworks under the
umbrella.

o Scrum
o Kanban
o Extreme Programming (XP)
 Agile/Scrum
methodologies
 Scrum Frameworks

• Scrum is an iterative and incremental

agile software development
framework
• A flexible, holistic product
development strategy
• Development team works as an
atomic unit
• Opposing to sequential approach
The Scrum Team

• Product Owner
o Possibly a Product Manager or Project Sponsor
o Decides features, release date, prioritization, $$$

• Scrum Master
o Typically a Project Manager or Team Leader
o Responsible for enacting Scrum values and practices
o Remove impediments / politics, keeps everyone productive

• Project Team
o 5-10 members; Teams are self-organizing
o Cross-functional: QA, Programmers, UI Designers, etc.
o Membership should change only between sprints
Sprint in Scrum

A Sprint in Scrum is a time-boxed iteration of work,

typically lasting between one to four weeks, during
which a cross-functional Scrum Team collaborates
to deliver a potentially shippable product increment.
• It begins with Sprint Planning, where the team
selects items from the Product Backlog to work on
and defines a Sprint Goal.
• Throughout the Sprint, the team holds Daily
Scrum meetings to synchronize activities and
address any impediments.
• At the end of the Sprint, the team conducts a
Sprint Review to demonstrate the completed work
to stakeholders and gather feedback.
• Finally, they hold a Sprint Retrospective to reflect
on their processes and identify areas for
improvement. The Sprint provides a structured
framework for iterative development, enabling the
team to deliver value incrementally while fostering
adaptability and transparency.
Sprint in Scrum

• Sprint Planning
• Daily Scrum
o Daily Standups
• Sprint Review
• Sprint Retrospective
Product backlog in Scrum

A product backlog is a list of requirements, also known as user stories, arranged in a specific order to enhance the
value of the delivered product that needs to work upon to create or maintain the product. The product backlog
should be managed by the product owner. There can be only one product backlog for a product.
Product backlog in Scrum
Product backlog in Scrum
 Sprint Backlog in Scrum

Sprint Backlog is a set of Product

Backlog items selected for the
current Sprint, plus plans for
delivering product increments for
achieving Sprint goals. Sprint
Backlog is the development team’s
expectation of what functions will be
included in the next increment and
what work will be required to deliver
those functions.
Sprint Planning

Each Sprint starts from the event

called - Sprint Planning. During
this meeting, Scrum
Team: Developers, Product
Owner and Scrum
Master collaboratively creates a
plan of the work for the upcoming
iteration.
Example Scrum

User Story Mapping

Example Scrum
Example Scrum
Sprint Tracking

A burn up chart tracks the amount of work to be

completed as one straight line across the top of the graph

A burn up chart with an ideal line, showing where the

project is ahead of and behind schedule.
Sprint Tracking

A Scrum task board is an integral part of

the Scrum method. It consists of rows and
columns - each row is a user story, which
functions as a unit of work that the Scrum
team uses for their product backlog. Tasks
are recorded on colored cards. Team
members update the task board
frequently, most commonly during the
daily meetings, based on the team’s
progress since the last update.
 Daily Standups

A daily stand-up meeting is a short organizational meeting that is held each day. The meeting, generally limited to
between five and 15 minutes long, is sometimes referred to as a stand-up, a morning roll-call or a daily Scrum.

For example,
• “Yesterday I was working on getting the SharePoint list data from
the postman tool”,
• “Today, I am working on updating the list item using the postman
tool”, and “Tomorrow, I will test the postman tool query, and
deploy it in the production.”
• And, I have no impediments, all tasks are going as planned.
Sprint Review

The sprint review is held at the end of each scrum

sprint. During the sprint review, the scrum
development team, product owner, and business
stakeholders gather together to discuss the sprint
results.
Sprint Retrospective

A sprint retrospective is a review conducted after a

sprint that plays a key role in the Agile methodology.
A sprint retrospective aims to determine what went
well and where you had problems and identify areas
where you can improve. Regular reviews are an
essential part of team collaboration.
Key Features of Scrum Methodology

• Scrum has a short fixed schedule of release cycles

with adjustable scope known as sprints to address
rapidly changing development needs. Each release
could have multiple sprints. Each Scrum Project
could have multiple Release Cycles.
• A repeating sequence of meetings, events, and
milestones
• A practice of testing and implementing new
requirements, known as stories, to make sure
some work is released ready after each sprint
eXtreme Programming
What is Extreme Programming (XP)?

Extreme Programming (XP) is an agile software

development framework that aims to produce higher
quality software and higher quality of life for the
development team. Extreme programming is, in a
nutshell, about good practices taken to an extreme.
Since pair-programming is good, let’s do it all of the
time. Since testing early is good, let’s test before the
production code is even written.
XP’s origin dates back to the 90s when Kent Beck –
who would later become one of the authors of the
Agile Manifesto – created it when hired to lead
Chrysler’s Comprehensive Compensation System
team.
05 Values of Extreme Programming
12 extreme programming practices

To further hone the process, XP also uses a set of 12 practices throughout the process. They are based on
the Agile manifesto, but adapted to fit XP needs:
1.The planning game: XP planning is used to guide the work. The results of planning should be what you’re
hoping to accomplish and by when, and what you’ll do next.
2.Customer tests: When you finish a new feature, the customer will develop an acceptance test to determine how
close it is to their original user story.
3.Small releases: XP uses small, routine releases to gain insights throughout the process. Often, releases go
straight to the customers, though they can happen in-house.
4.Simple design: The XP system is designed for simplicity—you’ll produce only what is necessary and nothing
more.
5.Pair programming: All programming comes from a pair of developers who sit side by side. There is no solo
work in extreme programming.
6.Test-driven development (TDD): XP’s reliance on feedback requires heavy testing. Through short cycles,
programmers release automated tests and then immediately react.
12 extreme programming practices

7. Refactoring: This is where you’ll pay attention to the finer details of the codebase, removing duplicates and
making sure that the code is cohesive. This results in good, simple designs.
8. Collective ownership: Any coding pair can change the code at any time, whether or not they developed it. XP
produces code as a team, and everyone’s work is held to the higher collective standards.
9. Continuous integration: XP teams don’t wait for completed iterations, they integrate constantly. Often, an XP
team will integrate multiple times a day.
10.Sustainable pace: The intensity of XP works requires you to set a sustainable pace. Teams should decide
how much work they can produce in this way per day and per week, and use that to set work deadlines.
11.Metaphor: The metaphor is, quite literally, a metaphor. It’s decided as a team, and uses language to describe
how the team should function. For example, we’re ants working as a collective to build up the anthill.
12.Coding standard: XP teams follow one standard. In the same way that writers need to take on a brand’s
voice to sound like the same person is always writing, XP developers code in the same, unified way so that it
reads like one developer.
XP – Process Model

In contrast to other approaches, XP is very opinionated in engineering practices. In addition to practices, XP is

based on values and principles.
Extreme Programming vs. Scrum

Scrum is a framework for helping teams develop complex projects in an adaptive manner. Scrum doesn’t
dictate how developers do the work. XP, as mentioned, puts much emphasis on good programming practices.
Also, XP is obviously about programming. Scrum, on the other hand, can be applied to any project that benefits
from an iterative approach. XP accepts changes to its components. Teams are allowed and even encouraged
to tweak the practices according to their specific needs. The Scrum Guide, on the other hand, is adamant in
stating that “While implementing only parts of Scrum is possible, the result is not Scrum.” Also, Scrum is a
framework that you need to fill out with methodologies and practices for doing the work. That means that it’s not
only possible to use XP and Scrum together but extremely recommended.
KANBAN
What is Kanban?

Kanban is a Japanese term that means “signboard” or

“visual card,” with the project management concept itself
originating in the 1940s and 1950s from Toyota. Constrained
by resources and supplies, the Japanese automotive
industry always sought to increase productivity and
throughput.

Kanban is an agile framework used for project and task

management. At its core are continuous improvement and
just-in-time development, which allows teams to stay on top
of any changes and updates. This also results in better
alignment between estimated requirements and actual
capabilities.
The primary medium that Kanban methodology uses is a
Kanban board — this visualization tool enables project
members to quickly understand what is happening
throughout the process. Cards (representing individual
tasks) are placed on the board and moved across columns
as work is completed or changed.
Kanban vs. Scrum
Kanban – Process Model

study implement integrate test done

• Visualize the workflow backlog
2 4 1 3
• Limit Work In Progress
(WIP)
• Measure and manage flow
• Make process policies
explicit Lead time until done
• Improve Collaboratively
(using models/scientific Cycle time of impl.
method)
Kanban – Process Model

The Kanban software development process is a method that emphasizes visualizing tasks, limiting work-in-
progress, managing flow, and continuously improving. Here’s how it works:
1. Visualize workflow: Start by mapping out your team’s process on a Kanban board. This might include stages
like “Backlog,” “To Do,” “In Progress,” “Review,” and “Done.” Each task is represented by a card that moves
across these stages.
2. Limit work-in-progress (WIP): Set limits on the number of tasks that can be in progress at any given time.
This helps prevent your team from getting overwhelmed and encourages them to focus on completing tasks
before starting new ones.
3. Measure and manage flow: Use the metrics and analytics provided by your Kanban software to track how
tasks move through your workflow. Look for bottlenecks and areas where tasks tend to stall and adjust your
process to improve flow.
4. Continuously improve: Regularly review your team’s performance and make incremental improvements. This
might involve tweaking your WIP limits, adjusting your workflow stages, or introducing new practices to
enhance productivity.
Kanban work?
Kanban work?
Kanban work?
 Kanban vs. Scrum

Both of these methodologies facilitate projects to deliver

value incrementally and iteratively. Each has so much
history and practical considerations that the discussion
of Kanban vs. Scrum had to be split into its own resource.
However, here are some high-level points and differences
when comparing the two:
•While Kanban is a task management system, Scrum is a
project delivery framework that benefits from Kanban in its
task management function.
•Kanban does not define particular roles — unlike Scrum,
which has a Product Owner, Scrum Master, and
development team. This is because Kanban uses a
continuous delivery cycle where everyone is equally
responsible for managing the flow of value.
•While both allow changes to be made, change can be
incorporated at any point in the Kanban
approach whereas Scrum typically avoids changes during
the sprint
Selection Process Parameters for a
Software Life Cycle Model
Choosing the right SDLC Model
Selection Process parameters plays an important role in software development as it helps to choose the best
suitable software life cycle model. Following are the parameters which should be used to select a SDLC.

1. Requirements characteristics : 2. Development team :

• Reliability of Requirements • Team size
• How often the requirements can change • Experience of developers on similar type of
• Types of requirements projects
• Number of requirements • Level of understanding of user requirements by the
developers
• Can the requirements be defined at an early stage
• Environment
• Requirements indicate the complexity of the
system • Domain knowledge of developers
• Experience on technologies to be used
• Availability of training
Choosing the right SDLC Model
Selection Process parameters plays an important role in software development as it helps to choose the best
suitable software life cycle model. Following are the parameters which should be used to select a SDLC.

3. User involvement in the project : 4. Project type and associated risk :

• Expertise of user in project • Stability of funds
• Involvement of user in all phases of the project • Tightness of project schedule
• Experience of user in similar project in the past • Availability of resources
• Type of project
• Size of the project
• Expected duration for the completion of project
• Complexity of the project
• Level and the type of associated risk
Choosing the right SDLC Model

Evolutionary Iterative and

Factors Waterfall V-Shaped Spiral Agile
Prototyping Incremental
Unclear User Requirement Poor Poor Good Excellent Good Excellent

Unfamiliar Technology Poor Poor Excellent Excellent Good Poor

Complex System Good Good Excellent Excellent Good Poor
Reliable system Good Good Poor Excellent Good Good
Short Time Schedule Poor Poor Good Poor Excellent Excellent

Strong Project Management Excellent Excellent Excellent Excellent Excellent Excellent

Cost limitation Poor Poor Poor Poor Excellent Excellent

Visibility of Stakeholders Good Good Excellent Excellent Good Excellent
Skills limitation Good Good Poor Poor Good Poor
Documentation Excellent Excellent Good Good Excellent Poor
Component reusability Excellent Excellent Poor Poor Excellent Poor
Agile Framework Summary
Aspect Scrum Kanban Lean Extreme Programming (XP)

Elimination of waste and Technical excellence and

Philosophy Iterative and time-boxed Flow-based and flexible
efficiency collaboration

Visualizing workflow and Efficiency and value High-quality software and

Primary Focus Collaboration and adaptability
flexibility maximization customer feedback

Iterative development and

Work Organization Sprints (fixed time intervals) Continuous flow of work Value stream mapping
frequent releases

Sprint reviews, daily stand- Frequent customer feedback

Feedback and Inspection Continuous monitoring Continuous improvement
ups and testing

Managed based on team Emphasis on small batches

WIP (Work in Progress) Limited during sprints Not explicitly limited
capacity and iterations

Regular feedback during Close collaboration with

Customer Collaboration Can be integrated as needed Customer feedback loops
sprints customers

Focused on process Emphasized: TDD, pair

Engineering Practices Optional; may vary by team Not explicitly defined
optimization programming, CI/CD

May vary based on sprint Can lead to reduced lead Strives for rapid and frequent
Lead Time Reduction Central objective
length times releases

Scopes are fixed within Flexible, can accommodate Welcomes and adapts to
Change Handling Adaptable to changes
sprints changes changing requirements

Projects with fixed-length Continuous workflow Operations, process High-quality software,

Suitability
cycles improvement optimization technical teams
Choosing the right SDLC Model

Which projects are most suitable for Waterfall? Which projects are most suitable for Agile?
Waterfall projects are best suited for: Agile projects are best suited for:
• Smaller, well-defined, and simpler projects • Projects with an involved client
• Working with external organizations or vendors, • Instances where there is scope for changing
where a high degree of collaboration may be requirements
impractical • Benefit from phased delivery.
• Projects with a fixed scope, time, and budget • Efforts where your organization is responsible for the
• Projects with a client that is not engaged entire process
• Larger, undefined, complex projects

Reference coursera
https://www.coursera.org/learn/software-processes/lecture/mLIZn/applying-software-development-models
https://www.coursera.org/learn/software-processes/lecture/W387O/model-selection-when-to-use-which-model