SDLC using Agile Methodology

Agile Methodology
• People collaborating
together to build high
quality products that
meet customer needs at
a sustainable pace

• The tasks are

divided to time boxes
(small time frames)
to deliver specific
features for a release

• Each delivery is incremental in

terms of features; the final
delivery holds all the features
• Iterative approach is required by the customer
taken and working
software is delivered
after each iteration
 Agile Manifesto/Philosophy

Individuals
• Self-organization, motivation
and and interactions are important Over Process and Tools
Interactions

• Working software is more

Working useful and welcome than just Comprehensive
Software presenting documents to clients Over
in meetings Documentation

• Requirements cannot be fully

collected at the beginning of the
Customer software development cycle, Over
Collaboration therefore continuous customer or Contract Negotiation
stakeholder involvement is very
important

Responding to • Agile methods are focused on

Change
quick responses to change and Over Following a Plan
continuous development
Agile Process Principles
1. Highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter
timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get
the job done.
6. The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
Agile Process Principles
7. Working software is the primary measure of progress
8. Agile processes promote sustainable. The sponsors,
developers, and users should be able to maintain a constant
pace indefinitely
9. Continuous attention to technical excellence and good
design enhances agility
10. Simplicity - the art of maximizing the amount of work not
done--is essential
11. The best architectures, requirements, and designs emerge
from self-organizing teams
12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly (Frequent Review).
Agile using SCRUM
What is SCRUM?

• Scrum is an agile lightweight process framework for development

• Can manage and control software/ development
• Uses iterative, incremental practices
• Has a simple implementation
SCRUM Values

Focus Respect Openness Commitment Courage

• Focus only • Respect and • Every thing • Greater • As we work

on few trust each about the control over together
things at a other within project is what we do and feel
time the team transparent and how we supported
• Work well • Sharing to every one do we are
together success and • Create a • We become courageous
and produce failure culture of more to be open
excellent openness committed and
work for success challenge
ourselves to
go beyond
our
capabilities
SCRUM Framework
• The Scrum framework consists of Scrum Teams and
their associated roles, events, artifacts, and rules.
Each component within the framework serves a
specific purpose and is essential to Scrum’s success
and usage

Roles Ceremonies Artifacts Agreements

Product Owner Sprint Planning Product Backlog Definition of Ready

Scrum Master Sprint Review Sprint Backlog Definition of Done

Scrum Team Sprint Retrospective Burndown Charts

Daily Scrum Meeting

SCRUM Roles
SCRUM Roles

Product Owner

• Represents the Business side of

the Product / Software
Development

Scrum Master

• Represents the People side of the

Product/Software Development

Development Team

• Represents the Technology side

of the Product/Software
Development
Product Owner
Represents the business side of the Product/Software
Development

The Product Owner is responsible for maximizing the value of

the product and the work of the Development Team

The Product Owner is the sole person responsible for

managing the Product Backlog

Creating Product Vision

Stakeholder Management

Scope Management

Release Management
Scrum Master
Vision: Understand the product vision and lead/coach the team to
work towards it

Product Backlog Refinement: Help PO in defining and

maintaining the product backlog

Sprint Planning: Facilitate the Sprint Planning meeting & help

team to create the Sprint Backlog

Development: Coach team to self-organize and help them to

resolve the Impediments

DSM: Facilitate and help the team to inspect the progress towards
the sprint goal

Sprint Review: Facilitate and ensure that the focus is on integrated

product increments

Sprint Retrospective: Facilitate and help team to inspect and

adapt the process
Development Team
The Development Team is responsible for delivering a
potentially shippable increment of working software

Develop high quality solution to fulfil the

product/software vision

The Development Team is Self-organized

The Development Team is Cross functional

The Development Team is Empowered & autonomous

Collectively responsible for delivery

Size will be between 6 to 7 (recommended)

SCRUM Sprint
The Sprint
The heart of Scrum is a Sprint

A sprint is a set period of time

during which specific work has to
be completed and made ready for
review

Time-box of one month or less

Sprints consists of the Sprint

