Agile Life cycle managing IT product development

1. Agile Lifecycle Handbook By Bhawani Nandan Prasad (MBA – Marketing and Strategy, B.E. Comp Sc)
Introduction
Agile denotes “the quality of being agile; readiness for motion; nimbleness, activity, dexterity in
motion”, implying light weight along with faster and nimbler software development process. Agile
methodology is aimed at rapidly growing and volatile internet software industry as well as the
mobile application environment.
Agile is concerned with producing software that meets the user's needs within the shortest possible
time. The user is usually involved in the iterative production process. Agile software processes are
characterized by accelerated delivery of working software at any stage in the development process.
The emphasis is on customer collaboration, communication and teamwork. Thus requirements may
change anywhere in the process and the process is adaptive to the change
Agile software life cycle is an iterative process where software is ready at each iteration but can
always be improved by further iteration. There is minimal documentation and maximum emphasis
on direct face-to-face communication. Agile software is adaptable to fast changes and is ideal for
small teams who have to deliver workable software within a very short deadline.
Existing Agile Methods
Given below are some of the popular methodologies that seem to represent the Agile methodology:
 Extreme Programming
 Scrum (this document focuses on Scrum methodology)
 Crystal Family of methodologies
 Feature Driven Development
 Rational Unified Process
 Dynamic Systems Development Method
 Adaptive Software Development
 Open Source Software Development

2. Overview of Scrum Lifecycle
Scrum Lifecycle consists of three phases:
1. Pre-game: This in turn consists of the following sub-phases:
a. Pre-Planning
b. Architecture/High Level Design
c. Sprint Planning
2. Development iterations:
The development phases consist of Sprints that are iterative cycles. One Sprint lasts
between 1 week to 1 month. There may be 3 to 8 sprints in a software development process
before a system is ready for distribution.
3. Post-game: This in turn consists of sub-phases as follows:
a. Product Integration
b. System Testing
c. Documentation

3. The Scrum Lifecycle
1.1. Pre-Planning Phase
1.1.1. Purpose
The Planning Phase focuses on identifying a viable project and the strategy for its execution.
1.1.2. Entry Criteria
 Need to identify viable projects
1.1.3. Inputs
 Opportunities available at hand
1.1.4. Outputs
 Selection of Projects
 High Level Problem Statement
 Product backlog for the selected Product
1.1.5. Exit Criteria
 Selection of system to be developed
1.1.6. Tasks
 The projects are prioritized and selected by the key stakeholders including management, the
customer, users, Sprint Manager as follows:
o Define the business opportunities
o Identify Viable project
o Assess feasibilities. Just enough feasibility study done to decide yes or no on the
project
o Prioritize projects based on the potential gains and other aspects
o Select Projects that are of higher priority
 Other decisions made at this phase includes the following:
o Whether to build new system or modify existing system
o the development team and its location
 Garnering support and funding for the project
 Starting to build the team

4. 1.2. Architecture/High Level Design
1.2.1. Purpose
In the architecture phase, the high level design of the system including the architecture shall be
planned based on the Product Backlog.
A design review meeting is held to go over the proposals for implementation and decisions are
made. In addition, preliminary plans for the contents of releases are prepared.
1.2.2. Entry Criteria
 Selection of system to be developed
1.2.3. Inputs
 Selection of Projects
1.2.4. Outputs
 Product Backlog updates
 Generalized use cases that captures the intentions of a user
 Architecture and High Level Design
 High Level Activity diagram
 High level workflow
 Standards, Conventions, Technology, Resources
 High Level estimates
1.2.5. Exit Criteria
 Approved Architecture and High Level Design
1.2.6. Tasks
This phase involves the following tasks by the Sprint team:
 Define high level scope
 Define Technology stack
 High level analyses and Design
 Setting up the environment
 Estimating the project at high level

5. 1.3. Sprint Planning
1.3.1. Purpose
The Sprint Planning meeting is carried out for each sprint with the purpose of defining the Sprint
backlog for the next Sprint.
1.3.2. Entry Criteria
 Need to plan for the next Sprint
1.3.3. Inputs
 Product Backlog
1.3.4. Outputs
 Updated Product backlog
 Sprint Goal and Sprint Backlog finalized for the next sprint
 Estimates and Plan for the next sprint
1.3.5. Exit Criteria
 Approved plan for the next Sprint
1.3.6. Tasks
 The Scrum Manager along with Scrum team shall review the latest Product Backlog. During
this process, new items may be added or existing items modified or deleted in the Product
Backlog. The priority may be revised.
 Based on the updated priority, a set of items shall be selected for the next sprint and
commitment taken from the Sprint team. This establishes the Sprint Goals and the Sprint
Backlog for the next Sprint.
 The following are assessed for the next sprint:
o Assess resource requirements
o Risk and Issues Management
o Training needs
 Just enough Analysis and Design shall be performed by the Scrum team so as to give good
estimates.
 The Scrum Manager prepares the plan for the next sprint
 Finally, seek necessary approvals from the management, customer and users on the Sprint
Backlog for the next Sprint.
1.3.7. Verification
 Review and Approval of Sprint Backlog

