Chapter 1

Fundamentals of Software development Systems

---------------------------------------------------------------------------------------------------------------------

1.1 Software development evolution

1. Code-Centric Beginnings (1940s–1960s)

Initially, software development had no formal frameworks. Developers worked directly with machine and assembly
languages, focusing on hardware operations. The absence of structured processes led to challenges in scalability and
maintenance, but these approaches laid the groundwork for formal methodologies.

2. Structured Frameworks (1970s–1980s)

With increasing complexity in software projects, structured approaches like the Waterfall model emerged. These
frameworks introduced a sequential process divided into clear phases: requirements gathering, design, coding,
testing, and deployment. Documentation became a cornerstone, ensuring clarity and consistency across teams.
However, the rigidity of these models made them unsuitable for dynamic requirements.

3. Iterative and Incremental Frameworks (1980s–1990s)

To address the limitations of structured frameworks, iterative models were developed. These approaches emphasized
delivering software in smaller increments, allowing feedback and adjustments throughout the project lifecycle. Risk
management became a focus, with models like the Spiral emphasizing iterative refinement of requirements and
solutions.

4. Agile Frameworks (2000s–Present)

The Agile Manifesto revolutionized software development by prioritizing adaptability, collaboration, and iterative
progress. Frameworks like Scrum and Kanban emerged, encouraging cross-functional teamwork and frequent
delivery of working software. Agile frameworks replaced exhaustive documentation with dynamic, customer-
focused processes, enabling rapid adaptation to change.

5. DevOps and Continuous Integration Frameworks (2010s–Present)

The rise of DevOps bridged the gap between development and operations, fostering automation and collaboration.
Continuous Integration and Continuous Deployment (CI/CD) pipelines became integral, ensuring rapid and reliable
software releases. This era prioritized automation, scalability, and seamless delivery in response to modern software
demands.

A Software Development Life Cycle (SDLC) is a structured process or framework that outlines the steps and stages
involved in designing, creating, testing, and maintaining software applications. It helps ensure that software is
developed efficiently, with quality, and in a predictable manner from start to finish.

Over the last 50 years, we have seen two main types of SDLCs.

 Waterfall
Waterfall is probably the most traditional software development life cycle, and it's based on a linear process
following the concept, design, build, and deploy approach.

The main actors of the waterfall development process are:

 Stakeholders/Product Manager: focused on defining the product strategy, aligning it with business goals,
and ensuring the product's success in the market.
 Engineering Manager: focused on managing the engineering team, ensuring efficient project execution,
fostering a productive team environment, and facilitating communication within and outside the team.
 Engineering Team: focused on developing the product following the directions of the roles above.

While there's nothing wrong with the waterfall approach (and there are certainly companies that still use it), the need
for more flexibility, speed, and adaptability soon arose.

 Agile

Agile Software Development was born as an answer to this demand of speed and flexibility. While it shares some
similarities with traditional waterfall development from a technical perspective, it is fundamentally based on
adaptive iterations and embraces a more flexible and customer-centric approach.

The trade-off for this agility was the need to identify new roles that could help Product Management keep pace and
understand both the development process and the technology.

That's why for Scrum, probably the most famous Agile Framework, the main actors are the same as waterfall, with
two main additions:

 Product Owners: focused on representing the user and business needs within the development team,
defining and prioritizing the product backlog, and ensuring the product is built according to requirements.
 Scrum Masters: A Scrum Master is like a coach for a team that works on projects. They help the team
follow the "Scrum" rules, which are like a game plan for getting work done efficiently and well.

1.2 Overview of traditional software development framework

A traditional software development framework refers to a structured, sequential approach for building software.
It focuses on meticulous planning, clearly defined stages, and extensive documentation. Below is an overview of the
key aspects and components of traditional frameworks:

 Characteristics of Traditional Frameworks

 Sequential and Predictable: Each stage follows a fixed order, with minimal room for changes once a
phase is complete.
 Extensive Documentation: Every phase is thoroughly documented, including requirements, designs, test
