SDLC

The Software Development Life Cycle (SDLC) is a structured process followed by software development teams
to :
 Plan
 Design
 Develop
 Test
 Deploy and
 Maintain
Software projects.

It is a framework for ensuring that high-quality software is delivered systematically and efficiently.
The SDLC process comprises several distinct phases, each with specific goals and deliverables.
Below is a detailed explanation of each phase of the SDLC:
1. Requirement Gathering and Analysis
Objective: Understand the exact requirements of the stakeholders, customers, or users.
Activities:
 Conduct meetings, interviews, and workshops with stakeholders to gather and document their requirements.
 Analyze the feasibility of these requirements in terms of technical, operational, and economic factors.
 Create a Software Requirement Specification (SRS) document that serves as a guide for the next phases.
Outcome: SRS document that lists all functional and non-functional requirements.

2. System Design
Objective: Create a blueprint for the software solution.
Activities:
 Design the system architecture, including defining hardware and software requirements.
 Develop detailed designs for the user interface, database, modules, and data flows.
 Prepare design documents like Entity-Relationship Diagrams (ERD), Data Flow Diagrams (DFD), and UML
diagrams.
Outcome: High-level design (HLD) and low-level design (LLD) documents, which provide a detailed architecture and
3. Implementation (Coding/Development)
Objective: Convert the system design into a working software application.
Activities:
 Developers write code based on the design documents and the SRS.
 Different modules or units of the software are developed in parallel by different teams.
 Code review and unit testing are performed to ensure code quality.
Outcome: Source code and developed modules of the software.

4. Testing
Objective: Identify and fix any defects or issues in the software to ensure it meets the requirements.
Activities:
 Conduct various types of testing, such as unit testing, integration testing, system testing, and user acceptance
testing (UAT).
 Use automated and manual testing methods to verify that the software works as expected.
 Report bugs, fix issues, and retest until the software is stable and meets quality standards.
Outcome: A fully tested and stable software application that is ready for deployment.
5. Deployment
Objective: Release the software to the production environment for use by end-users.
Activities:
 Plan and execute the deployment strategy, such as continuous deployment, phased deployment, or big bang
deployment.
 Set up the production environment, including configuring servers, databases, and networks.
 Deploy the software and perform smoke testing to ensure the deployment is successful.
Outcome: The software is live and available to users.

6. Maintenance
Objective: Ensure the software continues to function correctly after deployment.
Activities:
 Monitor the software for any bugs, performance issues, or user feedback.
 Provide patches, updates, or new releases to fix bugs, add new features, or enhance performance.
 Offer user support and conduct training sessions if necessary.
Outcome: Continuous improvement and updates to the software to keep it relevant and efficient.
Popular SDLC Models
• The SDLC process can be implemented using various models, depending on the project requirements,
complexity, and team preferences. Some popular SDLC models are:
• Waterfall Model: A linear and sequential approach where each phase must be completed before the next one
begins.
• V-Model (Verification and Validation): An extension of the Waterfall model with a strong emphasis on testing
at each development stage.
• Spiral Model: A combination of iterative development (Agile) and the Waterfall model, with a focus on risk
analysis.
• Agile Model: An iterative and incremental approach that focuses on delivering small, workable parts of the
software quickly.
• DevOps Model: Integrates development and operations teams to improve collaboration and productivity,
emphasizing continuous integration, continuous testing, and continuous deployment.
 JIRA Waterfall Model
