Agile Software Development

Process (22B12CS414)
Lecture 1
Detailed Syllabus

Dr. Amarjeet Prajapati

(Assistant Professor)
Course Code 22B12CS414 Semester Semester: VIIIth Session
Even 2021 -2022
(specify Month from January to
Odd/Even) February
Course Name Agile Software Development Process
Credits 3 Contact Hours 3

Faculty Coordinator(s) Dr Amarjeet Prajapati

(Names)
Teacher(s) (Alphabetically)
Dr Amarjeet Prajapati
 COGNITIVE
COURSE OUTCOMES
LEVELS
Interpret the trade-offs between traditional software
development methods and agile software development Understand level
CO1
methods for a software project effectively. (Level 2)

Identify and make use of an appropriate agile software

engineering approach viz. extreme programming, Apply Level
CO2 Scrum, Crystal techniques as a part of software (Level3)
development.
Apply Refactoring techniques on source code for Apply Level
CO3 improved design (Level3)
Choose tools and construct the methods for testing Apply level
CO4 Agile projects using various testing strategies (Level3)
List the Planning, tracking, estimation and monitoring
of agile projects with techniques like burn down Analyze level
CO5
charts, velocity calculation and task boards etc. (level4)
Mo Title of the Topics in the Module Lect
dul Module ures
e
1. Introduction Traditional software development methods, Agile software development 3
methods and lean software development methods
2. Agile Agile manifesto, Agile principles, Characteristics of Agile processes, an 3
Fundamentals iterative development process, Pros and cons of incremental development
and software prototyping.
3. Requirements User stories, agile estimation, planning techniques- Prioritizing Themes, 4
and Planning Financial prioritization, prioritizing desirability
4. Scrum Introduction, Scrum - Prioritizing, Estimating, and Planning, The Scrum 5
Experience (hands-on exercise)
5. Extreme Extreme Programming Values, Principles and Practices, Pair programming, 5
Programming Embracing change, incremental change
6. Crystal Crystal methodologies: project categories, complexity, family members, 4
Crystal’s seven properties, Crystal clear development process cycle, Crystal
yellow, crystal orange and crystal orange web.
7. Kanban The principles of kanban, Improving process with kanban, Measure and 4
manage flow, Emergent behavior
8. Feature-Driven Processes of feature driven development, practices and progress in FDD 2
Development
9. Testing Agile testing strategy, automated unit test, test plan, test driven 5
development, alpha, beta and acceptance testing
10. Refactoring Bad smells in code, properties of refactoring, refactoring examples, benefits, 7
cost and risk of refactoring
Total number of Lectures 42
Recommended Reading material: Author(s), Title, Edition, Publisher, Year of Publication
etc. ( Text books, Reference Books, Journals, Reports, Websites etc. in the IEEE format)

1. Cohn, Mike. Agile estimating and planning. Pearson Education

Beck, Kent. Extreme programming explained: embrace change. Addison-wesley
2. professional

Martin, Robert C. Agile software development: principles, patterns, and practices.

3. Prentice Hall.

Shore, James. The Art of Agile Development: Pragmatic guide to agile software
4. development. " O'Reilly Media, Inc.".

5. Schwaber, Ken. Agile project management with Scrum. Microsoft press

Stellman, Andrew, and Jennifer Greene. Learning agile: Understanding scrum, XP,
6. lean, and kanban. " O'Reilly Media, Inc."

Cohn, Mike. User stories applied: For agile software development. Addison-Wesley
7. Professional
Evaluation Criteria
Components Maximum Marks
T1 30
End Semester Examination 40
TA 30 Attendance (10) + Assignment/Quiz/Mini-project
Total 100

Project based learning: Each student in a group of 3-4 have to work on a

mini-project, in which they will identify a real-life problem and develop the solution
by applying their knowledge of search-based software engineering approach. The
project implementation can be in any programming language preferably along with
well documentation on different aspects of the software. This enhances the
understanding of students towards different concepts of search-based software
engineering approach and also helps them during their employability.
Questions??
Agile Software Development
Process (22B12CS414)
Lecture 2
Traditional software development
methods

Dr. Amarjeet Prajapati

