The document provides an overview of the agile software development process. It begins with defining agile as an iterative and adaptive approach to software development performed collaboratively by self-organizing teams. It then discusses agile principles like valuing customer collaboration, responding to change, and delivering working software frequently. The document also covers specific agile frameworks like Scrum and Extreme Programming, the role of user stories, estimation techniques like planning poker, and ceremonies like daily stand-ups, sprint planning and retrospectives. It concludes by comparing agile to the traditional waterfall model and defining some common agile metrics.

1. Agile Software
Development Process
Solomon Raja
PMP, PMI-ACP, CSM

2. Agenda
• About Agile
• Scrum Framework
• User Story Creation
• Definition of Done
• Agile – Retrospective
• Agile – Metrics
• Agile vs Traditional Development Approach

3. What is Agile software development?
Agile is an iterative and adaptive
approach to software development
methodology performed in a highly
collaborative manner by self-organizing
teams. It focuses on the following values.
 Iterative and incremental development
 Potential shippable product at the end of
every iteration
 It provides an opportunity to assess the
direction of a project throughout the
development lifecycle.

4. Agile Manifesto
CUSTOMER
COLLABORATION
Over contract negotiation
INDIVIDUAL &
INTERACTIONS
Over process and tools
RESPONDING
TO CHANGE
Over following a plan
WORKING
SOFTWARE
Over full documentation
Agile Manifesto

5. Agile Principles
Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage
Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

6. Agile Principles
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

7. Agile Model
Agile
Scrum
Extreme
Programming
Feature
Driven
Development
Crystal
Lean
DSDM
It is a combination of iterative and incremental process
models with focus on process adaptability and customer
satisfaction by rapid delivery of working software
product. It is a collection of values and principles, that
can be applied on an agile software development
project. The most popular model is Scrum however
other models such as extreme programming, & Rational
Unified Process (RUP), Feature Driven Development,
Crystal, Lean, DSDM, etc., as equally important and
extreme programming emphasis on engineering best
practices such as Test driven approach development
(TDD), continuous Integration, etc.,

8. Agile - Adaptive Planning
The Stacey complexity model categorizes tasks in four
different categories: simple, complicated, complex and
anarchy/chaos. In this model we have two dimensions:
Uncertainty of requirements: This indicates how certain
requirements are and how likely the requirements will
change in the future. Basically this dimension says
something about the level of uncertainty of WHAT we
have to do.
Uncertainty of technology: The 2nd dimension shows
how uncertain your approach or technology is to finish a
task. This shows the level of uncertainty of HOW
we build a project.
I think, if we would explain these 4 categories to
somebody, who has nothing to do with s/w
development or agile, & then ask “How would you solve
tasks from the complex category?” then he or she will be
able to come up with the answer by himself/herself.
The answer is Agile through the adaptive planning.

9. Empirical Process – Pillars of Scrum
Transparency allows all facets of any Scrum process to be
observed by all stakeholders. This promotes an easy and
transparent flow of information throughout the
organization and creates an open work culture.
Inspection in Scrum is depicted through
• Scrum board & Information radiators
• Collection of feedback from the Product Owner and other
stakeholders.
• Review of the working software
Adaptation happens as the Scrum Core Team and
Stakeholders learn through transparency and inspection
and then adapt by making continuous improvements in
the work they are doing.
• Daily Standup
• Risk Identification
• Review Meeting
• Retrospect Sprint Meeting
Transparency
Inspection
Adaption
Scrum is a powerful set of principles and
practices that help teams deliver products
in short cycles, enabling fast feedback,
continual improvement, and rapid
adaptation to change.

10. Agile – Scrum Values
All work performed in Scrum needs a set of values as the foundation for the team's processes and
interactions. And by embracing these five values, the team makes them even more instrumental to its
health and success.
• Focus – As we focus on only a few things at a time, we work well together and produce excellent
work. We deliver valuable items sooner.
• Courage – Because we work as a team, we feel supported and have more resources at our disposal.
This gives us the courage to undertake greater challenges.
• Openness - As we work together, we express how we're doing, what's in our way, and our concerns
so they can be addressed.
• Commitment - Because we have great control over our own destiny, we are more committed to
success.
• Respect - As we work together, sharing successes and failures, we come to respect each other and to
help each other become worthy of respect.

11. Agile (Scrum) Development Framework
Product Backlog
Design Car Engine
Braking System
Clutch System
Design ABS, Airbag
Gear System
Car Seat alignment
Head & Tail light
Fuel system
Sprint Backlog
Design Car Engine
Braking System
Clutch System
Gear System
Sprint
Review
2 - 4 Week
Sprint
Shippable
Product
Increment
24 Hours
Daily Standup
Product Vision
Launch a cost effective
car in a year to be No.1
in Automobile
Industry of European
market.
RetrospectiveBacklog Grooming