Before understanding the Agile and JIRA, you must be aware of the waterfall model.
What is a Waterfall model?
Waterfall model is the oldest model used by an IT industry to develop the software.
There are various models and processes which are used by different companies, but the waterfall model is the oldest, safest, and
easy model in the IT industry.
It is the easiest model for building software that represents real life
Let's understand the Waterfall model. Waterfall model is broken down into multiple phases:
Requirements
Suppose there is a client and he wants to develop software, then the client reaches out to the company. Suppose he reaches out
to the service-based company and asks the company to build the software for me.
What does the company do?
Company will collect all the requirements, the knowledge that the customer has or the client want to have on his software, the
company will collect all the information from the client and prepare the documentation. Once this activity is performed, then the
design phase gets started.
Design :
In this phase, we prepare the high-level and low-level designs. Before developing the software, the design of the software is
required. Suppose the customer wants e-commerce website similar to the Amazon, then UI(User Interface) of the website will
be made by the designer and dataflows are also designed in this phase that how data will flow. Once this phase is completed, the
development phase will get started.
Development:
In the Development phase, the software development team starts coding and developing the software. This is the longest phase
of the waterfall model as developers need more time to build the software. Once the development of the software is completed,
then the project is handed over to the testers.
Testing:
The testing team will test the software, and if any bug is found, then they inform the developers about the issue they found and
make sure that the bug is fixed. They ensure that the end-to-end software is completed.
Deployment:
Once the project is tested, the project is deployed so that it becomes live to the real-time users.
Example of Waterfall model
Lets say client wants an app like a WhatsApp, so he reaches to the company where both the company and the client had a
discussion for 2 months.

The company made the documentation of all the requirements in 2 months.

Now, the development team starts developing the software and suppose it took around 10 months to develop the software.

It means that 12 months have been used, i.e., 2 months in requirement phase and 10 months in a development phase, but still
the client does not have the idea about the internal phases.

Once the development is completed, testing is done, and it will take around 2 months for software quality testing.
Once the testing is done, it goes to the integration and launch so that WhatsApp will become live.

However, when it reaches to the client, then the client says that it has taken more than a year and the software that I received
was not what I expected.

This happened because the client had only verbal communication with the software team.
If the client wants some changes in the software, then the whole process will be executed again.
Advantages of the Waterfall model
• Simple and easy to understand and use
• It represents all the tasks that you want to do in real life. For example, you need the requirements of a client. It contains
different phases, and each phase is started only when the previous phases get completed.
• Specific deliverable and review process
• Each phase has a specific deliverable and review process. After the requirement phase, we have all the requirements of
what the customer needs. Once the software is developed, we have its deliverable.
• Phases do not overlap
• In this model, phases do not overlap, i.e., they are completed once at a time. Once the previous phase is completed, then
only the next phase gets started. For example, the Development phase will start only when the design phase is completed.
Disadvantages of the Waterfall model
• Time to market is high
• Product is released only when all the phases are completed. Therefore, this model takes a long time to release the product.
• Unexpected results
• What you expect and you receive are mostly different as the customer has an idea as per the documents only about the
product. The client has only an idea, which is a documented idea.
• Not suitable for changing requirements
• This model is not suitable for the projects where requirements are at a moderate to high risk of changing. If the
requirements are changing, then this model is not recommended as all the requirements are done at the requirement phase,
which is a very time taking process.
 V-model
V-Model Design
Requirements Gathering and Analysis: The first phase of the V-Model is the requirements gathering and analysis phase, where
the customer’s requirements for the software are gathered and analyzed to determine the scope of the project.

Design: In the design phase, the software architecture and design are developed, including the high-level design and detailed
design.

Implementation: In the implementation phase, the software is built based on the design.

Testing: In the testing phase, the software is tested to ensure that it meets the customer’s requirements and is of high quality.

Deployment: In the deployment phase, the software is deployed and put into use.

Maintenance: In the maintenance phase, the software is maintained to ensure that it continues to meet the customer’s needs and
expectations.

The V-Model is often used in safety: critical systems, such as aerospace and defensce systems, because of its emphasis on
thorough testing and its ability to clearly define the steps involved in the software development process.
 V-Model Design
Requirements Gathering and Analysis: The first phase of the V-Model is the requirements gathering and analysis phase,
where the customer’s requirements for the software are gathered and analyzed to determine the scope of the project.

Design: In the design phase, the software architecture and design are developed, including the high-level design and detailed
design.

Implementation: In the implementation phase, the software is built based on the design.

Testing: In the testing phase, the software is tested to ensure that it meets the customer’s requirements and is of high quality.

Deployment: In the deployment phase, the software is deployed and put into use.