(Assistant Professor)
What is Software? Software is:
1. Instructions (computer programs) that when executed
provide desired features, function, and performance
2. Data structures that enable the programs to
adequately manipulate information and
3. Documentation that describes the operation and use
of the programs.

Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides

copyright 2009 by Roger Pressman.
1. Program: Program is a combination of
source code & object code.
2. Documentation: Documentation consists of
different types of manuals. For example Data
Flow Diagram, Flow Charts, ER diagrams, etc.
3. Operating Procedures: Operating
Procedures consist of instructions to set up and
use the software system and instructions on how
react to the system failure. For example:
installation guide, Beginner's guide, reference
guide, system administration guide, etc.
A software process is the set of activities and associated outcome
that produce a software product. Software engineers mostly carry
out these activities.
There are four basic key process activities:

Software Specifications – In this process, detailed description of a software

system to be developed with its functional and non-functional requirements.

Software Development –In this process, designing, programming,

documenting, testing, and bug fixing is done.

Software Validation –In this process, evaluation software product is done to

ensure that the software meets the business requirements as well as the end
users needs.

Software Evolution – It is a process of developing software initially, then

timely updating it for various reasons.
Software Process Model
A software process model is an abstraction of the actual process, which is being
described. It can also be defined as a simplified representation of a software
process. Each model represents a process from a specific perspective.

Generic Process Framework

1. Communication – Involves communication among the customer and other
stake holders; encompasses requirements gathering

2. Planning – Establishes a plan for software engineering work; addresses

technical tasks, resources, work products, and work schedule

3. Modeling (Analyze, Design) – Encompasses the creation of models to better

under the requirements and the design

4. Construction (Code, Test) – Combines code generation and testing to

uncover errors • Deployment – Involves delivery of software to the
customer for evaluation and feedback
Prescriptive Process Model
• Defines a distinct set of activities, actions, tasks, milestones, and work
products that are required to engineer high-quality software

• The activities may be linear, incremental, or evolutionary

Waterfall Model
The waterfall model is a breakdown of project activities into linear sequential phases,
where each phase depends on the deliverables of the previous one and corresponds to a
specialization of tasks. The approach is typical for certain areas of engineering design.
V Model
The V-model represents a development process that may be considered an extension of the
waterfall model and is an example of the more general V-model. Instead of moving down
in a linear way, the process steps are bent upwards after the coding phase, to form the
typical V shape. The V-Model demonstrates the relationships between each phase of the
development life cycle and its associated phase of testing. The horizontal and vertical axes
represent time or project completeness (left-to-right) and level of abstraction
(coarsest-grain abstraction uppermost), respectively.
Incremental model
The incremental build model is a method of software development where the model is
designed, implemented and tested incrementally (a little more is added each time) until the
product is finished. It involves both development and maintenance. The product is defined
as finished when it satisfies all of its requirements. Each iteration passes through the
requirements, design, coding and testing phases. And each subsequent release of the system
adds function to the previous release until all designed functionally has been implemented.
This model combines the elements of the waterfall model with the iterative philosophy of
prototyping.
Iterative Model
An iterative life cycle model does not attempt to start with a full specification of
requirements by first focusing on an initial, simplified set user features, which then
progressively gains more complexity and a broader set of features until the targeted system
is complete. When adopting the iterative approach, the philosophy of incremental
development will also often be used liberally and interchangeably.
RAD model
Rapid application development (RAD) is often referred as the adaptive software
development. RAD is an incremental prototyping approach to software development
that end users can produce better feedback when examining a live system, as opposed
to working strictly with documentation. It puts less emphasis on planning and more
emphasis on an adaptive process.
Spiral model
A spiral model looks like a spiral with many loops. The exact number of loops of the
spiral is unknown and can vary from project to project. This model supports risk handling,
and the project is delivered in loops. Each loop of the spiral is called a Phase of the
software development process.
Agile model
Agile is an umbrella term for a set of methods and practices based on the values and
principles expressed in the Agile Manifesto that is a way of thinking that enables teams
and businesses to innovate, quickly respond to changing demand, while mitigating risk.
Organizations can be agile using many of the available frameworks available such as
Scrum, Kanban, Lean, Extreme Programming (XP) and etc.
Questions??
Agile Software Development
Process (22B12CS414)
Lecture 3
Introduction to Agile Software
Development

