AGILE PROCESS HANDBOOK

01/09/2016

Arivarasan I

Assurance

Chennai
arivarasan.i@tcs.com
 Confidentiality Statement
Include the confidentiality statement within the box provided. This has to be legally
approved
Confidentiality and Non-Disclosure Notice
The information contained in this document is confidential and proprietary to TATA
Consultancy Services. This information may not be disclosed, duplicated or used for
any other purposes. The information contained in this document may not be
released in whole or in part outside TCS for any purpose without the express written
permission of TATA Consultancy Services.

Tata Code of Conduct

We, in our dealings, are self-regulated by a Code of Conduct as enshrined in the
Tata Code of Conduct. We request your support in helping us adhere to the Code in
letter and spirit. We request that any violation or potential violation of the Code by
any person be promptly brought to the notice of the Local Ethics Counselor or the
Principal Ethics Counselor or the CEO of TCS. All communication received in this
regard will be treated and kept as confidential.

2
About this Manual:

Purpose:
The objective of this manual is to describe how agile methods can be applied in multi-site software
development projects of any scale.
This manual aims at describing the end-to-end software development process in a hands-on fashion, addressing
issues like responsibilities, interfaces between process steps and criteria for scaling the project setup.
Agile Software Development is a behavioural shift and can work well in the context of any operating and
delivery model.
There are several basic practices to adhere to, while embarking on Agile Software Development. Yet, within a
couple of iterations, agile practitioners should capture the spirit of these practices and continuously adapt them
to their context.

Intended Audience:

This manual is for use by all development projects being executed in or intending to execute in agile framework.
In addition, it can be referred to by projects, of any type and methodology, which intend to adopt practices of
agile framework.
The manual is also for use by support groups like Delivery Assurance to understand the areas of interface of
their groups with the project activities.

Overview:
Section 1 defines software process and related concepts such as architected process, operational process and
process structure as an Entry-Task-Verification & Validation-Exit (ETVX) model.

Section 2, the Phase Guide, describes the phases in an agile development project in terms of the Entry-Task-
Verification & Validation-Exit model. It also lists the common entry criteria and common activities applicable
across all phases.

Section 3, the Practice Guide, details the various agile practices. The nature of a project can vary depending on
the project type, processes included, people involved, scope and time for the project. The various practices
elaborated in the Practice Guide are set as guidance for the project. The Practice Guide outlines the significant
values, characteristics and success factors of various agile and lean practices and provides guidance to agile
(and other) teams in selecting practices that add value in the context of their projects, programs or portfolio As
with everything else in an agile project, the teams have to continuously Inspect and Adapt the practices used
3
and how they are operationalized in the project. While doing so, the team must keep in mind the relevance and
value with respect to the change.

The general benefits of agile models are team and business centric. Hence it is more dependent on client and
TCS ecosystem and less specific to project types. However it has proven more useful and successful for full-cycle
large ADM projects and programs, large enhancement projects on BIPM, smaller ADM projects when applied
for transformed customers.
The practices described in this manual and the importance of usage of these practices varies based on various
factors. The following factors should be considered in determining the practices for the project / program:

Custom-made software for a specific client or an off-the-shelf product

Location of the project team (Onsite/Offshore/Both)
Type of project or program
Project/Program solely driven by TCS or shared with other vendors
Number of versions and variants of product to be maintained
Software Risk Category

The users of this document should use their judgment to select activities relevant to the scenario in which they
are functioning and use this document effectively.

Section 4 lists the various Planning and Adapting artefacts.

4
LIST OF FIGURES

Figure 1 Agile Architected Process Page 8

Figure 2 Burn down charts/Graph Page 23

5
 CONTENTS

SECTION 1PROCESS FRAMEWORK

1.1 What is a Software Process..........................................................................8

1.2 Architected Process............... 8

1.3 Operational Process .......9

1.4 Process Structure...9

1.4.1 Phases......9

1.4.2 Activity and ETVX Model.......10

1.4.3 Organizational Roles....10

1.4.4 Work Items.....11

SECTION 2PHASE GUIDE