Maintenance: In the maintenance phase, the software is maintained to ensure that it continues to meet the customer’s needs and
expectations.

The V-Model is often used in safety: critical systems, such as aerospace and defence systems, because of its emphasis on
thorough testing and its ability to clearly define the steps involved in the software development process.
Industrial Challenge:
As the industry has evolved, the technologies have become more complex, increasingly faster, and forever
changing, however, there remains a set of basic principles and concepts that are as applicable today as when IT
was in its infancy.
• Accurately define and refine user requirements.
• Design and build an application according to the authorized user requirements.
• Validate that the application they had built adhered to the authorized business requirements.

Importance of V-Model
1. Early Defect Identification
2. determining the Phases of Development and Testing
3. Prevents “Big Bang” Testing
4. Improves Cooperation
5. Improved Quality Assurance
Advantages of V-Model
• This is a highly disciplined model and Phases are completed one at a time.
• V-Model is used for small projects where project requirements are clear.
• Simple and easy to understand and use.
• This model focuses on verification and validation activities early in the life cycle thereby enhancing the
probability of building an error-free and good quality product.
• It enables project management to track progress accurately.
• Clear and Structured Process: The V-Model provides a clear and structured process for software development,
making it easier to understand and follow.
• Emphasis on Testing: The V-Model places a strong emphasis on testing, which helps to ensure the quality and
reliability of the software.
• Improved Traceability: The V-Model provides a clear link between the requirements and the final product,
making it easier to trace and manage changes to the software.
• Better Communication: The clear structure of the V-Model helps to improve communication between the
customer and the development team.
Disadvantages of V-Model
• High risk and uncertainty.
• It is not good for complex and object-oriented projects.
• It is not suitable for projects where requirements are not clear and contain a high risk of changing.
• This model does not support iteration of phases.
• It does not easily handle concurrent events.
• Inflexibility: The V-Model is a linear and sequential model, which can make it difficult to adapt to changing
requirements or unexpected events.
• Time-Consuming: The V-Model can be time-consuming, as it requires a lot of documentation and testing.
• Overreliance on Documentation: The V-Model places a strong emphasis on documentation, which can lead to an
overreliance on documentation at the expense of actual development work.
3) Validation phase includes
• Unit testing is conducted early so that the bugs are eliminated at the early stages of product
development, though not all bugs can be revealed.
• Integration testing is done to check whether there is valid and proper communication within the internal
modules of the system.
• System testing is the testing of the entire system to ensure that the internal modules are configured to
communicate effectively with the external systems.
• Acceptance testing is done to test a product in the client’s environment to check compatibility issues.

Advantages of the V model:

• Simple and explicit process to follow
• Testing starts from the requirement phase itself
• All the Functional Areas can be covered
• Defects can be found at an early stage
• This is comparable to the shift-right approach in DevOps testing, which encourages the testers to
analyze and wait until changes are deployed in production to find defects in unexpected real-life
situations.
 Spiral Model
The spiral model is a systems development lifecycle (SDLC) method used for risk management that combines the
iterative development process model with elements of the Waterfall model.
The spiral model is used by software engineers and is favored for large, expensive and complicated projects.
The model consists of four phases –
Planning,
Risk analysis,
Engineering, and
Evaluation
which are executed in a cyclical manner, with each cycle building on the previous one.
Important Points
• This makes it a highly adaptable framework that can be used to guide and adapt any software development
process.
• Due to its flexibility and risk management focus, the Spiral Model is a popular choice for complex and large-
scale software projects.
• It enables software development teams to identify potential risks early on and adjust the development process
accordingly, ultimately leading to a higher quality product.
“The spiral model is called the metamodel” because it encompasses other software development lifecycles. For
e.g. a single loop spiral actually represents an iterative waterfall model. Spiral models use prototype models to
create prototypes before starting actual product development. A spiral model allows you to mitigate risk and take
a systematic approach. Spiral models can also be viewed as supporting evolutionary models.
Risk Handling in Spiral Model
The spiral model analyzes all proposed solutions and identifies, analyzes and addresses all potential risks.
Following this, methods such as prototyping, simulation, benchmark testing, analytical models, and user research
are used to develop the lowest-risk, most cost-effective strategy.