Dr. Amarjeet Prajapati

(Assistant Professor)
What is Agile?

• Agile is the ability to create and respond to change. It

is a way of dealing with, and ultimately succeeding in,
an uncertain and turbulent environment.

• The word represents the adaptiveness and response

to change which was so important to their approach.

• It’s really about thinking through how you can

understand what’s going on in the environment that
you’re in today, identify what uncertainty you’re
facing, and figure out how you can adapt to that as
you go along.
Agile model
Agile is an umbrella term for a set of methods and practices based on the values and
principles expressed in the Agile Manifesto that is a way of thinking that enables teams
and businesses to innovate, quickly respond to changing demand, while mitigating risk.
Organizations can be agile using many of the available frameworks available such as
Scrum, Kanban, Lean, Extreme Programming (XP) and etc.
 The Agile Manifesto

⚫ In 2001, 17 software development professionals

gathered to discuss concepts around the idea of
lightweight software development and ended up
creating the Agile Manifesto.

⚫ The Manifesto outlines the four core values of

Agile, and although there has been debate about
whether the Manifesto has outlived its
usefulness, it continues at the core of the Agile
movement.
 The four core values outlined in the Agile
Manifesto are:
⚫ Individuals and interactions over
processes and tools
⚫ Working software over comprehensive
documentation
⚫ Customer collaboration over contract
negotiation
⚫ Responding to change over following a
plan
The 12 principles of Agile-The Agile Manifesto also outlined 12
core principles for the development process. They are:
1. Satisfy customers through early and continuous delivery of valuable work.
2. Break big work down into smaller tasks that can be completed quickly.
3. Recognize that the best work emerges from self-organized teams.
4. Provide motivated individuals with the environment and support they need
and trust them to get the job done.
5. Create processes that promote sustainable efforts.
6. Maintain a constant pace for completed work.
7. Welcome changing requirements, even late in a project.
8. Assemble the project team and business owners on a daily basis throughout
the project.
9. Have the team reflect at regular intervals on how to become more effective,
then tune and adjust behavior accordingly.
10. Measure progress by the amount of completed work.
11. Continually seek excellence.
12. Harness change for a competitive advantage.
The Agile software development cycle
⚫ The Agile software development cycle can be broken down into
six steps: concept, inception, iteration/construction, release,
production and retirement.
⚫ The first step, concept, involves the identification of business
opportunities in each potential project as well as an estimation of
the time and work that will be required to complete the project.
⚫ During the second step, inception, team members are identified,
funding is established and the initial requirements are discussed
with the customer.
⚫ The third step, iteration/construction, is when teams start creating
working software based on requirements and continuous feedback.
The Agile software development cycle relies on iterations
⚫ Multiple iterations occur throughout the development
cycle and they each possess their own workflow. A
typical iteration flow consists of:

defining requirements based on the product backlog, sprint

backlog and customer and stakeholder feedback;
developing software based on the set requirements;
conducting quality assurance testing, internal and external
training and documentation;
delivering and integrating the working product into
production; and
gathering customer and stakeholder feedback on the
iteration in order to define new requirements for the next
sprint.
⚫ The fourth step, release, involves final quality assurance
testing, resolution of any remaining defects, finalization
of the system and user documentation and, at the end,
release of the final iteration into production.

⚫ After the release, the fifth step, production, focuses on the

ongoing support necessary to maintain the software. The
development teams must keep the software running
smoothly while also teaching users exactly how to use it.

⚫ The final step, retirement, incorporates all end-of-life

activities, such as notifying customers and final
Migration. The system release must be removed from
production.
Throughout the Agile cycle, different features can be
added to the product backlog, but the entire process should
consist of repeating each step over and over until every
item in the backlog has been satisfied.

This makes the Agile cycle more of a loop than a linear