2.1 Phases in Architected Process.....12

2.1.1 Agile requirements gathering...13
2.1.2 Product Backlog Creation....13
2.1.3 Pre Sprint Story Review....13
2.1.4 Sprint Planning...13
2.1.5 Sprint Backlog Creation....14
2.1.6 Sprint/Iteration.....14
2.1.7 Daily Scrum......14
2.1.8 Sprint review.......15
2.1.9 Retrospective and Demonstration.........15

2.2 Common Entry Criteria.......15

2.3 Common Project Activities....16

2.4 Common Artifacts...17

2.4.1 Product Backlog....17

2.4.2 Sprint Backlog.......17
2.4.3 Definition of Done...18

6
SECTION 3PRACTICE GUIDE

3.1 Release Planning..18

3.2 Joint Application Design (JAD)....18

3.3 Iteration Planning....18

3.4 Test Driven Development...19

3.5 Cross Team Synchronization....19

3.6 Release Retrospective...20

3.7 Management Retrospective....20

SECTION 4ARTIFACTS GUIDE

4.1 Planning Artifacts ...20

4.1.1 Product Backlog......21

4.1.2 Iteration Backlog........21

4.1.3 Definition of Done......22

4.1.4 Product Vision..22

4.1.5 Release Plan......22

4.1.6 Iteration Goal....23

4.2 Adapting Artifacts ..23

4.2.1 Burndown Chart....23

4.2.2 Taskboard..24

4.2.3 Status Reports..24

7
1 AGILE PROCESS FRAMEWORK:

1.1 What is Agile Process?

Agile process is a SDLC model, a combination of iterative and incremental process
models with focus on process adaptability and customer satisfaction by rapid delivery
of working software product.
In agile, the tasks are divided to time boxes (iterations) with small time frames to
deliver specific features for a release.
The prime feature of agile is a working software build is delivered after each iteration.
Each build is incremental in terms of features; the final build holds all the features
required by the customer.
1.2 Architected process

The Agile process can be divided into set of project or program specific processes.
The Process frame work explained here is Scrum. It consists of Scrum Teams and their
associated roles, events, artifacts, and rules.
Each component within the framework serves a specific purpose and isessential to
8

Figure 1
 Scrums success and usage.

1.3 Operational Process

The Scrum model which is being followed may have time frame of 2 weeks to 1 month
per iteration.
Scrum employs an iterative, incremental approach to optimize predictability and
control risk.
Threepillarsuphold everyimplementation of this operational process are:

o Transparency- Significant aspectsbe defined by a common standardso

observersshare a common understanding ofwhatisbeing seen.
o Inspection- Scrum artifactsand progresstoward a SprintGoal must be
inspected todetect undesirable variances.
o Adaptation- An adjustment mustbemadeassoonaspossibleto the process
or the product to minimize further deviation from acceptable limits.

1.4 Process Structure

1.4.1 Phases
The Five major phases of agile model are;
o Project Initiation- This is agile's version of a high-level business requirement.
Basically, a Product Owner conducts interviews with stakeholders about their
goals for the product.
o Iteration planning- This is important before every iteration /Sprint begins
while Product Owner is involved in scope discussions, the Scrum Master (PM)
and QA work directly with Dev to ensure that scope and acceptance levels are
understood from the onset.
o Iteration progress- The Iteration or sprint has a definition of what is to be
built, a design and flexible plan that will guide building it, the work, and the
resultant product.
o Iteration Retrospective- The purpose of the retrospective is to inspect,
identify and improve the items that does not gone well in the iteration

9
 o Demo- Demo is where the tech team determines if the delivered product meets
expectations. This is where the working piece of software will be showcased to
the business team

1.4.2 Activity and ETVX model

Activity is the work that will be practically carried over delivering a functional
requirement.
ETVX model is some set of criteria pertained to complete the tasks related to that
activity. ETVX Stands for,

o Entry Criteria- The requirements must be in a User story format in a