The different phases of the spiral model are-

1. Planning
 This phase begins by gathering business requirements into a baseline spiral. In the subsequent spiral, all system,
subsystem and unit requirements are identified at this stage as the product matures.
 This phase also includes understanding system requirements through ongoing customer and system analyst
communication. The product will be deployed in the identified market at the end of the spiral.
 This includes iteration cost, schedule, and resource estimates.
 This includes understanding system requirements for ongoing communication between system analysts and
customers.
2. Risk Analysis
 After the “plan” phase, the team prepares for the “risk” phase. The “risk” phase is designed to consider the
variability in the rate at which a given product might fail.
 It is designed to account for the uncertainty in the rate at which a given product might fail.
 During the “risk” phase, the team evaluates various aspects of the current state of the product, such as the state
of its code, the state of its design, and the state of its prototype.
 The team then makes adjustments to the current state of the product based on the changes made in the “plan”
phase and then follows up with a “sales” phase to collect customer feedback.
 Once risks are identified, risk mitigation strategies are planned and completed.
 Briefly, risk analysis involves identifying, estimating and monitoring technical feasibility and management risks
such as schedule slippage and cost overrun.
 After testing the build, customers rate the software at the end of the first iteration and provide feedback.
3. Product development
 In the next quadrant, prototypes are built and tested.
 This step includes architectural design, module design, physical product design and final design.
 Convert the proposals made in the first two quadrants into usable software.
 This phase also includes the actual implementation of features in a project, which are verified by performing
testing.
4. Next phase planning
 In this phase, the customer evaluates the software and gives feedback.
 The team prepares for the next phase of the planning process.
 The next phase of the planning process is known as the “spiral” phase.
 During the “spiral” phase, the team determines the order of events in the current state of the product and then
follows these events up with a “revision” phase to “Revise” the current state of the product so that it is ready for
production.
 The “revision” phase is also called the “reproduction” phase, one of the most important aspects of the planning
process.
Conclusion: Each spiral in this model can be called a loop, a separate development process for the spiral model.
Four activities (Planning, Risk Analysis, Engineering, and Evaluation) form the intermediate phases of the spiral
model and are repeated for each loop. s
Benefits of the Spiral Model
 The benefits of the spiral model include:
 The spiral model works for development as well as enhancement projects.
 The spiral model is designed to control risk. The major distinguishing feature of the spiral model is that it creates
a risk-driven approach to the software process rather than a primarily document-driven or code-driven process.
 It incorporates many of the strengths of other models and resolves many of their difficulties.
 Spiral models are ideal for large and complex projects, as continuous prototyping and evaluation help reduce
risk.
 This model supports customer feedback and the implementation of Change Requests (CR), which is not possible
with traditional models such as waterfall.
 Customers see the prototype at each stage, which increases the chances of customer satisfaction.
Limitations of the Spiral Model
 The most obvious limitations of the spiral model are that it does not account for the uncertainty in the rate at
which a given product might fail and for the variability in the rate at which a given product might fail.
 This model does not account for the fact that customers might change their mind about a given product and
return it to the supplier.
 Spirals can continue indefinitely. As the spirals continue to increase, the project’s cost also increases.
 Many intermediate stages require excessive documentation.
 Spiral models are best suited for projects rather than large complex small projects as continuous prototyping and
evaluation help reduce risk.
 The number of phases is initially unknown, and frequent prototyping and risk analysis can exacerbate the
situation, so project deadlines may not be met.
 This is very expensive and time-consuming as each stage involves prototyping and risk analysis.
 SDLC Phases for Data Analysis Project:

SDLC Phase Data Analysis Phase Example Task in Data Analysis Project

Define the key questions or problems to