process. At any time, an enterprise can have multiple
projects occurring simultaneously with iterations that are
logged on different product lines and a variety of internal
and external customers providing different business needs.
Types of Agile methodologies: The goal of every Agile
methodology is to embrace and adapt to change while
delivering working software as efficiently as possible.
However, each method varies in the way it defines the
steps of software development.
The most widely used Agile methods include:
• Scrum
• Lean software development
• Extreme programming
• Crystal
• Kanban
• Dynamic systems development method
• Feature-driven development
Questions??
Agile Software Development
Process (22B12CS414)
Lecture 4
Scrum Methodology

Dr. Amarjeet Prajapati

(Assistant Professor)
Scrum Overview

•Scrum is an agile process that allows us to focus on

delivering the highest business value in the shortest
time.

•It allows us to rapidly and repeatedly inspect actual

working software in two three week sprints (iterations)
for us.

•The product owner negotiates priorities with the team.

•Teams self-organize to determine the best way to

deliver the highest priority features.
Scrum origins

⚫ Jeff Sutherland
⚫ Initial scrums at Easel Corp in 1993
⚫ IDX and 500+ people doing Scrum
⚫ Ken Schwaber
⚫ ADM
⚫ Scrum presented at OOPSLA 96 with Sutherland
⚫ Author of three books on Scrum
⚫ Mike Beedle
⚫ Scrum patterns in PLOPD4
⚫ Ken Schwaber and Mike Cohn
⚫ Co-founded Scrum Alliance in 2002, initially within the Agile
Alliance
Scrum has been used by (at least)
•Microsoft •Amazon
•IBM •Intuit
•Yahoo •Nielsen Media
•Google •First American Real Estate
•Electronic Arts •BMC Software
•High Moon Studios •Ipswitch
•Lockheed Martin •John Deere
•Philips •Lexis Nexis
•Siemens •Sabre
•Nokia •Salesforce.com
•Capital One •Time Warner
•BBC •Turner Broadcasting
•Intuit •Oce
Scrum has been used for:

⚫ Commercial software • Video game development

⚫ In-house development
• FDA-approved, life-critical
⚫ Contract development systems
⚫ Fixed-price projects
• Satellite-control software
⚫ Financial applications
⚫ ISO 9001-certified • Websites
applications
• Handheld software
⚫ Embedded systems
⚫ 24x7 systems with • Mobile phones
99.999% uptime
requirements • Network switching
applications
⚫ the Joint Strike Fighter
• ISV applications
Characteristics
⚫ Requirements are captured as items in a list of “product
backlog” our requirements in the specs

⚫ Self-organizing teams

⚫ Product progresses in a series of “sprints” iterations

⚫ Product is designed, coded, and tested during each sprint

⚫ Uses generative rules to create an agile environment for

delivering projects

⚫ One of the “agile processes”

Putting it all together

Image available at www.mountaingoatsoftware.com/scrum

No changes during a sprint
C
h
a
n
g
e

⚫ Plan sprint durations around how long you can

commit to keeping change out of the sprint
Scrum framework
Roles

•Product owner
•ScrumMaster Meetings
•Team
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting Components

•Product backlog
•Sprint backlog
•Burndown charts
Product owner manager
⚫ Define the features of the product specification
⚫ Decide on release date and content 14-Dec
⚫ Be responsible for the profitability of the product (ROI)
which 335 need not do
⚫ Prioritize features according to market value what
you’re supposed to learn in 335
⚫ Adjust features and priority every iteration, as needed
not in 335
⚫ Accept or reject work results or grade the projects
The Scrum Master
Scrum masters are the facilitators of scrum, the lightweight agile framework
with a focus on time-boxed iterations called sprints. As facilitators, scrum
masters act as coaches to the rest of the team. “Servant leaders” as the
Scrum Guide puts it. Good scrum masters are committed to the scrum
foundation and values, but remain flexible and open to opportunities for
the team to improve their workflow.
The team
⚫ Typically 5-9 people four or 3

⚫ Cross-functional:

⚫ Programmers, testers, user experience designers, etc. If this is

the case, it was by luck

⚫ Teams are self-organizing definitely in 335

