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

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

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

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

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

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

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

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.

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

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