12. Agile Development – Product Vision
Release 1
•Iteration1
•Iteration 2
Release 2
•Iteration 3
Release 3
•Iteration 4
•Iteration 5
•Iteration 6
Release 4
•Iteration 7
Product Roadmap
Product Vision
What, Who, Why, When, Constraints, Assumptions
Release Milestone, Epic / User Stories, Objective
Release Plan
High Priority Epic / User Stories, Estimation, Team Capacity, DoD, Iteration
Product Owner is responsible
to have a vision of what to
build, why to build, when to
release, how this helps to
increase the revenue, etc.,
This is key to successfully
starting any agile software
development project. Product
owner is responsible for
defining stories and
prioritizing the product
backlog

13. Agile – Roles and Responsibilities
Product Owner Scrum Team Scrum Master
Responsible for product vision,
creation of roadmap and release
strategy.
Self-organizing / self-managing/
Extremely collaborative without
externally assigned roles.
Facilitates the Scrum process.
Creates an environment
conducive for self-organization.
Responsible for maximizing the
return on investment.
Negotiates commitments with the Product
Owner, one Sprint at a time.
Promotes improved engineering
practices.
Accepts or rejects each product
increment during sprint review.
Has autonomy regarding how to reach
commitments.
Enforces time boxes. Helps
resolve impediments.
Constantly re-prioritizes the
Product Backlog, adjusting any
long-term expectations such as
release plans.
Most successful with long-term, FTEs.
Scrum moves work to a flexible learning
team and avoids moving people or
splitting them between teams.
Captures empirical data to adjust
forecasts. Shields the team from
external interference .
Decides whether to ship, whether
to continue development.
Scrum Team size is 7 ± 2 members.
Play servant leadership.

14. 14
DailyScrumCall
SprintPlanningMeeting
SprintReviewMeeting
SprintRetrospective
Select User stories
to be included
Prepare a Product
Backlog
Prioritize Sprint
Backlog
Update on tasks
accomplished for
the day
Action plan on
tasks to
accomplish for the
next day
Discuss and
resolve
Impediments and
dependencies
Review work done
and pending
Review schedule
Demo completed
items to
stakeholders
Identify what went
well. How things
can be improved or
how certain issues
could be avoided
Work on continues
process /delivery
improvements
Embrace change
(with appropriate
trade-offs)
Agile - Scrum Ceremonies
Sprint Ceremonies Frequency Timebox
Sprint Planning – 1st activity of the Sprint Bi-Weekly 2 Hours
Sprint Review (End of Sprint) Bi-Weekly 1 Hour
Sprint Retrospective (End of Sprint) Bi-Weekly 30 Mins
Scrum – Stand up Daily 15-30 Mins
This guideline is for 2 weeks iteration / sprint

15. User Story
A user story describes functionality that will be valuable to users or purchasers of an
application or system or software. A user story is defined incrementally, in three stages
 The brief description of the need
 The conversations that happen during backlog grooming and Sprint planning to
solidify the details
 The tests that confirm the story's satisfactory completion
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T - Testable

16. User Story
 Product Owner prioritizes and team estimates them
 It usually follows the format:
▪ As a : <Role>
▪ I want to : <Function>
▪ So that : <Desired Goal>
▪ Acceptance Criteria
Story Quality
As a consumer, I want shopping cart functionality to easily purchase items online. Good story.
All graphing and charting will be done using 3rd party library. This is not a good story.
The users can run the application on Windows 8.1 and Linux 6.5. Good story.
The user will be prompted to save his/her work if he/she hasn't saved it for 15
minutes.
Good story.
As an executive, I want to generate a report to understand which departments
need to improve their productivity.
Good story.
The Performance of the application should be faster. Not a good story

17. Estimation – Story Point – Estimating Size, Not Effort
Story points are a unit of measure for expressing the overall size of a user story,
requirement, or feature. It is a relative measure of the effort required to
complete a user story.
It’s influenced by complexity, uncertainty, risk, dependency, volume of work,
etc.,
 The first approach is to select a story that you expect to be one of the smallest stories
you’ll work with and say that story is estimated at one story point.
 The second approach is instead to select a story that seems somewhat medium and give
it a number somewhere in the middle of the range you expect to use
Mike Cohn recommends either a Fibonacci-like sequence (0, 1, 2, 3, 5, 8, 13, 20,
40, 100) or a base-2 sequence (0, 1, 2, 4, 8, 16, 32, 64, 128) to ensure that the
buckets are reasonable.
The reason for using the Fibonacci sequence is to reflect the inherent uncertainty
in estimating larger items.
Car Story
points
Mini Cooper 1
Camry 3
Town Car 8
Civic 2
Prius 2
Accord 3
Beetle 2
Impala 5
Crown Victoria 5

18. Estimation – Poker Planning
Planning poker is a tool for estimating the size of the
user story in terms of story points. Story point is a
relative measure of the effort and time required to
complete a user story. Story points are usually
expressed either in numbers that follow the Fibonacci
series (1, 2, 3, 5, 8, 13).
 Epic or User story will be discussed with the team with
detailed explanation by Product owner
 Once team under stand the epic or user story then each
estimator estimates it and places his/her poker card down.
 All cards are turned over at same time, if estimates are
different, outliers are discussed
 Repeat until consensus is reached or group can “live with” a
selected size