6. 1.4. Development Iterations
1.4.1. Purpose
During Development iterations, high-quality working software is incrementally delivered that
meets the changing needs of our stakeholders. Each iteration is called a Sprint.
Each sprint consists of traditional phases – Requirements, Analysis, Design, Evolution and Delivery.
Each Sprint involves development or enhancements of new functionality. One Sprint lasts between
1 week to 1 month. There may be 3 to 8 sprints in a software development process before a system
is ready for distribution.
1.4.2. Entry Criteria
 Approved plan for the next Sprint
1.4.3. Inputs
 Updated Product backlog
 Sprint Goal and Sprint Backlog
 Sprint Plan
1.4.4. Outputs
 Agile class diagrams depicting data layer objects
 Agile class diagrams depicting business layer objects
 Agile sequence diagrams for complex logic
 User interface mock-ups and flows
 Working Code
 Defects and their status
1.4.5. Exit Criteria
 Working Code is complete
1.4.6. Tasks
 All stakeholders collaborate during this phase to reduce the risk through fast feedback cycle.
 Analysis and Design is carried out Just in time. This involves the following steps:
o Refine the requirements (The requirements evolve throughout the project)
o Refine the Architecture and design of the system (The architecture and design
evolves during the sprint development).
o Model shall be done in a manner that you can always come back later
o All stakeholders shall actively participates
o Issues are intended to be resolved just in time
 The functionality is coded in the order of priority. This may be accomplished through
practices such as follows:
o Active stakeholder participation
o Test Driven development
o Pair programming
o Accomplished in iterations

7. o Develop Incrementally
o Code refactoring
 The quality is assured through guidance like coding convention and other guidelines.
 Confirmatory testing: The developers shall perform development testing to confirm the
design and the users shall perform agile acceptance testing to confirm the requirements.
This isn't the complete testing because we are producing working software on a regular
basis.
 Independent Testing: This involves the following:
o System Testing/Function Testing. This is performed by test professionals who are
good at finding defects which the developers have missed.
o User Testing
 Majority of testing is done during each construction cycle so that the testing in the release
iteration is smaller.
 Daily Scrum meetings that are conducted by the Scrum Master and attended by Product
owner and Scrum team. The management can also participate in the Scrum meetings.
During this meeting, the following are reviewed:
o Assess Velocity to check the progress
o Work completed
o Issues and Risks
o Work planned for the next days

8. 1.5. Post Game (or Release Iteration)
1.5.1. Purpose
During the release iteration(s), also known as the "end game", the system is transitioned into
production. Not that for complex systems the end game may prove to be several iterations, although
if you've done system and user testing during construction iterations this likely won't be the case
1.5.2. Entry Criteria
 Working Code is complete
1.5.3. Inputs
 Working Code
1.5.4. Outputs
 Integrated and tested Code
 User documentation
 Deployment of code
 Scrum Review Checklist
1.5.5. Exit Criteria
1.5.6. Tasks
 Product Integration. This involves integrating the code with the previous build.
 Final testing of the system. Final system and acceptance testing should be performed at
this point, although the majority of testing should be done during construction iterations.
 Rework the code
 User documentation. Some documentation may have been written during construction
iterations, but it typically isn't finalized until the system release itself has been finalized to
avoid unnecessary rework. Documentation is produced if the stakeholder is willing to pay
for it.
 Training. Train end users, operations staff, and support staff to work effectively with our
system
 Deploy the System
 Daily Scrum meetings that are conducted by the Scrum Master and attended by Product
owner and Scrum team. The management can also participate in the Scrum meetings.
1.6. Sprint Review meeting
This is held on the last day of a Sprint. In this meeting, the Scrum team and Scrum master present
the result (i.e. the working product increment) of the Sprint to the management, customers, users
and the Product Owner.
The review meeting may bring out new Backlog items and even change the direction of the system
being built.
These meetings are informal.

9. Scrum master reviews whether project is carried out in accordance with Scrum values, practices and
rules and it progresses as planned. The following checklist is used for the purpose:
 Scrum Review Checklist

10. Scrum in a nutshell Metrics
Stage
Event/
Meeting
Led/
Facilitated
by
Participants Frequency Artifacts
1 Strategy *
Product
Owner
Key
stakeholders
(Customer and
Users), Sr
Executive
Once a
year
Vision
Statement *
2
Define
Product
Roadmap *
Product
Owner
Key
stakeholders
(Customer and
Users)
Twice a
year
Product
Roadmap *
Themes *
3
Release
Planning
Meeting *
Product
Owner
Development
team,
SCRUM Master
(Optional)
Once a
quarter
Product Backlog
Epics
User Stories
4
Sprint
Planning
Meeting
Product
Owner
Development
team,
SCRUM Master
At
beginning
of sprint
Sprint Backlog
User Stories
Tasks
5
Daily
SCRUM
SCRUM
Master
Development
team, Product
Owner (as
desired)
Daily
Task Board
Sprint Burndown
Chart
6
Spring
Review (End
Meeting #1)
Product
Owner
Key
stakeholders
(Customer and
Users),
Development
team
At end of
Sprint
Potentially
shippable
increment, User
acceptance
7
Sprint
Retrospective
(End Meeting
#2)
SCRUM
Master
Development
team,
At end of
Sprint
Release
Burndown Chart