⚫ Ideally, no titles but rarely a possibility
⚫ Membership should change only between sprints
hopefully this does not happen in a 2 sprint project
Product Sprint planning meeting
backlog, or
the
Prioritize
requirements
from your
• Analyze and evaluate product
specs
backlog
Selected requirements to be
completed in
We did this just
iteration one
once, it’s just 6
week project Sprint planning Sprint
after all
• Decide how to do it Backlog
You created tasks needed to our iteration
complete the requirements requirements
Sprint planning
⚫ Team selects items from the requirements they can commit to completing
we did this for you (see final project page)
⚫ Select the most important requirements from the product backlog that
you think you can complete in a Sprint iteration
⚫ High-level design is considered iteration 1 requirements

As a vacation planner, I want

to see photos of the hotels. Code the middle tier (8 hours)
Code the user interface (4)
Write test fixtures (4)
Code the foo class (6)
Update performance tests (4)
 The Daily Scrum

⚫ At start of day team meetings

⚫ Time Boxed: n minutes
⚫ Stand-up: to keep it short
⚫ Not for problem solving, which comes later
⚫ Whole world is invited PM and team only
⚫ Only team members, ScrumMaster, product owner, can
talk
⚫ Helps avoid other unnecessary meetings
 Everyone answers 3 questions
1
What did you do yesterday?

2
What will you do today?

3
Is anything in your way?
⚫ These are not status updates for ScrumMasters
⚫ They are commitments in front of the team
The work

⚫ Show me the code

⚫ Do it in with team
⚫ Program solo or pair
⚫ Ask questions of team
⚫ Complete tasks you promised you would do
Tasks
⚫ Individuals sign up for work of their own
choosing during the Sprint Review your email to
your PM
⚫ Work is never assigned
⚫ Track the progress of tasks with a Task Board
⚫ Defined In Progress Completed
⚫ Can add, change, or remove tasks
⚫ Update time remaining daily
⚫ When complete, mark the task as complete
⚫ Track progress with a burn down chart
The Sprint review live grading with PM?
⚫ Team presents what it accomplished during the sprint
⚫ Typically takes the form of a demo of new features or
underlying architecture
⚫ Informal
⚫ Time boxed
⚫ No powerpoints
⚫ Whole team participates
⚫ Invite the world team and PM only
Sprint Retrospective we’ll skip this

⚫ At the end of sprint take a look at what is and what is

not working
⚫ Time boxed 10 minutes
⚫ Whole team participates PM and team only
⚫ ScrumMaster
⚫ Product owner
⚫ Team
⚫ Possibly customers and others
Start / Stop / Continue
⚫ Whole team gathers and discusses what they’d like to:

Start doing

Stop doing

This is just one

of many ways to Continue doing
do a sprint
retrospective.
Questions??
Agile Software Development
Process (22B12CS414)
Lecture 5
Scrum Methodology-PART-II

Dr. Amarjeet Prajapati

(Assistant Professor)
Product backlog and Sprint backlog
Scrum cycle
Scrum Artifacts
Features/Theme vs User Stories
For example, I want to build a site that sells shoes. My features might be:
⚫ Display informative Home screen
⚫ User Registration
⚫ User Login
⚫ Display Products
⚫ Display Shopping Cart
⚫ Add products to Shopping Cart

And then, User stories would be developed off those:

⚫ Display informative Home screen

- As a User, I want to access the Home screen, so that I can enter the website
- As a user, I want to be able to see specials, so that I can see the current deals
⚫ User Registration
- As a user, I need to be able to register as a new user, so that I can have more access to the site
- As a user, I want to be able to register with my Google account
⚫ User Login
- As a user, I need to be able to login with my username/password, to gain access to the site
- As a user, I want to be able to login with my Google account, to gain access to the site
Display Products
Epic

⚫ An agile epic is a body of work that can be broken

down into specific tasks (called user stories) based
on the needs/requests of customers or end-users.
 User Story
⚫ A user story is the smallest unit of work in an agile framework.
It’s an end goal, not a feature, expressed from the software
user’s perspective.
⚫ A user story is an informal, general explanation of a software
feature written from the perspective of the end user or
customer.
⚫ The purpose of a user story is to articulate how a piece of work
will deliver a particular value back to the customer. Note that
"customers" don't have to be external end users in the
traditional sense, they can also be internal customers or
colleagues within your organization who depend on your team.
⚫ User stories are a few sentences in simple language that outline
the desired outcome. They don't go into detail. Requirements
are added later, once agreed upon by the team.
Sprint
⚫ Sprint is one timeboxed iteration of a continuous development cycle.
Within a Sprint, planned amount of work has to be completed by the
team and made ready for review.
⚫ A sprint is a short, time-boxed period when a scrum team works to
complete a set amount of work.
⚫ “With scrum, a product is built in a series of iterations called sprints
that break down big, complex projects into bite-sized pieces,"
Before Sprint