business language. This will be interpreted to the technical team
o Tasks- A set of tasks that will be estimated while iteration planning
which shows the time needed to complete the activity.
o Verification and Validation- The activity will go through reviews,
quality checks to conform to the acceptance criteria.
o Exit criteria- All the tasks should be completed and closed to get that
activity to a completion state.

1.4.3 Roles in Agile

Scrum Teams deliver products iteratively and incrementally, maximizing
opportunities for feedback.
The Scrum Team consists of a Product Owner, the Development Team, the
Quality Assurance team, a business analyst and a Scrum Master.
The various roles in the Scrum team are explained as,
o Product Owner- Responsible for clearly expressing Product Backlog
items and maximizing the value of the product and the work of the
Development Team.
o Development Team- Professionals who do the work of delivering a
potentially releasable Increment of Done product at the end of each
Sprint.

10
 o Quality Assurance Team- involves in verifying and validating the
integrity of the releasable increment that has been developed by the
development team.
o Business Analyst- interprets the business requirement given by the
product owner and translates to the development and QA team in a
technical format.
o Scrum Master- is the leader for the Scrum Team who helps those outside
the Scrum Team understand which of their interactions with the Scrum
Team are helpful and to maximize the value created by the Scrum Team.

1.4.4 Work Items

The artifacts that are generated during the course of the project are considered
as work items. There are two types of work items: Product work Items and
Process work items
The Product work items are the artifacts that are used in the operation process
of the agile model. Some of them are,
o Product Vision-a Vision Document describes ideas or values or future
state for a particular organization, product or service.
o Product backlog-a document that describes the upcoming work on the
product.
o Sprint/Iteration backlog-Describes what functionality will be in the
next Increment and the work needed to deliver that functionality into a
Done Increment.
o Developed code or source code- an abstraction, but a detailed one
which convey instructions in a persistent manner with the comments
describing the instructions to the computer system
The Process work items are the artifacts that are generated with result obtained
during the course of the sprint/iteration. Some of them are,

11
 o Design review documents-The design ideas and information about the
development of the code which will assist the peer review to verify our
software design and source code.
o Daily status reports-The information about the iteration progress will be
sent by QA with the status of each and every user story that was
committed to deliver in the current sprint/iteration.
o Burn down charts-It is a graphical representation of workflow left to do
in that iteration. It will be compared with the actual work done till date
and useful for predicting when work will get completed.
o Requirements Traceability Matrix (RTM):Requirements should be
mapped to appropriate Management Release and Cycle. They must be
imported into ALM using Rally Connector Tool.
o Test Summary Report:Tests that has been carried out during the entire
release cycle with defects, test runs, requirements collectively included
and generated as a Summary report from ALM.

2. PHASE GUIDE

2.1 Phases in Architected Process

2.1.1 Agile requirements gathering

Agile projects start with basic requirements gathering. Knowing the goals of your
end users and project stakeholders is the necessary first step to any successful
project.
The Requirements gathered will be broken into short descriptions of the
functionality in customer terms called User Stories.
Initial User Stories (Informal and formal) which describes the piece of
requirement in user simple (informal) format and in a very formal business
format as
o As a (role) I want (something) so that (benefit).

12
 The User stories are very important while scheduling and estimation during
planning phase of an iteration.
A user story have three important sections.
o Description of the story
o Acceptance criteria
o Benefit of the story

2.1.2 Product backlog

The Product Backlog is an ordered list of everything that might be needed in the
product and is the single source of requirements for any changes to be made to
the product.
The Product Owner is responsible for the Product Backlog, including its content,
availability, and ordering.

2.1.3 Pre Sprint Story Review a.k.a pre-planning

When going before the actual planning meeting, the sprint team needs to have:
o A fully prioritized backlog
o User-stories which fit into sprints
o Acceptance criteria for all user-stories
The idea of the pre-planning is to make sure the team is as informed as possible
for starting the sprint planning.
Holding these pre-planning meetings should not become a distraction to the
work of the sprint, it should be time-boxed to a manageable amount of time and
it should possibly be scoped into the previous sprint.
2.1.4 Sprint Planning
The work to be performed in the Sprint is planned at the Sprint Planning. This
plan is created by the collaborative work of the entire Scrum Team.
Sprint Planning answersthefollowing:
o Whatcan bedeliveredin theIncrementresulting fromtheupcoming Sprint?
o How will the workneededtodelivertheIncrementbe achieved?