Requirement Gathering Business Understanding and Objective Setting
address with data
System Design Data Collection and Understanding Collect and explore data sources
Clean data, handle missing values,
Development Data Cleaning and Preparation
transform data formats
Apply analysis techniques, statistical
Implementation Data Analysis and Modeling
tests, or machine learning
Validate models, ensure statistical
Testing Validation and Interpretation
significance
Create dashboards or reports to
Deployment Presentation of Results and Reporting
communicate insights

Maintenance Monitoring and Continuous Improvement Update models or analysis with new data
 Agile Model
The Agile Model is an iterative and incremental approach to software development that emphasizes :

 Flexibility,
 Collaboration,
 Customer feedback, and
 Rapid Delivery of Small, workable pieces of Software.

It emerged as a response to the limitations of traditional waterfall methodologies, which often led to
inflexible planning and delays in responding to changes.
Below are 12 principals of agile methodology:
Here are the key phases of the Agile model:
1. Concept Phase:
Purpose: The Concept Phase is focused on idea generation and initial exploration. It involves defining the high-level
vision of the project, assessing feasibility, and identifying the key business needs or opportunities.
Activities:
Identify and clarify the main idea or problem the project aims to address.
Engage with stakeholders to understand needs, requirements, and expected value.
Perform a high-level feasibility analysis to determine if the project idea is viable.
Conduct market research, competitive analysis, and initial risk assessment.
Create a rough outline of potential scope and objectives.
Outcome: The outcome of the Concept Phase is generally a go/no-go decision. If the idea is feasible and aligns with
business goals, it proceeds to the next phase. This phase is high-level and often results in a preliminary project charter or
business case.
2. Inception Phase

Purpose: The Inception Phase comes after the Concept Phase and focuses on planning and defining the project in
greater detail. It involves assembling the Agile team, refining requirements, and setting up the necessary
groundwork for development to begin.
Activities:
 Define the project scope, goals, and high-level requirements.
 Assemble the Agile team and assign roles, such as Product Owner, Scrum Master, and team members.
 Develop an initial product backlog with prioritized user stories or requirements.
 Establish initial estimates, milestones, and timelines.
 Identify initial risks, dependencies, and constraints.
 Set up the development environment, tools, and processes.
Outcome: The outcome of the Inception Phase is a clear project plan with defined goals, a prioritized backlog,
and an understanding of the initial scope. The team should be aligned and ready to start development sprints
following this phase.
3. Iteration/Construction Phase:
• Objective: The development team works in short cycles (iterations or sprints) to design, develop, test, and
deliver small increments of the product.
• Activities: Conduct daily stand-up meetings, work on user stories, perform code reviews, and conduct
continuous integration and testing. At the end of each iteration, a working increment of the software is delivered.
• Outcome: A potentially shippable product increment at the end of each iteration

4. Release Phase:
• Objective: The goal is to release a working version of the software to the users.
• Activities: Finalize the testing (including user acceptance testing), deploy the product to the production
environment, and provide training to end-users. Documentation and release notes are prepared.
• Outcome: A stable, functional release of the software, along with documentation and trained users.
5. Production Phase:
• Objective: Ensure that the software is running smoothly in a production environment and provide ongoing
support.
• Activities: Monitor the system's performance, fix bugs, and provide support and maintenance to keep the
software running optimally. Address any issues reported by users.
• Outcome: A smoothly running system with minimal issues and a support team in place.

6. Retirement Phase:
• Objective: The final phase where the product is retired from active use.
• Activities: Conduct knowledge transfer, archive the project artifacts, and ensure that all data is backed up.
Notify users and stakeholders about the product's retirement.
• Outcome: Product is formally retired, and users are transitioned to alternative systems if necessary.
Key Traits of Agile Phases:
• Agile phases are not strictly sequential; they overlap, and activities from different phases can happen concurrently.
• Agile emphasizes continuous improvement through regular feedback and reflection in retrospective meetings.
• At the end of each iteration, the team evaluates its performance and identifies opportunities for improvement.

Key Characteristics of Agile Methodology

Iterative Development: Agile promotes breaking the project into small, manageable units called iterations or sprints. Each iteration typically
lasts from one to four weeks, allowing teams to deliver functional pieces of the product regularly.