During Sprint
Sprint Review vs Sprint Retrospective
Questions??
Agile Software Development
Process (22B12CS414)
Lecture 6
Scrum Methodology-PART-II

Dr. Amarjeet Prajapati

(Assistant Professor)
Backlog grooming
Backlog grooming is a regular session where backlog items are discussed,
reviewed, and prioritized by product managers, product owners, and the rest
of the team. The primary goal of backlog grooming is to keep the backlog
up-to-date and ensure that backlog items are prepared for upcoming sprints.
Additionally, the process helps product managers explain and align the
organization behind the strategy that informs the backlog items.

Backlog grooming, referred to also as backlog management, backlog

refinement, pre-planning, or story time, is a widely adopted activity by Scrum
and agile product teams. The most common tactical activities that occur during
backlog management include:
• Removing outdated user stories and tasks.
• Adding new user stories that reflect newly discovered user insights.
• Breaking down broad user stories into smaller items.
• Reordering user stories based on their priority.
• Explaining and clearly defining user stories and tasks to avoid uncertainty
and “black box” communication.
• Assigning or re-assigning story points and estimates.
• Identifying roadblocks and minimizing risks related to backlog items.
Benefits of backlog grooming
Keeps the backlog clean
Depending on how big your organization is and your company structure,
your backlog can receive input from several different teams and
departments.

Keeps the backlog relevant

The purpose of backlog refinement is to ensure that the backlog is
populated with initiatives that are relevant, well-documented, and
prioritized in accordance with the needs of the customer and
organization.

Keeps the whole product team up to date

An unorganized backlog with poorly formulated backlog items can lead
to ambiguity and miscommunication across teams, as well as bad
product decisions.

Increases work velocity

A groomed backlog helps your product team deliver features more
Role of a Scrum Master?
Characteristics and Skills of a Project
Manager vs. a Scrum Master
Product backlog
⚫ A product backlog is a prioritized list of work for the
development team that is derived from the roadmap and
its requirements.
⚫ The most important items are shown at the top of the
product backlog so the team knows what to deliver first.

Product Roadmap
Product backlog
Product Requirements
Product Roadmap
⚫ A product roadmap is a plan of action for how a product or
solution will evolve over time.

⚫ Product owners use roadmaps to outline future product

functionality and when new features will be released.

⚫ To build a roadmap, product owners take into account market

trajectories, value propositions, and engineering constraints.

⚫ Once these factors are reasonably well-understood, they are

expressed in a roadmap as initiatives and timelines.
 Product requirements
⚫ A product requirements document (PRD) defines the
requirements of a particular product, including the
product’s purpose, features, functionality, and
behavior.

⚫ It serves as a guide for business and technical teams to

help build, launch, or market the product.

⚫ A product requirements document defines the product

you are about to build: It outlines the product's
purpose, its features, functionalities, and behavior.
Questions??
Agile Software Development
Process (22B12CS414)
Lecture 7
Prioritize Product Backlog

Dr. Amarjeet Prajapati

(Assistant Professor)
Deciding what to build (or what to build next) is one of the most critical parts of a
product manager’s job. You only get so many chances to make an impact.

The influencing factors for prioritizing product backlog items are

• Customer Satisfaction
• Business Value
• Complexity
• Risk & Opportunity
• Cost
• Effected number of users / or frequency of use
Priority rank
Identify the factors your project will consider to analyze the priority,
you can use all the above factors or most impact-full factors to do this
exercise in this example we are using three factors a.) Customer
Satisfaction, b.) Business Value, c.) Cost.

Allocate the weightage to each consideration factor, in case you think

all the factors are of equal weight for your particular project, just give 1
to all. in this example we have allocated 12 to Customer satisfaction,
10 to Business Value and 7 to cost.