13
2.1.5 Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint,
plus a plan for delivering the product Increment and realizing the Sprint Goal.
The Sprint Backlog makes visible all of the work that the Development Team
identifies as necessary to meet the Sprint Goal.
The Sprint Backlog is a plan with enough detail that changes in progress can be
understood in the Daily Scrum/Stand-up meeting.

2.1.6 Sprint
The heart of Scrum is a Sprint, a time-box of one month or less during which a
useable, and potentially releasable product Increment is created.
Sprints best have consistent durations throughout a development effort.
A new Sprint starts immediately after the conclusion of the previous Sprint.

2.1.7 Daily Scrum/meeting

The Daily Scrum is a 15-minute time-boxed event for the Development Team to
synchronize activities and create a plan for the next 24 hours.
This is done by inspecting the work since the last Daily Scrum and forecasting
the work that could be done before the next one.
Every team member should report the following in scrum:
o What did I do past day that helped the team meet the Sprint Goal?
o What will I do today to help the team meet the Sprint Goal?
o Do I see any impediment that prevents me or the Team from meeting
theSprint Goal?
2.1.8 Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and
adapt the Product Backlog if needed.

14
 During the Sprint Review, the Scrum Team and stakeholders collaborate about
what was done in the Sprint.
If any changes needs in the Product Backlog during the Sprint, attendees
collaborate on the next things that could be done to optimize value.

2.1.9 Retrospective and Demonstration

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself
and create a plan for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next
Sprint Planning.
Demo at the end of each sprint, the team will demonstrate a coded, tested and
usable piece of software.
During this meeting, the Scrum team shows what they accomplished during
the sprint.

2.2 Common Entry Criteria

Requirements Gathered should be categorized and prioritized and placed in the
Product backlog.
The Product owner should define scope of each items in the product backlog.
Ordering the items in the Product Backlog to best achieve goals and missions.
Optimizing the backlog items to ensure the value of the work the Development
Team performs.
Ensuring that the Product Backlog is visible, transparent, and clear to all, and
shows what the Scrum Team will work on next; and,
Ensuring the Development Team understands items in the Product Backlog to
the level needed.
Scrum Master plans and facilitates the scrum events as required.
Determine an achievable Sprint goa as what can be done in the upcoming sprint
with estimated hours need to complete the committed requirements.

15
 Ensure all the hardware and software resources are ready to complete the sprint
goal.

2.3 Common Project Activities

As the Development Team works, it keeps the Sprint Goal in mind. In order to
satisfy the Sprint Goal, it implements the functionality and technology.
If the work turns out to be different than the Development Team expected, they
collaborate with the Product Owner to negotiate the scope of Sprint Backlog
within the Sprint.
Daily Scrum is a stand-up meeting conducted for every 24 hours to monitor and
discuss about the progress of the current sprint.
As the team is a cross functional one, the developers will propose their design to
the team, which will be validated among the architect and project management.
The Quality Assurance (QA) team will do their analysis, design their test cases
and review it with the business analyst to verify the integrity of the test
scenarios.
Once the Development team completed their code, it will be unit tested and sent
to QA check.
QA team will do their verification and checks on the code against the acceptance
criteria in the user story.
If the code passes the checks, then they will certify the story as working and send
it to the User Acceptance Testing (UAT).
At the end of the sprint, Sprint Review is held to inspect the Increment and adapt
the Product Backlog if needed.
Ensure Requirements are mapped to appropriate Management Release and Cycle
and generate Requirement Traceability Matrix (RTM) and Test Summary Report
(TSR).
In Sprint retrospective, the Scrum Team have identified improvements that it
will implement in the next Sprint.

16
 The Increment product developed during the sprint will be regression tested in
an environment which resembles the production.
After the regression, if the increment works well without introducing any defect
in the existing system, then it will be released to the production environment.