plans, and maintenance guidelines.
 Time-Consuming: Rigid processes make the framework ideal for projects with clearly defined goals but
less suitable for rapidly changing environments.
 Examples: The Waterfall model is the most prominent example of a traditional framework.
  Phases in Traditional Software Development Framework

1. Requirement Analysis

 Goal: Understand and document what the software must achieve.

 Activities:
o Stakeholder meetings to gather requirements.
o Creating Software Requirement Specifications (SRS) documents.
 Output: A detailed requirements document.

2. System Design

 Goal: Plan the architecture and design of the software.

 Activities:
o High-level design (HLD) to define system architecture.
o Low-level design (LLD) for module-specific details.
 Output: System design documents and diagrams.

3. Implementation (Coding)

 Goal: Convert designs into working code.

 Activities:
o Developers write code based on design documents.
o Use of programming standards and best practices.
 Output: Source code for the software.

4. Testing

 Goal: Ensure the software meets requirements and is free from defects.
 Activities:
o Unit testing, integration testing, system testing, and acceptance testing.
o Use of test cases derived from requirements.
 Output: A tested software product, ready for deployment.

5. Deployment

 Goal: Install and configure the software in the production environment.

 Activities:
o Software deployment on servers or user systems.
o Training users, if needed.
 Output: Live software, accessible to end users.

6. Maintenance

 Goal: Address bugs, make improvements, and ensure software longevity.

 Activities:
o Bug fixing and performance optimization.
 o Handling user-reported issues.
 Output: Updates and patches to keep the software functional.

 Advantages of Traditional Frameworks

 Clear Structure: Defined phases make it easy to manage and track progress.
 Thorough Documentation: Useful for long-term maintenance and knowledge transfer.
 Predictable Outcomes: Suitable for projects with well-understood, stable requirements.

 Disadvantages of Traditional Frameworks

 Inflexibility: Changes in requirements are difficult to incorporate after the project starts.
 Delayed Feedback: Testing occurs late in the process, delaying issue detection.
 High Risk: Misinterpreted requirements may not be discovered until late stages.

 Use Cases

Traditional frameworks are suitable for:

 Projects with fixed and well-defined requirements.

 Domains like government, defense, or regulated industries, where documentation and predictability are
crucial.

1.3 Waterfall model

The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle
model. It is very simple to understand and use. In a waterfall model, each phase must be completed fully before the
next phase can begin. This type of software development model is basically used for the project which is small and
there are no uncertain requirements. At the end of each phase, a review takes place to determine if the project is on
the right path and whether or not to continue or discard the project. In this model software testing starts only after
the development is complete. In waterfall model phases do not overlap.

Phases of the Waterfall model

When used for complex projects, such as software development, the Waterfall development methodology has seven
stages:

1. Requirements. Potential project requirements, deadlines and guidelines for the project are analyzed and placed
into a formal requirements document, also called a functional specification. This first phase of development
defines and plans the project without mentioning specific processes. It also defines the project scope, team
members, stakeholders, process for requirements gathering, reporting of project progress, use of aids such as
templates and workflow diagrams, and an overall roadmap of the project.

2. Analysis. The system specifications are analyzed to generate product models and business logic to guide
production. This is also when financial and technical resources are audited for feasibility.

3. Design. A design specification document is created to outline technical requirements during the design phase.
These include the programming language, hardware, data sources, architecture and services.
4. Coding and implementation. The source code is developed using the models, logic and requirement
specifications designated in the previous phases. Typically, the system is coded in smaller components, or units,
before being put together.

5. Testing. This is when quality assurance and unit, system and beta tests identify issues that must be resolved.
This forces a repeat of the coding stage for debugging. If the system passes integration and testing, the
Waterfall process continues forward.

6. Operation and deployment. The product or application is deemed fully functional and is deployed to a live
environment.

7. Maintenance. Corrective, adaptive and perfective maintenance is carried out indefinitely to improve, update
and enhance the product and its functionality. This could include releasing patch updates and new versions.