Have your backlog ready with the items including Defects, stories,
Spikes etc. In this example we are assuming our backlog have 10 stories
that we are prioritizing.

Define a scale to provide rate to each story against its consideration

factors. In this example we are having a scale of 1 to 10.
Affinity Analysis
With this technique user stories are categorized into different baskets like high low
medium etc. and pick backlog items to groom, plan or construct. This is techniques of
basketing Product backlog items to prioritize in groups.
Organize backlog items by category
Kano Analysis
⚫ With this technique backlog items are prioritized based on the customer
satisfaction factor. The Kano Analysis chart have different areas of
customer satisfaction

Must be Functionality-Customer usually take those functionality for granter, If implemented

customers are just neutral, but if not implemented or poorly implemented, customers are very
dissatisfied.
One Dimensional Functionality-Those are the functionality satisfied the customer if
implemented and dissatisfied if not implemented. Those functionalities are often discussed
with mutually agreement between development team and business/customer.

Attractive Functionality-Those are the functionality satisfied the customer if implemented but
don’t dissatisfied the customer if not implemented. Those functionality are often not
demanded by the customer, but customers get delighted by having those functionality.

Performance Functionality-Those are the functionality are proportional to implementation

and satisfaction. More we implement more the satisfaction will be.

Indifferent Functionality-These functionalities are neutral nor good or bad, implementing

them or not implementing them does not satisfy or dissatisfy the customer.
MoSCoW Method
The acronym derived from the first letter of its 4 prioritizing category (Must Have,
Should Have, Could Have, Would like to have). This is another way of Affinity
analysis by basketing the product backlog items in four categories.
M – Must have
This point describes requirements that must be satisfied in the final solution.
These requirements are non-negotiable. And the project will fail without
them.

S – Should have
A high-priority feature that is not critical to launch. But it is considered to be
important and of a high value to users. Such requirements occupy the second
place in the priority list.

C – Could have
A requirement that is desirable but not necessary. According to the method,
this point will be removed first from scope if the project’s timescales are at
risk.

W – Won’t have
A requirement that will not be implemented in a current release but may be
included in a future stage of development. Such requirements usually do not
affect the project success.
Scrum team members role during
Prioritization?
Benefits of backlog prioritization
Questions??
Agile Software Development
Process (22B12CS414)
Lecture 8
Project Estimation

Dr. Amarjeet Prajapati

(Assistant Professor)
Agile estimation is the process for estimating the effort required to complete a
prioritized task in the product backlog. This effort is usually measured with respect
to the time it will take to complete that task, which, in turn, leads to accurate sprint
planning.
Why Run Agile Estimations?
Agile estimations are essential for:
• Making teams accountable for deliverables
• Inducing discipline across the Agile team
• Predicting the approximate time it will take to finish a project
• Enabling better sprint management
• Improving team productivity

Some of the to-the-point benefits of Agile Estimation techniques include:

• Improved Decision-Making
• Better Coordination
• Better Risk Management
Agile Estimation Techniques
⚫ T-Shirt Sizing
⚫ Sprint Poker 🃏
⚫ Three Point Method
⚫ Affinity Estimation
⚫ Relative Mass Evaluation ⚖
⚫ Dot Voting
⚫ Maximum Allowable Size ⛔
⚫ Big, Uncertain, Small

Homework-Read all above techniques in detail

Questions??
 Agile Software Development
Process (22B12CS414)
Lecture 9
Extreme Programming

Dr. Amarjeet Prajapati

(Assistant Professor)
Reference-https://www.youtube.com/watch?v=td7mY7x_Tk0
Introduction to Extreme Programming
Extreme Programming Phases
Full List of XP Practices
Questions??
 Agile Software Development
Process (22B12CS414)
Lecture 10
Extreme Programming

Dr. Amarjeet Prajapati

(Assistant Professor)
Reference-https://www.youtube.com/watch?v=td7mY7x_Tk0
 Test-driven development

Test-driven development starts with developing test for

each one of the features. The test might fail as the tests
are developed even before the development.
Development team then develops and refactors the code
to pass the test.
Acceptance TDD and Developer TDD
Here in this Test Driven Development example, we will define a class password. For
this class, we will try to satisfy following conditions. A condition for Password
acceptance: The password should be between 5 to 10 characters.
First in this TDD example, we write the code that fulfills all the above requirements.