2.4 Common Artifacts

2.4.1 Product Back log:

This is an important artifact that will be maintained throughout the
sprints that are happening for a particular project.
The Product Backlog lists all features, functions, requirements,
enhancements, and fixes that constitute the changes to be made to the
product in futurereleases.
Product Backlog items can be updated at any time by the Product Owner
or at the Product Owners discretion.

2.4.2 Sprint Backlog:

TheSprintBacklog isthe set ofProductBacklog itemsselected for the Sprint,plusaplan
for delivering theproductIncrementand realizing theSprintGoal
TheSprintBacklog makes visibleall of the work thatthe Development Team
identifiesas necessaryto meet theSprint Goal.
TheDevelopmentTeam modifiesthe SprintBacklog throughout theSprint,and
theSprintBacklog emerges during theSprint.

2.4.3 Definition of DONE

When a ProductBacklog item or an Increment is described asDone.
Thisis thedefinition of Done for the Scrum Team and isused to assess when work
iscomplete on the productIncrement.
Thesamedefinition guides theDevelopment Team in knowing how many
ProductBacklog items itcan select during a Sprint Planning.

17
3 PRACTICE GUIDE
3.1 Release Planning
The purpose of release planning is to commit to a plan for delivering
an increment of product value.
Before getting started, release planning needs:
o A ranked product backlog managed by the product owner
o Input from the team about overall capabilities, known velocity,
and technical impacts
o High-level vision, market, and business objectives
o An acknowledgment of whether new product backlog items may
be needed.

3.2 Joint Application Design

Joint Application Development (JAD) is a user requirements elicitation

process that involves the system owner and end users in the design and
development of an application through a succession of collaborative
workshops called JAD sessions.
JAD emphasizes producing a requirements specification and optionally a
prototype, Agile focusses on iterative development.
Both requirements and the end software product evolve through regular
collaboration between self-organizing cross-functional teams.

3.3 Iteration/Sprint Planning

The input to this meeting is the Product Backlog, the latest product
Increment, projected capacity of the Development Team during the
Sprint, and past performance of the Development Team.
The numberof itemsselected fromthe ProductBacklog for theSprintis
solely up tothe DevelopmentTeam.

18
 After the Development Team forecasts the Product Backlog items it will
deliver in the Sprint, the Scrum Team crafts a Sprint Goal.

3.4 Test Driven Development

Instead of writing functional code first and then your testing code as an
afterthought, if you write it at all, you instead write your test code
before your functional code.
There are two levels of TDD:
o Acceptance TDD (ATDD). With writing single acceptance test, or
behavioural specification, and then just enough production
functionality/code to fulfil that test.
The goal of ATDD is to specify detailed, executable
requirements for your solution on a just in time (JIT).
ATDD is also called Behaviour Driven Development (BDD).
o Developer TDD. With developer TDD you write a single
developer test, sometimes inaccurately referred to as a unit test,
and then just enough production code to fulfil that test.
The goal of developer TDD is to specify a detailed,
executable design for your solution on a JIT basis.
Developer TDD is often simply called TDD.

3.5 Cross team synchronization

Cross-functional teams (CFTs) can be defined as "groups that are made

up of people from different functional areas within a company."
These teams are empowered to make decisions at a lower level than is
customary, allowing them handle the entire scope of a project from start
to finish.

19
 3.6 Release Retrospective
A release retrospective is an opportunity to inspect and adapt the
release cycle rather than the sprint cycle. Of course, the inspection
points would vary when it comes to the release.
The basic idea of doing a release retrospective is to review and evaluate
an entire release.
This meeting would be held at the end of the release and usually before
starting the next release cycle.
3.7 Management Retrospective
During this meeting, the team reflects on what happened in the iteration
and identifies actions for improvement going forward.
This meeting will be held at the end of the each sprint.
The things that are not went well will be given priority and discussed to
improve in the next sprint.