Customer Collaboration: Agile emphasizes frequent collaboration with stakeholders and customers. Continuous feedback helps teams adjust
their work according to changing requirements or priorities.

Cross-Functional Teams: Agile teams are usually composed of members with various skills and expertise, allowing them to work
collaboratively and efficiently on different aspects of the project.

Emphasis on Working Software: Agile prioritizes delivering functional software over comprehensive documentation. The focus is on
producing working increments that can be tested and validated by users.

Adaptive Planning: Agile recognizes that requirements can evolve. Teams are encouraged to be flexible and adapt their plans based on
ongoing feedback and insights from stakeholders.

Continuous Improvement: Agile promotes a culture of reflection and learning, where teams regularly evaluate their processes and outcomes
to identify areas for improvement.
Core Values:
1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Principles of Agile:
The Agile Manifesto also includes 12 principles, including:
 Delivering working software frequently.
 Welcoming changing requirements, even late in development.
 Collaborating daily between business stakeholders and developers.
 Building projects around motivated individuals.
 Maintaining a sustainable pace of development.
 Regularly reflecting on how to become more effective.
Popular Agile Frameworks
Several frameworks implement Agile principles, including:
Scrum: Focuses on fixed-length sprints and defined roles (Scrum Master, Product Owner, Development Team).
Kanban: Emphasizes visualizing work, limiting work in progress, and managing flow.
Extreme Programming (XP): Focuses on technical practices and continuous integration to improve software
quality.
Lean: Aims to maximize value by minimizing waste and optimizing processes.
Backlog Refinement Work flow
Agile Meetings and Purposes
Agile methodology involves several key meetings, often referred to as "ceremonies," that are crucial for ensuring:
 Transparency
 Collaboration, and
 Continuous Improvement within a team.
Each meeting serves a specific purpose to help the team stay aligned, adapt to changes, and deliver value continuously.

Agile Methodology Meetings and Their Purpose

Sprint Planning:
Purpose: To define the goal of the upcoming sprint and determine the work that the team will commit to delivering.
Who Attends: The entire Scrum team (Product Owner, Scrum Master, and Development Team & QA Team).
Outcome: A sprint backlog that contains user stories or tasks to be completed in the sprint and a clear sprint goal.

Daily Stand-up (Daily Scrum):

Purpose: To provide a quick status update on progress and any impediments. It helps in fostering collaboration and ensuring that
the team remains on track.
Who Attends: The Development Team, Scrum Master, sometimes the Product Owner and QA Team.
Outcome: Identification of blockers and a plan for the day. It should last no longer than 15 minutes.
Sprint Review:
• Purpose: To showcase the work completed during the sprint to stakeholders and get feedback. It is an
opportunity to inspect the product increment and adapt the product backlog.
• Who Attends: The Scrum Team and key stakeholders.
• Outcome: Adjustments to the product backlog based on feedback, ensuring alignment with stakeholders.

Sprint Retrospective:
• Purpose: To reflect on the sprint and identify what went well, what didn’t, and what can be improved. It focuses
on continuous improvement.
• Who Attends: The Scrum Team.
• Outcome: Actionable items to improve processes, tools, or team dynamics in future sprints.

Backlog Refinement (Grooming) Meeting:

• Purpose: To review and refine the product backlog, ensuring that it is up-to-date and prioritized with well-
defined user stories.
• Who Attends: The Product Owner, Scrum Master, and Development Team.
• Outcome: A well-groomed backlog with prioritized user stories that are ready for upcoming sprints.
Kanban
Sprint Kickoff:
• Purpose: Similar to Sprint Planning, the sprint kickoff is used to align the team on the sprint’s goals and
planned tasks.
• Who Attends: The Scrum Team.
• Outcome: A confirmed understanding of the sprint goal and tasks.

User Story Mapping Sessions:

• Purpose: To collaboratively build a roadmap of the product, focusing on user stories and their value.
• Who Attends: Product Owner, Scrum Master, and Development Team.
• Outcome: A visual representation of user stories aligned with the product vision.
 Agile Workflow Diagram