Planning, Daily Scrums, the
development work, the Sprint
Review, and the Sprint
Retrospective
During which a A new Sprint starts
“Done”, useable, immediately after No changes are made that would
and potentially the conclusion of compromise the Sprint Goal
shippable product the previous Sprint
Increment is created Scope may be clarified and re-negotiated
between the Product Owner and
Development Team as more is learned.
Timeboxing
Its fixed span of time called as Sprint in
Scrum which has:
Fixed Goal, Fixed Team, Fixed Length, Product Increment at the
end

Maximum length of the Sprint

-Recommended by Scrum framework is 4 weeks

Why Timeboxing?
- Helps stay focused on the Goal
- If we don't decide the time box of any ceremony or
events, then some people will keep on discussing and
others will lose interest
- Moreover, the team will get less time to work on sprint
tasks. So having the timeboxes is very important to keep
people motivated
Activities/Events/Ceremonies in SCRUM

Product
Daily Sprint
Backlog Sprint Sprint
Scrum Retrospec
Refineme Planning Review
Meeting tive
nt
Product Backlog Refinement-
Timebox [Up to 10% of Sprint Capacity]

Purpose Participants
Understand the Scrum Team,
Product Backlog optionally the
and keep it ready other SMEs
for at least couple
of Sprints

Input Output
Product Backlog Sprint Backlog
Sprint Planning- Timebox [Max 2-8 hours]

Purpose Participants
For Scrum Team Scrum Team
to craft a Sprint Activities:
Goal and create a 1. Craft a Goal: Answer why
plan to achieve it
are you running this sprint
2. Create a Plan: Identify
Inputs Outputs PBIs (Product Backlog
Product Backlog, Sprint Goal, Items) required to achieve
Capacity, Product Sprint Backlog,
Increment Sprint Burndown the Sprint Goal and commit
based on Teams Velocity.
Sprint Planning- Timebox [Max 2-8 hours]
• Daily Scrum- Timebox [Max 15 minutes]

Activities:
Purpose Participants 1. Inspect: Where do we stand
A formal Development Team, with respect to the Sprint
opportunity to Scrum Master,
inspect the teams Product Owner Goal?
progress with (optional)
respect to Sprint
2. Identify: Are there any
Goal impediments to making
progress?
Inputs Output 3. Adapt: What should we do to
Sprint Backlog, Action item to achieve Sprint Goal?
Sprint Burndown resolve impediments
3 Important Questions
1. What work did you complete
yesterday?
2. What have you planned for
today?
3. Are you facing any problems or
issues?
Sprint Review- Timebox [Max 1-4 hours]
Activities:
Purpose Participants 1. Report: Product Owner
For stakeholders to Scrum Team, explains the Sprint Goal and
review the work Sponsors,
done by the Scrum Customers, End what is done and not done
team and provide Users etc
feedback 2. Demo: Development Team
demos the Product Increment
and Stakeholders provide
Inputs Output
Product Increment, Updated Product
feedback
Sprint Goal, Backlog 3. Forecast: Product Owner
Release Burndown
discusses the Product Backlog
as it stands today and
projected completion date
Sprint Retrospective - Timebox [Max 1-4 hours]

Activities:
Purpose Participants 1. Reflect Back: Scrum
Formal opportunity to Scrum Team Team discusses how the
review how the last Sprint
went and identify areas for Sprint went and identify
continuous improvement
for future Sprints root causes and action
items for improvement
2. Look Forward: Identify
Inputs Output improvement ideas for
Sprint Burndown, Action items for continuous improvement
Impediment List, next sprint
Comments from
Sprint Review
Artifacts of SCRUM

Product
Increment
Sprint
Backlog

Product
Backlog
Product Backlog

Anything and everything required to fulfill

the product vision contains

• Functional Requirements
• Non-functional Requirements
• Change Requests
• Enhancements
• Defects
• POC (Proof of Concept)
• Should be detailed enough
Sprint Backlog

It’s a plan which helps Development Team to

self-organize to achieve the Sprint Goal

• The PBI’s that team plans to deliver to

achieve Sprint Goal
• Tasks required to accomplish planned PBI’s
Product Increment

It’s an integrated increment of final

product released iteratively

• Software Package
• Release Notes
• User Manual
• Support Documents etc.
Burndown Chart
• Development team uses the Sprint burndown for
inspecting the progress with respect to the Sprint Goal
and determining the plan to achieve the Sprint Goal
• Development Team creates during the Sprint Planning
• Development Team updates the burndown as and when
the work is done
Agreements In SCRUM