Advantages of waterfall model:

 Simplicity: Easy to understand and implement due to its linear structure.

 Documentation: Detailed documentation ensures clarity and aids maintenance.
 Predictability: Clear milestones and deliverables for each phase.
 Suitable for Stable Requirements: Ideal for projects with well-defined and unchanging requirements.

This model is simple and easy to understand and use. It is easy to manage due to the rigidity of the model – each
phase has specific deliverable s and a review process. In this model phases are processed and completed one at a
time. Phases do not overlap. Waterfall model works well for smaller projects where requirements are very well
understood.

Disadvantages of waterfall model:

 Inflexibility: Difficult to accommodate changes once a phase is completed.

 Late Testing: Defects are often discovered late in the process, increasing costs.
 High Risk: If requirements are misunderstood early on, the final product may not meet user needs.

 Inefficiency: Each phase must be completed fully before moving to the next, even if changes are needed.

Once an application is in the testing stage, it is very difficult to go back and change something that was not well-
thought out in the concept stage. No working software is produced until late during the life cycle. High amounts of
risk and uncertainty. Not a good model for complex and object-oriented projects. Poor model for long and ongoing
projects. Not suitable for the projects where requirements are at a moderate to high risk of changing.

When to use the waterfall model:

This model is used only when the requirements are very well known, clear and fixed. Product definition is stable.
Technology is understood. There are no ambiguous requirements ample resources with required expertise are
available freely. The project is short. Very less customer interaction is involved during the development of the
product. Once the product is ready then only it can be demoed to the end users. Once the product is developed and if
any failure occurs then the cost of fixing such issues are very high, because we need to update everywhere from
document till the logic.

1.4 Introduction to Agile Methodology

The Agile Methodology is a modern software development approach that emphasizes flexibility, collaboration, and
continuous delivery. It focuses on iterative progress through incremental releases, allowing teams to adapt quickly to
changes and deliver value faster to stakeholders. Agile was officially formalized with the Agile Manifesto in 2001,
which outlined its principles and values. Agile is not a single process but a collection of methodologies and practices
that share common principles, including:

 Incremental Development: Breaking the project into small, manageable units (increments).
 Iterative Approach: Repeating development cycles to refine and improve the product.
 Collaborative Teamwork: Encouraging constant communication between developers, testers, and
stakeholders.
 Customer-Centric: Prioritizing customer satisfaction through early and continuous delivery of valuable
software.

 Core Principles of Agile

The Agile Manifesto is based on four core values and twelve principles:

 Four Core Values

1. Individuals and Interactions over Processes and Tools: Focus on people and communication rather than
rigid adherence to tools and procedures.
2. Working Software over Comprehensive Documentation: Deliver functional software quickly instead of
spending excessive time on documentation.
3. Customer Collaboration over Contract Negotiation: Engage customers throughout the project, ensuring
their needs are continuously met.
4. Responding to Change over Following a Plan: Adapt to changes rather than sticking strictly to
predefined plans.

 Twelve Principles

 Deliver valuable software frequently, with a preference for shorter timescales.

 Welcome changing requirements, even late in development.
 Maintain close collaboration between developers and business stakeholders.
 Build projects around motivated individuals, providing them the environment and support they need.
 Face-to-face communication is the most effective way of conveying information.
  Deliver working software as the primary measure of progress.
 Agile processes promote sustainable development.
 Continuous attention to technical excellence and good design enhances agility.
 Simplicity—the art of maximizing work not done—is essential.
 Self-organizing teams produce the best architectures, requirements, and designs.
 Regularly reflect on how to become more effective and adjust accordingly.

 Key Features of Agile Methodology

1. Iterative and Incremental Development: Agile breaks projects into smaller parts called iterations or
sprints, each delivering a functional increment of the product.
2. Flexibility and Adaptability: Agile allows requirements to evolve as the project progresses, making it
ideal for dynamic environments.
3. Collaboration and Communication: Agile teams work closely with stakeholders, ensuring transparency
and alignment.
4. Continuous Delivery: Delivering working software at regular intervals ensures faster feedback and value
realization.
5. Customer Involvement: Frequent feedback from customers ensures the product meets their expectations.

 Popular Agile Frameworks