4 ARTIFACTS GUIDE
4.1 Planning Artifacts
4.1.1 Product Backlog
As a product is used and gains value, and the marketplace provides
feedback, the Product Backlog is a larger and more exhaustive list of
user requirements ordered in a prioritized manner.
It will be constantly updated or changed whenever a requirement is
updated.
Not only changesin businessrequirements, also when marketconditions,
or technology change maycausechangesin the ProductBacklog.
TheProduct Backlog listsall
requirements,enhancements,features,functions and fixesthat constitute
thechanges tobemadeto theproductin futurereleases.

20
 The Product Owner is responsible for the Product Backlog, including its
content, availability, and ordering.

4.1.2 Iteration Backlog

The Sprint Backlog is a plan with enough detail that changes in progress
can be understood in the Daily Scrum
The Sprint Backlog makes visible all of the work that the Development
Team identifies as necessary to meet the Sprint Goal
As new work is required, the Development Team adds it to the Sprint
Backlog
As work is performed or completed, the estimated remaining work is
updated.
When elements of the plan are deemed unnecessary, they are removed.
4.1.3 Definition of Done
The purpose of each Sprint is to deliver Increments of potentially
releasable functionality that adhere to the Scrum Teams current
definition of Done.
This is the definition of Done for the Scrum Team and is used to assess
when work is complete on the product Increment.
If there are multiple Scrum Teams working on the system or product
release, the developer teams on all of the Scrum Teams must mutually
define the definition of Done.
4.1.4 Product vision
The first stage in an agile project is defining your product vision.
It should be a quick summary to communicate how your product
supports the companys or organizations strategies.
The vision statement must articulate the goals for the product.
The four key steps to define the project goal are,
o Developing the agile product objective
o Creating a draft agile vision statement
21
 o Validating and revising the agile vision statement
o Finalizing your agile vision statement

4.1.5 Release Plan

The purpose of release planning is to commit to a plan for delivering
an increment of product value.
Release planning is a collaborative effort involving these roles:
o Scrum master Facilitates the meeting
o Product owner Represents a general view of the product backlog
o Delivery team or agile team Provide insights into technical
feasibility and dependencies
o Stakeholders Act as trusted advisors as decisions are made
around the release plan.

4.1.6 Iteration/Sprint Goal

The Sprint Goal gives the Development Team some flexibility regarding
the functionality implemented within the Sprint.
The selected Product Backlog items deliver one coherent function,
which can be the Sprint Goal.
In order to satisfy the Sprint Goal, Scrum Team implements the
functionality and technology.
The Development Team uses the Daily Scrum to inspect progress
toward the Sprint Goal and to inspect how progress is trending toward
completing the work in the Sprint Backlog

22
4.2 Adapting Artifacts
4.2.1 Burn down Charts
The burn down is a chart that shows how quickly you and your team are
burning through your customer's user stories.
It shows the total effort against the amount of work we deliver each
iteration
We can see the total effort on the left, our team velocity on the right. But
look what else this simple graphs gives us.
o Work done each iteration
o Work remaining
o Work done so far
o When we can expect to be done

Figure 2

23
4.2.2 Task Board
Task board is a dashboard of a sprint. Team members update the task
board continuously throughout the sprint.
Each product backlog item is turned into multiple sprint backlog items.
Each of these is represented by one task card that is placed on the Scrum
Task board.
Each task card starts on the Scrum task board in the To Do column.
The columns we generally use on a task board are:
o Story
o To Do
o Work In Progress
o To verify
o Done
4.2.3 Status reports

To/Cc List for Daily status report:

To: The To list should have the Distribution list for your team plus
Project Manager, Product Owners etc.
Cc: The QA Team (all QA testers working in your iteration team, QA
leads, QA Manager (in CC) in the status email.
Since there are multiple projects within same Iteration team, the
project name should be added after the team name in daily status
reports.
Test Execution Status should be changed from Not Started to Code
Not Ready to Test in the daily status report. Not started prompts a
question in readers mind why its not started?
Is the code not ready/deployed to test or Testers/Environments are not
available to test. Calling it out as Code Not Ready to Test will make it
clear

24
Thank You

25