https://www.guru99.com/test-driven-development.html
Scenario 1: To run the test, we create class PasswordValidator ();
Scenario 2: Here we can see in method TestPasswordLength () there is no need
of creating an instance of class PasswordValidator. Instance means creating an
object of class to refer the members (variables/methods) of that class.

We will remove class PasswordValidator pv = new PasswordValidator () from the

code. We can call the isValid () method directly by PasswordValidator. IsValid
(“Abc123”). (See image below)
So we Refactor (change code) as below:
 Scenario 3: After refactoring the output shows failed status (see image below)
this is because we have removed the instance. So there is no reference to non
–static method isValid ().

So we need to change this method by adding “static” word before Boolean as

public static boolean isValid (String password). Refactoring Class
PasswordValidator () to remove above error to pass the test.
After making changes to class PassValidator () if we run the test then the output will
be PASSED as shown below.
Questions??
 Agile Software Development
Process (22B12CS414)
Lecture 11
Lean Software Development

Dr. Amarjeet Prajapati

(Assistant Professor)
Reference-https://www.youtube.com/watch?v=td7mY7x_Tk0
Lean Software Development
Eliminate Waste
Empower the team
Build Quality In
Amplifying Learning
Fast Delivery
Defer decision
Questions??
 Agile Software Development
Process (22B12CS414)
Lecture 12
DevOps Vs Agile

Dr. Amarjeet Prajapati

(Assistant Professor)
https://www.guru99.com/devops-tutorial.html
What is DevOps?
The DevOps is the combination of two words, one is Development and other is
Operations. It is a culture to promote the development and operation process
collectively.

The DevOps tutorial will help you to learn DevOps basics and provide depth
knowledge of various DevOps tools such as Git, Ansible, Docker, Puppet,
Jenkins, Chef, Nagios, and Kubernetes.
 The DevOps is a combination of two words,
one is so ware Development, and second is
Operations. This allows a single team to
handle the entire application lifecycle, from
development to testing, deployment, and
operations. DevOps helps you to reduce the
disconnection between so ware developers,
quality assurance (QA) engineers, and
system administrators.
DevOps Lifecycle
Code: The first step in the DevOps life cycle is coding, where developers build the code
on any platform
Build: Developers build the version of their program in any extension depending upon
the language they are using
Test: For DevOps to be successful, the testing process must be automated using any
automation tool like Selenium
Release: A process for managing, planning, scheduling, and controlling the build in
different environments after testing and before deployment
Deploy: This phase gets all artifacts/code files of the application ready and
deploys/executes them on the server
Operate: The application is run after its deployment, where clients use it in real-world
scenarios.
Monitor: This phase helps in providing crucial information that basically helps ensure
service uptime and optimal performance
Plan: The planning stage gathers information from the monitoring stage and, as per
feedback, implements the changes for better performance
Difference between DevOps and Agile
DevOps Principles
Here, are six principles which are essential when adopting DevOps:

1. Customer-Centric Action: DevOps team must take customer-centric action for that
they should constantly invest in products and services.

2. End-To-End Responsibility: The DevOps team need to provide performance support

until they become end-of-life. This enhances the level of responsibility and the quality
of the products engineered.

3. Continuous Improvement: DevOps culture focuses on continuous improvement to

minimize waste. It continuously speeds up the improvement of product or services
offered.

4. Automate everything: Automation is a vital principle of DevOps process. This is not

only for the software development but also for the entire infrastructure landscape.

5. Work as one team: In the DevOps culture role of the designer, developer, and tester
are already defined. All they needed to do is work as one team with complete
collaboration.

6. Monitor and test everything: It is very important for DevOps team to have a robust
monitoring and testing procedures.
Homework-Read more about
DevOps tools
Questions??
 Agile Software Development
Process (22B12CS414)
Lecture 12
DevOps Vs Agile

Dr. Amarjeet Prajapati

(Assistant Professor)
https://www.guru99.com/devops-tutorial.html
Homework-Read more about
DevOps tools
Questions??