Agile is implemented through various frameworks, each tailored to specific project needs:

1. Scrum
o Uses sprints (time-boxed iterations) and roles like Scrum Master and Product Owner.
o Focuses on regular meetings (e.g., daily stand-ups) and retrospective analysis.
2. Kanban
o Emphasizes visualizing workflow and limiting work in progress.
o Continuous delivery with no strict time-boxed iterations.
3. Extreme Programming (XP)
o Focuses on technical excellence and practices like pair programming and test-driven development
(TDD).
4. Lean Software Development
o Minimizes waste, optimizes value, and enhances team productivity.
5. Scaled Agile Framework (SAFe)
o Extends Agile principles to large, complex projects involving multiple teams.

 Benefits of Agile Methodology

1. Improved Flexibility: Agile adapts to changes in requirements or priorities, ensuring relevance.

2. Faster Time-to-Market: Incremental deliveries mean faster releases of functional software.
3. Higher Customer Satisfaction: Continuous feedback and collaboration ensure that customer needs are
met.
4. Better Team Collaboration: Agile fosters open communication and a sense of ownership among team
members.
5. Reduced Risk: Early and frequent delivery of working software minimizes the risk of complete project
failure.
6. Improved Quality: Iterative testing and refinement ensure higher-quality outputs.
  Challenges of Agile Methodology

1. Cultural Shift: Agile requires significant changes in team dynamics, communication, and management.
2. Less Predictability: The lack of fixed timelines and deliverables can be challenging for stakeholders who
prefer certainty.
3. Requires Skilled Teams: Agile demands cross-functional, self-organized teams with a high level of
expertise.
4. Scalability Issues: Adapting Agile for large organizations or projects can be complex without frameworks
like SAFe.

When to Use Agile

 Projects with frequently changing requirements.

 Environments where collaboration and customer feedback are critical.
 Situations requiring rapid delivery of functional components.

1.5 Agile vs. Traditional Waterfall model

Aspect Agile Model Waterfall Model

Iterative and incremental

Approach Sequential and linear process
development

Highly flexible; changes can be Rigid; changes are difficult after

Flexibility
made at any stage the process starts

Customer Continuous customer involvement Customer involved mainly at the

Involvement throughout development beginning and end

Phases run concurrently Phases run sequentially (design,

Project Phases
(development, testing, etc.) development, testing)

Risks identified and mitigated Risks identified during planning;

Risk Management
continuously harder to address later

Frequent, incremental releases or Single final product delivery at the

Delivery
updates end

Continuous testing with each Testing happens after the

Testing
iteration development phase

Requirements evolve and can Fixed requirements defined at the

Requirements
change during the project beginning

Team Cross-functional team collaboration Teams work in silos with less

Collaboration and communication collaboration
 Aspect Agile Model Waterfall Model

Suitable for complex, evolving Suitable for smaller, well-defined

Project Size
projects projects

Lightweight documentation, evolves Comprehensive documentation

Documentation
with the project upfront

Adaptive, timelines can change Fixed timeline based on the

Timeframe
based on iterations project plan

Customer Immediate feedback during Feedback is received after the

Feedback development cycles project is complete

Fixed budget once the project

Budget Can vary based on project changes
scope is defined

1.6 Introduction to Agile Framework

An Agile Framework is a set of methods and practices based on the principles of Agile methodology, designed to
guide teams in implementing Agile effectively. These frameworks provide structure while maintaining the flexibility
and adaptability central to Agile, enabling teams to deliver high-quality software quickly and efficiently. Agile
frameworks aim to break down complex projects into smaller, manageable cycles that prioritize customer feedback,
collaboration, and incremental delivery.

Key Features of Agile Frameworks