1. Sprint Planning : Workflow Diagram:

2. Daily Scrum (Stand-up)
3. Sprint Review:
4. Sprint Retrospective
5. Backlog Refinement (Grooming):
What is User Story ?
In Agile methodology, a user story is a simple, concise description of a feature or functionality from the perspective of an end-
user or customer.
User stories are a fundamental element of Agile project management that help teams understand the value and purpose behind
a requirement, focusing on user needs rather than technical details.

Key Characteristics of a User Story

Format: User stories are typically written in a simple format that includes three key components:
1. As a [type of user]
2. I want [an action]
3. So that [a benefit or value]
Example:
"As a customer, I want to be able to track my order status so that I know when it will be delivered.”
INVEST Principle: A good user story should adhere to the INVEST principle:
• Independent: It should be self-contained and not dependent on other stories.
• Negotiable: It should provide room for discussion and refinement.
• Valuable: It should deliver value to the end user.
• Estimable: It should be estimable for effort.
• Small: It should be small enough to be completed within a sprint.
• Testable: It should have clear acceptance criteria for testing.

Part of the Product Backlog:

• User stories are maintained in the product backlog, where they are prioritized by the Product Owner based on their value to
the user and the overall goals of the project.

Why Use User Stories?

• Enhanced Communication: User stories encourage conversations between developers, testers, and stakeholders to ensure a
shared understanding of the requirements.
• Focus on User Needs: They help keep the team focused on delivering value from the user's perspective rather than getting
lost in technical specifications.
• Flexibility and Adaptability: User stories are brief and can be easily adapted as more information is available or as project
priorities change.
Conclusion:

These Agile meetings ensure that teams work together effectively, remain transparent,
continuously improve, and deliver high-quality products that meet stakeholders' needs.
 Definition of Done in Agile Methodology
In Agile methodology, the Definition of Done (DoD) is a shared understanding within a Scrum team that outlines
the criteria that must be met for a product backlog item (such as a user story, feature, or task) to be considered
complete.
It ensures transparency, quality, and consistency across the development process.
Key Elements of the Definition of Done (DoD)
1. Clear and Specific Criteria:
 The DoD specifies clear, measurable criteria that must be fulfilled before any piece of work is marked as done.
This could include:
 Code is written, reviewed, and merged.
 Unit tests are written and passed.
 Integration tests are conducted.
 Documentation is updated.
 The feature is deployed to a staging environment and validated.
2. Quality Assurance:
• Ensures that all quality standards are met before delivery. This may include code quality checks, testing
requirements, compliance standards, and more.
3. Consistency Across Teams:
• Provides a consistent standard across the team or organization, ensuring that "done" means the same thing for
everyone. This prevents misunderstandings or discrepancies when delivering increments of the product.
4. Acceptance Criteria Met:
• For a user story or feature to be done, all acceptance criteria defined by the Product Owner must be met and
verified by the team.
5. Potentially Shippable Product Increment:
• In Scrum, each sprint should result in a potentially shippable product increment. The DoD helps ensure that the
increment is complete and could be released to customers without additional work.
Benefits of the Definition of Done
1. Improved Quality:
• Establishes a high standard of quality, reducing the likelihood of defects and ensuring that every increment meets the
expected quality levels.
2. Enhanced Transparency:
• Promotes transparency within the team and stakeholders by defining what "done" means, ensuring that everyone has
the same understanding.
3. Predictable Velocity:
• With a clear DoD, the team can better estimate and predict their velocity (the amount of work they can complete in a
sprint) as the criteria for "done" is standardized.
4. Better Focus:
Helps the team stay focused on completing work fully rather than leaving tasks partially completed or "almost done."
Example of a Definition of Done
Code written, reviewed, and merged.
Unit tests with at least 80% coverage are written and passed.
Integration tests are run and passed.
Feature is tested in a staging environment.
Documentation (user and technical) is updated.
Code complies with security and regulatory requirements.
Very Important Topic on Entry | Exit Criteria
Q

&

Thanks