Definition Of Ready Definition of Done

• Its any entry criteria agreed by • Its an exit criteria agreed by
Product Owner and Development Product Owner and Development
Team to start the development of Team to consider a PBI is done
Product Backlog Item and ready to be shipped

• Examples: • Examples:
• No open questions about PBI • Coded
• Acceptance criteria written • Reviewed
• No technical dependencies • Bug Fixed
• PBI estimated and split small • Packaged
enough to fit in to a Sprint • Test Cases Written
• Tested
• Integrated
• Deployed
• Accepted by Product Owner
User Stories
• User Stories are Product Backlog Items that are descriptions of
functionality
• The User Story always takes the form:
– Who (user role) – Is this a customer, employee, admin etc.?
– What (goal) – What functionality must be
achieved/developed?
– Why (reason) – Why does user want to accomplish this
goal?
– Example:
“As a frequent traveler I want to be able to quickly rebook
frequently booked flights so that I can save time during the booking
process”
User Stories
• A Story is an:
– Independent
– Negotiable
– Valuable
– Estimable
– Sized properly
– Testable
Planning Poker
• Its an iterative approach to estimating

• Steps:
- Each estimator is given a deck of cards, each card has a valid estimate
written on it
- Customer/Product owner reads a story and it’s discussed briefly
- Each estimator selects a card that’s his or her estimate
- Cards are turned at the same time
- Discuss differences (especially outliers)
- Re-estimate until estimates converge
Velocity
• It’s a measure of how much work a Scrum Team can do in a
Sprint
• It’s calculated at the end of the Sprint by summing up story
points associated with the Product Backlog items done
• Used to calculate approximate cost of release and track release
progress
Let’s Play (ACTIVITY)
Design an
Hit the Given Target As many number of times as you can within the
stipulated time from a specific Distance by travelling smoothly.
Agile Benefits
Customer: High-value features are developed and delivered more quickly with short
cycles, than with the longer cycles favored by classic “waterfall” processes

Development Teams: Team members enjoy development work, and like to see their work
used and valued. Scrum benefits Team members by reducing non-productive work (e.g.
writing specifications or other artifacts that no one uses), and giving them more time to do
the work they enjoy

Product Managers: Product Managers, who typically fill the Product Owner role, are
responsible for making customers happy by ensuring that development work is aligned
with customer needs. Scrum makes this alignment easier by providing frequent
opportunities to re-prioritize work, to ensure maximum delivery of value

Project Managers: Project Managers who fill the Scrum Master role find that planning and
tracking are easier and more concrete, compared to waterfall processes. The focus on task-level
tracking, the use of Burndown Charts to display daily progress, and the Daily Scrum meetings, all
together give the PM’s awareness about the state of the project at all times

Top Management: Scrum provides high visibility into the state of a development project,
on a daily basis. External stakeholders, such as top executives and personnel in the
Project Management Office, can use this visibility to plan more affectively, and adjust
their strategies based on more hard information and less speculation
Pros & Cons of SCRUM
Pros Cons
• Is a very realistic approach to software • Not suitable for handling complex
development dependencies
• Promotes teamwork and cross training • More risk of sustainability,
• Functionality can be developed rapidly maintainability and extensibility
& demonstrated • An overall plan, an agile leader and
• Resource requirements are minimum agile PM practice is a must without
• Suitable for fixed or changing which it will not work
requirements • Depends heavily on customer
• Delivers early partial working solutions interaction, so if customer is not clear,
team can be driven in the wrong
• Good model for environments that
direction
change steadily
• There is very high individual
• Minimal rules, documentation easily
dependency, since there is minimum
employed
documentation generated
• Enables concurrent development and
• Transfer of technology to new team
delivery within an overall planned
members may be quite challenging due
context
to lack of documentation
• Little or no planning required
• Easy to manage
• Gives flexibility to developers
Scrum Summary
Waterfall v/s Agile
Agile v/s Waterfall

Waterfall Approach
Design Spec Code UAT Launch

Change Management & Approval

Agile Approach
Users
Stories Sprint Sprint Sprint
Agile v/s Waterfall
Questions ?
Thank You