1. Iterative Development: Work is divided into smaller iterations or increments, allowing for continuous
improvement and adaptation.
2. Customer Collaboration: Direct and frequent engagement with stakeholders ensures alignment with
evolving needs.
3. Team Empowerment: Agile frameworks promote self-organized and cross-functional teams to foster
innovation and ownership.
4. Frequent Deliverables: Delivering functional software at regular intervals provides early value to
customers and stakeholders.
5. Flexibility: Agile frameworks support evolving requirements, even late in development.
6. Transparency: Regular reviews, planning, and open communication ensure all stakeholders remain
informed.

Popular Agile Frameworks

1. Scrum
o Focuses on time-boxed iterations called sprints (typically 2-4 weeks).
o Key roles include the Product Owner, Scrum Master, and Development Team.
o Emphasizes daily stand-ups, sprint planning, and retrospectives.
2. Kanban
 o Visualizes work on a Kanban board with columns like "To Do," "In Progress," and "Done."
o Focuses on limiting work in progress (WIP) to improve flow and efficiency.
o No fixed iteration cycles, enabling continuous delivery.
3. Extreme Programming (XP)
o Stresses engineering practices such as test-driven development (TDD), pair programming, and
continuous integration.
o Aims for high-quality code and frequent releases.

Benefits of Agile Frameworks

 Flexibility and Adaptability: Enables teams to respond to changes quickly.

 Customer Satisfaction: Frequent releases and feedback cycles ensure alignment with customer needs.
 Continuous Improvement: Iterations encourage teams to learn and improve over time.
 Transparency and Communication: Regular meetings and open collaboration foster trust and
accountability.
 Early Delivery of Value: Incremental delivery ensures faster realization of business value.

Challenges of Agile Frameworks

 Requires Skilled Teams: Agile relies on highly capable, self-organized teams.

 Complexity in Scaling: Applying Agile to large projects or organizations requires additional effort and
frameworks like SAFe.
 Cultural Shift: Transitioning from traditional methods to Agile can be challenging for teams accustomed
to hierarchical structures.
 Stakeholder Involvement: Agile demands continuous engagement from stakeholders, which can be
resource-intensive.

1.7 Key Roles in Agile

Agile teams are often comprised of the following key roles and responsibilities:

Let’s take a look at each.

Product owner: The product owner represents the stakeholders of the project. The role is primarily responsible for
setting the direction for product development or project progress. The Product Owner understands the requirements
of the project from a stakeholder perspective and has the necessary soft skills to communicate the requirements to
the product development team. The Product Owner also understands the long-term business vision and aligns the
project with the needs and expectations of all stakeholders. End-user feedback is taken into account to determine
appropriate next-best action plans for the development throughout the project cycle.

The key responsibilities of a Product Owner include:

 Scrum backlog management

 Release management
 Stakeholder management

The Product Owner is knowledgeable of the backlog items added to the list as well as items selected for work. The
Product Owner changes and sets the priority of backlog item list based on stakeholder feedback and project
circumstances. The role also manages the release cycle planning to ensure that the development team can deliver
updated project iterations on a continuous basis.
Finally, the Product Owner ensures that product development translates into value for the stakeholders.
Communication with end-users, business executives, partners and the development team is therefore a key
responsibility.

Team lead/Scrum master

The Team Lead or Scrum Master ensures team coordination and supports the progress of the project between
individual team members. The Scrum Master takes the instructions from the Product Owner and ensure that the
tasks are performed accordingly.

The role may involve:

 Facilitating the daily Scrum and Sprint initiatives

 Communicating between team members about evolving requirements and planning
 Coaching team members on delivering results
 Handling administrative tasks such as conducting meetings, facilitating collaboration, and eliminating hurdles
affecting project progress
 Shielding team members from external interferences and distractions

The role is also responsible to manage external coordination with the organization and the Product Owner to ensure
effective implementation of the Scrum framework. The responsibilities may include:

 Implementing changes
 Coordinating between stakeholders to find necessary resources
 Helping Product Owners optimize the backlog planning for optimum performance