19. User Story life cycle
Yes
In Testing
Open
In Progress
Dev. Complete
(With Unit Testing)
R
e
o
p
e
n
e
d
C
o
d
e
R
e
v
i
e
w
S
t
o
r
y
G
o
a
l
Yes
Feedback
No
Yes
No
Done
Yes
No

20. Definition of Done
Definition of Done is a crucial element of a successful scrum project development. When
defined and followed, we need to make sure that scrum team says that a story / task is done.
There is an explicit understanding what it means
 All Acceptance Criteria of the User Story are met
 Code meets defined coding standard.
 Code review is conducted and passed.
 The code is covered by a minimum of 70% unit tests.
 Integration tests of the affected areas are conducted & passed

21. Agile - Retrospective
Realize where you are and where you want to be
Engage the team in productive discussion
Team work to build “We over I” attitude
Relish the power of Inspect and Adapt cycles
Openness and Transparency make retrospective
efficient and effective
Inspect
Adapt
Continuous
Improvement

22. Agile - Retrospective
Setting the Stage
Gather data
Generate Insights
Decide what to do
Closing Retrospective
• Create Safe Env.
• Open Minded
• Engage team
• Focused Discussion
• Visit previous result
• Visit DoD
• Identify Pain Points
• Analyze Metric
• Share Thoughts
• Group Ideas & See pattern
• Brainstorm
• Problem Solving Technique
• Prioritize Ideas
• Get commitment from
team
• Have action plan

23. Retrospective - Quantitative Review
Team identify the metrics to measure and analyze the progress of iteration for better visibility
and continuous improvements.
• Team Velocity
• Burn Down Chart
• Sprint Goal Success Rate
• Defects Trend
0
20
40
60
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Team X Velocity Trend
Planned Actual

24. Retrospective - Quantitative Review
 Team Productivity
 Team Member Capability
 Product Quality
 Team lead their own improvement journey
 Empower Team
 Increase customer value through efficiency
 Continuous Improvement
Those who are unaware they are walking in darkness will never seek the light – Bruce Lee

25. Agile vs Traditional SDLC
Traditional Methodology Agile Methodology
Plan Driven Vision Driven
Linear development process Short Iteration
Requirements are clear at the inception Requirements are unclear at the inception
Elaborate Process involved Limited Process involved
Less customer collaboration Frequent Customer Collaboration
Testing happens after completion of
development phase
Testing happens in parallel with development
No flexibility to change requirement More flexible to change requirement
Post Mortem at the end of project Retrospective at the end of iteration
Less Continuous Improvement More Continuous Improvement

26. Agile vs Traditional SDLC
Agile projects have a fixed
schedule and resources while the
scope varies. As the scope of a
project might change in agile
development, teams commit to
fixed iterations of work: sprints if
you're using a scrum framework.
It's also a best practice to keep
teams fixed throughout the
development process. By keeping
teams consistent on a product or
project, they become more
efficient through developed trust
and continuity.

27. Agile vs Traditional SDLC

28. Agile vs Traditional SDLC

29. 29
Metric Definition Formula Frequency
Burndown Chart The burndown chart is an essential part of any
agile development project and is a way for the
team and stakeholders to clearly see what is
happening and how progress is being made
during each sprint. The story point / effort
remaining is the most effective and efficient
way of using burn-down charts.
Plotting burn-down using story point
or effort remaining is the most
effective and efficient way of using
burn-down charts
Daily
Sprint Defect Rate This metric helps to highlight how many
number of defects identified in a sprint.
(Total No. of defects found / Total
no. of test cases executed) x 100
End of
Sprint
Regression Rate The regression testing is a process to ensure
that new code change or deployment does not
break the existing system/application.
(No. of regression defects
found/Total no. of test cases) x 100
End of
Sprint
User Story
Reopened Rate
When a user story or task was not
implemented correctly as per the expectation
then it needs to be reopened to fix it properly.
This metric helps to identify number of user
stories or task reopened in a sprint.
(No. of US reopened / Total No. of
US ) x 100
End of
Sprint
Agile - Health Metric

30. 30
Metric Definition Formula Frequency
Velocity Chart It’s a capacity planning tool. This helps to know
productivity of the Agile team and predicts how
much work an Agile scrum development team can
successfully complete within a sprint. At the end of
each sprint, the team adds up story point / effort
estimates associated with user stories that were
completed during that sprint. This total is called
velocity
Number of total story points or
effort spent of User stories / Sprint
End of Sprint
Post Release
Defect
When a code fix for user story or task was
implemented incorrectly as per expectation however
it was not caught during the internal test execution
cycle and it was caught by the client or end users
after go-live called post release defect. This metric
helps to identify number of post release defects in a
sprint
(No. of defects found after Go-Live)
/ Total. No. of test cases executed x
100
End of Sprint
Sprint Goal
Success Rate
Delivering all committed user stories with no
compromise on quality within the sprint .
(No of user stories delivered / No.
of user stories committed) x 100
End of Sprint
Agile - Health Metric

31. 31
Metric Definition Formula Frequency
Client Feedback o Delivery Excellence
• Sprint Execution
• Quality of deliverable
o Communication
o Production Deployment
• No impact to existing system
NA Every Month
(or)
End of every
Sprint
Agile - Health Metric