The role of a Scrum Master is focused on attributes such as transparency across the Scrum Team, self-organization,
commitment, respect and most importantly, following an empirical process to identify the best approach for product
development.

Development team members

The team members within the Development Team are comprised of individuals with responsibilities including but
not limited to product development. The team takes cross-functional responsibilities necessary to transform an idea
or a requirement into a tangible product for the end-users. The required skills might be wrapped up in one or more
dev team members:

 Product designer
 Writer
 Programmer
 Tester
 UX specialist

Not every member may be an engineer, but may be a part of the team if their skills are required for the project to
proceed at the required pace. In addition to the skills facilitating product development, the team members should
also boast soft skills that would enable them to self-organize and get the work done. This means that when an issue
occurs, the team is both capable and empowered to take corrective actions. The key responsibilities of the
Development Team are to perform work sprints as per the requirements provided by the Product Owner and
coordinated by the Scrum Master. A regular standup meeting called the Daily Scrum is followed to communicate
project progress with the peers and the Scrum Master. This activity ensures transparency and allows the
Development Team to incorporate the changes as necessary in future sprints based on feedback from the Product
Owner.

Stakeholders
The Stakeholder position may not be directly involved in the product development process but is used to represent
a range of key roles that impact the decisions and work of the Scrum team. The stakeholder may be:

 The end user of the product

 Business executives
 Production support staff
 Investors
 External auditors
 Scrum team members from associated projects and teams

Input from the Stakeholders is key to direct the progress of the project in different directions to align product
development with business goals, end-user expectations as well as addressing challenges facing the Scrum
Development Team.

Additional roles for larger Scrum projects

In addition to these typical roles of the Scrum team, large enterprises working on large projects may include more
roles into the Scrum teams. These can include:

 Technical and domain experts with the knowledge of technology as well as a wide variety of stakeholder
requirements or expectations.
 An independent testing and audit team may join the Scrum team members and work throughout the product
development lifecycle.
 An Integrator may be required among large teams that work on independent but closely coordinated
subsystems for a project. The responsibility for the Integrator would include integration of the subsystems as
well as testing that may be performed by external testing teams.
 An Architect Owner may be required for architectural envisioning, planning and decision making.

1.8 Scrum

Scrum is a lightweight, time-boxed, and iterative framework that helps teams deliver value incrementally. It divides
the work into small, manageable cycles called sprints, enabling teams to inspect, adapt, and continuously improve.

Scrum is based on three pillars:

1. Transparency: Everyone involved has visibility into the processes and progress.
2. Inspection: Frequent reviews help detect issues and opportunities for improvement.
3. Adaptation: Teams adjust their approach based on feedback and lessons learned.

Key Components of Scrum

1. Scrum Roles

Scrum defines three primary roles, often referred to as the Scrum Team:

 Product Owner (PO): Responsible for maximizing the product's value by managing the Product Backlog
and ensuring the team works on the most valuable items.
 Scrum Master: Facilitates the Scrum process, removes impediments, and ensures the team adheres to
Scrum principles.
 Development Team: A cross-functional group responsible for delivering a potentially shippable product
increment at the end of each sprint.

2. Scrum Events

Scrum follows a defined set of events that structure the process:

1. Sprint: A time-boxed iteration (typically 1-4 weeks) during which a potentially releasable product
increment is developed.
2. Sprint Planning:
o Objective: Define the sprint goal and determine which Product Backlog items will be completed
during the sprint.
o Participants: Scrum Team.
3. Daily Scrum:
 o A 15-minute stand-up meeting held daily to synchronize progress and identify obstacles.
o Questions addressed:
 What did I accomplish yesterday?
 What will I do today?
 Are there any blockers?
4. Sprint Review:
o Held at the end of the sprint to demonstrate completed work to stakeholders.
o Includes feedback for potential improvements.
5. Sprint Retrospective:
o A meeting after the Sprint Review to reflect on what went well, what could improve, and
actionable steps for the next sprint.

3. Scrum Artifacts

1. Product Backlog:
o A prioritized list of features, tasks, or requirements for the product maintained by the Product
Owner.
o Items are refined and detailed over time through backlog refinement sessions.
2. Sprint Backlog:
o A subset of the Product Backlog selected for a sprint, along with a plan to deliver the sprint goal.
3. Increment:
o The sum of all completed Product Backlog items during the sprint, representing a potentially
releasable version of the product.

Scrum Workflow

1. Start of Sprint: Sprint planning occurs, and a sprint backlog is created.

2. During Sprint:
o The team works on selected items.
o Daily Scrum meetings track progress and address challenges.
3. End of Sprint:
o Completed work is demonstrated in the Sprint Review.
o Team reflects on the process in the Sprint Retrospective.
o Feedback is incorporated into the next sprint.

Key Principles of Scrum

 Empirical Process Control: Decisions are based on observation, experience, and experimentation.
 Self-Organizing Teams: Teams decide how best to accomplish tasks.
 Value-Driven Development: Focuses on delivering value incrementally.
 Time-Boxing: Events and sprints are constrained by a fixed duration.
 Continuous Improvement: Feedback loops allow for regular adjustments.

Benefits of Scrum

1. Improved Flexibility: Adaptable to changing requirements.

2. Enhanced Collaboration: Promotes teamwork and stakeholder involvement.
3. Faster Delivery: Incremental delivery ensures quicker realization of value.
 4. Higher Quality: Continuous inspection and adaptation enhance product quality.
5. Transparency: Stakeholders and teams have clear visibility into progress and challenges.

Challenges of Scrum

1. Requires Discipline: Success depends on the team's commitment to Scrum principles.

2. Team Dependency: Effective Scrum requires cross-functional and self-organized teams.
3. Scaling Issues: Complex projects may require additional frameworks like SAFe or LeSS.
4. Stakeholder Engagement: Demands frequent involvement, which can be resource-intensive.

When to Use Scrum

 Projects with evolving requirements where customer feedback is critical.

 Complex or innovative projects that need incremental and iterative progress.
 Teams looking to improve collaboration, transparency, and adaptability.

1.13 Sprint Planning

Sprint Planning is a crucial event in the Scrum framework, occurring at the beginning of every sprint. It sets the
stage for the work the team will focus on during the sprint and ensures alignment with the overall product vision and
objectives. The goal of Sprint Planning is to define what will be delivered in the upcoming sprint and how it will be
achieved.

Key Objectives of Sprint Planning

1. Define the Sprint Goal: The Sprint Goal is the primary objective of the sprint, a concise statement that
describes the desired outcome or the value to be delivered by the end of the sprint.
2. Select Product Backlog Items: The team selects a set of items from the Product Backlog that they aim to
complete during the sprint. These items are typically in the form of user stories or tasks.
3. Create the Sprint Backlog: The selected items are then broken down into tasks, and a plan is formed to
complete them. This results in the Sprint Backlog, a list of work items the team commits to completing.

Steps in Sprint Planning

1. Review the Product Backlog

 The Product Owner presents the Product Backlog, which contains the highest-priority items for the
product.
 The team asks questions to ensure a clear understanding of each backlog item.
 The Product Owner may clarify any doubts, such as acceptance criteria, priority, or business value.

2. Define the Sprint Goal

 Based on the selected Product Backlog items, the team agrees on a Sprint Goal, which provides focus and
direction.
 The Sprint Goal should be a clear, concise, and achievable statement that reflects the desired outcome of
the sprint.

3. Select Items for the Sprint Backlog

  The team collaborates with the Product Owner to decide which Product Backlog items (e.g., user stories,
features, or tasks) to include in the Sprint Backlog.
 The team considers their capacity (e.g., team size, skills, and availability) and the priority of items.
 Each selected item is broken down into smaller, more manageable tasks.

4. Task Breakdown and Estimation

 The team discusses how each item will be implemented and defines the tasks required to complete it.
 The Development Team estimates the effort involved in completing the tasks (using estimation techniques
such as story points, hours, or ideal days).

5. Commit to the Sprint Backlog

 After tasks are estimated, the team commits to completing the selected items within the sprint.
 The commitment is based on the team’s capacity and the agreed-upon effort for the sprint.

6. Final Review and Adjustments

 The Scrum Master ensures that the Sprint Planning meeting is productive and that the team has a clear,
actionable plan for the sprint.
 The Sprint Backlog is finalized, and the Sprint Goal is clearly communicated to all team members.

 Significance of scrum for Agile methodology

Scrum is an agile framework used for managing and executing complex projects, particularly in software
development. It emphasizes collaboration, flexibility, and iterative progress. Here’s a brief overview of its key
components and principles:

Key Components

1. Roles:
o Product Owner: Responsible for defining the product vision and managing the product backlog.
They prioritize the work that needs to be done to maximize value.
o Scrum Master: Facilitates the Scrum process, removes obstacles, and ensures that the team
follows Scrum practices. They serve as a coach for the team and the organization.
o Development Team: A self-organizing group of professionals who work together to deliver
potentially shippable product increments. They are cross-functional and responsible for their own
work.
2. Artifacts:
o Product Backlog: A prioritized list of features, enhancements, bug fixes, and technical tasks
required for the product. It is dynamic and evolves as the project progresses.
o Sprint Backlog: A subset of the product backlog selected for a specific sprint. It contains the
tasks the team commits to completing during the sprint.
o Increment: The sum of all completed product backlog items at the end of a sprint, representing a
potentially shippable product.
3. Events:
 o Sprint: A time-boxed iteration, usually lasting 1 to 4 weeks, during which the development team
works to complete the sprint backlog. Each sprint begins with a planning session and ends with a
review and retrospective.
o Sprint Planning: A meeting at the beginning of each sprint where the team selects items from the
product backlog to work on and defines the sprint goal.
o Daily Scrum: A short, time-boxed meeting (usually 15 minutes) held every day for the
development team to synchronize and discuss progress, challenges, and plans for the day.
o Sprint Review: A meeting held at the end of a sprint where the team demonstrates what they have
built and discusses feedback from stakeholders.
o Sprint Retrospective: A meeting held after the sprint review where the team reflects on the
sprint, identifies areas for improvement, and discusses actionable steps to enhance their processes.

Scrum Process Flow

1. Product Backlog Creation: The Product Owner creates and maintains the product backlog, ensuring it
reflects stakeholder needs and priorities.
2. Sprint Planning: At the start of each sprint, the team conducts sprint planning to select items from the
product backlog to work on. They establish a sprint goal and define tasks to achieve it.
3. Daily Scrums: Throughout the sprint, the development team holds daily scrums to synchronize work,
address challenges, and adapt plans as necessary.
4. Development Work: The team works on completing the tasks in the sprint backlog, collaborating closely
to build the increment.
5. Sprint Review: At the end of the sprint, the team presents the completed work to stakeholders, gathers
feedback, and discusses any changes needed for future sprints.
6. Sprint Retrospective: After the sprint review, the team reflects on their processes, identifies strengths and
weaknesses, and plans improvements for the next sprint.

Key Principles

 Iterative Development: Work is done in small, manageable increments, allowing for regular feedback and
adjustments.
 Collaboration: Team members work closely together, fostering open communication and teamwork.
 Flexibility: The framework allows teams to adapt to changes in requirements or priorities throughout the
project.
Important Questions

 Explain in brief Waterfall model of Software Development

 Compare between Agile vs. Traditional Waterfall model

 Explain the traditional software development framework

 What are the Key Roles in Agile framework

 What are the Steps in Sprint Planning? Explain them in detail

 Explain Scrum in detail.

 Describe the significance of scrum for Agile methodology with respect to their Components (like Roles,
Artifacts and Events) and Process Flow