Agile Development Lifecycle

ID 36929648

Page Version 12

Content Type Process Definition

Status ACTIVE

Effective Date 03-Sep-2014

1. Status: DRAFT / ACTIVE / OBSOLETE

2. Content Type: Process
Definition/Guideline/Standard Change History...

No Notes Author Date

1 First version Naiju 10-Jan-2014

2 Add more Scrum into the Indra Adiyanto 03-Sep-2014

lifecycle

3 Change name: Project Indra Adiyanto 09-Sep-2016

Initiation Document (PID) to
Project Plan Document (PPD)

4 Change reference to Project Indra Adiyanto 20-Jul-2017

Plan Document

5 Update the DoD as decided in Indra Adiyanto 18-Jul-2018

2018-07-18 PEG Meeting

6 Formalized to SOP Harry Culaban Sible 01-Mar-2019

Contents

Overview
Agile Development is a term that covers several iterative and incremental software development methodologies. The most common agile
methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development,
and Feature-Driven Development (FDD).

All of these agile methods is unique in its specific approach; however they all share a common vision and core values (see the Agile
Manifesto). All these follow the basic principle of iteration and the continuous feedback to successively refine and deliver a software system.
There is continuous planning, continuous testing, continuous integration, and other forms of continuous evolution of both the project and the
software. Almost all of them are lightweight when compared to traditional waterfall-style processes, and inherently adaptable. As important,
they all focus on empowering people to collaborate and make decisions together quickly and effectively.

Process defined here is based on Scrum, and we build it as close as possible so we can get the maximum benefit of it.

Terms and Terminologies

 Sprint: Sprint is the basic unit of development.
Timebox: Timebox is a fixed time period for a sprint.
Product Backlog: Product Backlog is an ordered list of requirements maintained for the project.
Sprint Backlog: Sprint Backlog is the ordered list of work the Development Team should accomplish within a particular Sprint.

Roles and Responsibilities

Project Manager role is only applicable in Startup, Initiation and Closure phase, while in Sprint phase the same person can play the role of
Product Owner or Scrum Master.

Role Responsibilities Remarks

Project Manager Create the Project Proposal Applicable only in Startup, Initiation and
Perform the initial planning Closure phase
Form the team
Perform Project Closure tasks
Ensures that development process is
followed

Product Owner Clearly expressing Product Backlog
items
Ordering the items in the Product
Backlog to best achieve goals and
missions
Optimizing 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
Ensuring the Development Team
understands items in the Product
Backlog to the level needed
Who should be the product owner depends
on the type of development effort.
Internal Development:
representative/customer from the
business area benefiting.
Outsourced Development:
representative/customer from the
company paying for the solution and
receiving the benefits

Development Team Responsible for delivery Development team members should be

Take part in Estimation
cross-functionally diverse; collectively they
should possess the necessary and
sufficient set of skills to get the job done. A
well-formed team can take an item off of
the product backlog and produce a
good-quality, working feature that meets
the team’s definition of done.
Optimal Development Team size is small
enough to remain nimble and large enough
to complete significant work within a Sprint.
Fewer than three Development Team
members decrease interaction and results
in smaller productivity gains. Smaller
Development Teams may encounter skill
constraints during the Sprint, causing the
Development Team to be unable to deliver
a potentially releasable Increment.
Having more than nine members requires
too much coordination.

Scrum Master Making sure a Scrum team lives by the Not the Development Team’s assistant
values and practices of Scrum This is a servant-leader, management
Provides guidance and support for the position
Scrum Team
Removes Impediments to the
Development Team’s success that
they are unable to remove themselves
Process owner for the team, creating a
balance with the product owner
(project's key stakeholder)

Agile Process
Startup
Sl Description of Tasks Responsibility Format1 Remarks

1. Provide the justification Project Manager Project Proposal Form Take inputs from as
for the project, based on many people as possible
the cost of development like IT, users, other
and the anticipated subject matter experts,
benefits and gains. The etc. during this activity.
following tasks shall be
executed.

Build the Business

Case
Define the objective
and high-level
scope of the project
Perform the Cost
Benefit Analysis

2. Get the Project Proposal Project Manager

approved by Central
Project Office and obtain
Project Code

3. Identify key stakeholders Project Manager Project Kick Off Meeting Detailed stakeholder list
and conduct Project Kick Minutes will be identified at later
Off Meeting phases of the project.

4. Create the Project in Project Manager Use the Project

Tools Home Page
Template for
Confluence Confluence page
JIRA JIRA Project require
Quality Center the Project Code to
be added

Initiation
Sl Description of Tasks Responsibility Format1 Remarks

1. Create Project Plan Project Manager Project Pland Document Project Manager
Document Lite may fill in only the
applicable sections
and mark other
sections as Not
Applicable
New sections may
be added if
required.
Use confluence
page whenever
possible, copy the
structure from the
template

2. Define Roles and Project Manager Project Plan Document See the Roles and
Responsibilities Lite Responsibilities above
3. Define Project Lifecycle Project Manager Project Plan Document Mention new
Lite templates, if any,
that would be used
during the project
execution
Use the sections
Project Lifecycle
and Project
Tailoring to
document the
process to be
followed.

4. Identify potential risks Project Manager JIRA Risk Log

5. Define High Level Product Owner Business Any of these

Requirements Requirements templates may be
Document used for
User Stories, Back documenting high
Log in JIRA level requirements

6. Define the following Product Owner Project Plan Document

High Level Planning

Duration of each
Sprint
No. of Timeboxes

7. Create Product Backlog Product Owner JIRA

Initial Estimation
Initial Prioritization
of requirements

Sprints
Sl Description of Tasks Responsibility Format1 Remarks

1. Sprint Planning Development Team Sprint Goal Typical duration 5% of

Sprint Backlog Sprint length

Inputs for Planning:

1. Increment + Ready
Product Backlog
2. Definition of Done
3. Development Team
Velocity + Capacity
4. Retrospective
Commitment

Estimate using planning

poker.

You can use

your smart
phone for
planning
poker:

Android:
Scrum
Time -
Planning
Poker
iOS: iScru
m
 Use Fibonacci sequence
: 1, 2, 3, 5, 8, 13, 21, 34,
55, 89. Number 89
indicates that the story
are too big or too
complex too estimate.
Based on the estimation,
pick backlog items which
will be can be done in
sprint. Consult with
Product Owner if you
want to change the order
of backlog item.

Seek help
from Scrum
Master if you
are not sure
how to do this.

Each sprint can be

summarized by a sprint
goal that describes the
business purpose and
value of the sprint.
Typically the sprint goal
has a clear, single focus,
such as

Support customer
registration.
Demonstrate the
ability to identify
fraudulent
transaction.

There are times when a

sprint goal might be
multifaceted, for
example, “Get basic
printing working and
support search by date.”
During sprint planning,
the development team
should help refine and
agree to the sprint goal
and use it to determine
the product backlog
items that it can
complete by the end of
the sprint. These product
backlog items serve to
further elaborate the
sprint goal.

2. Sprint Execution Development Team An important Scrum rule

states that once the
sprint goal has been
established and sprint
execution has begun, no
change is permitted that
can materially affect the
sprint goal.

Change versus
Clarification

Although the sprint goal

should not be materially
changed, it is
permissible to clarify the
goal:
 What constitutes a
change? A change
is any alteration in
work or resources
that has the
potential to generat
e economically
meaningful waste, h
armfully disrupt the
flow of work, or sub
stantially increase
the scope of work
within a sprint.
Adding or removing
a product backlog
item from a sprint or
significantly altering
the scope of a
product backlog
item that is already
in the sprint typically
constitutes change.
What constitutes a
clarification?
Clarifications are
additional details
provided during the
sprint that assist the
team in achieving
its sprint goal. All of
the details
associated with
product backlog
items might not be
fully known or
specified at the start
of the sprint.
Therefore, it is
completely
reasonable for the
team to ask
clarifying questions
during a sprint and
for the product
owner to answer
those questions.

Being Pragmatic
The
no-goal-alterin g-change rule is just that—
What if business conditions change in
? Say a competito r launches its new p
After reviewing the new product, we c
Should we blindly follow the rule of no
Probably not.
What if a critical productio n system ha
Should we not interrupt the current sp
Probably not.
We must act in an economically sensi
. However, if the economic consequen
 This
applicable
also when we
need to
abnormally
terminate the
sprint. Sprint
termination is
used when an
economically
significant
event has
occurred, such
as a
competitor’s
actions that
completely
invalidate the
sprint or
product
funding being
materially
changed.

3 Perform Daily Scrum Development Team Time-boxed 15 minutes.

Each team member
answers following 3
questions:

1. What did you do

yesterday?
2. What will you do
today?
3. Are there any
impediments in your
way?

Any impediments that

are raised in the scrum
meeting become the
Scrum Master's
responsibility to resolve
as quickly as possible.

4. Conduct Sprint Review Development Team The product (software) During this meeting, the
Meeting team shows what they
accomplished during the
sprint. Typically this
takes the form of a demo
of the new features.

Some rules:

Kept informal
Demo the real
product, no
PowerPoint slides
No more 2 hours of
preparation for the
meeting

A sprint review meeting

should not become a
distraction or significant
detour for the team;
rather, it should be a
natural result of the
sprint.
 5. Perform Sprint Product Owner Document this on This is to ensure
Retrospective Confluence Page improvement on next
Development Team Sprint.
Scrum Master Usually this will take 3
hours for 4 weeks Sprint,
less for shorter Sprint.

Each team member is

asked to identify what
went well and not, and
also identify specific
things that the team
should:

What did we do
well?
What should we
have done better?

Use the page template

for Retrospective.

6. Update Product Backlog Product Owner JIRA Re-prioritization of

requirements, if required

Definition of Ready (DoR)

This is to ensure that items at the top of the backlog are ready to be moved into a sprint so that the development team can confidently
commit and complete them by the end of a sprint. The DoR can be tailored and agreed by the Team. There is no minimum standard,
following list can be used as reference:

Business value is clearly articulated.

Details are sufficiently understood by the development team so it can make an informed decision as to whether it can complete the
PBI.
Dependencies are identified and no external dependencies would block the PBI from being completed.
Team is staffed appropriately to complete the PBI.
The PBI is estimated and small enough to comfortably be completed in one sprint.
Acceptance criteria are clear and testable.
Performance criteria, if any, are defined and testable.
Development team understands how to demonstrate the PBI at the sprint review.

Definition of Done (DoD)

The done definition can be tailored on team/project level, however this is the minimum standard:

Unit tests performed & passed.

Source code committed on server.
Code review completed & issues are closed.
SIT Performed.
User Acceptance Tested/Validated by Product Owner.
Follow all ADM Standards.

For "Release" Sprint, the DoD must include following:

Deployment Package (Script, Object) created.

Deployment Plan/RFC created.

Please be aware on these & misconceptions, which are not valid Scrum events:
Sprint 0: The term Sprint 0 is often applied to project setup and initiation, during which the release of any value is deferred. As such it is not a sprint at all.
Hardening Sprint: If a team's definition of done is inadequate, or is not being met, technical debt can be expected to accumulate. A so-called Hardening Spr
Release Sprint: Each sprint must result in a potentially releasable increment, regardless of the number of teams and deliverables involved in a release, so b
Release Retrospective: A similar antipattern, since each sprint must yield an increment that is potentially releasable. The outcome of any release should be
However, if multiple teams are involved in making a release, they *may* choose to hold a Joint Retrospective in addition to their individual Sprint Retrospec
Closure
Sl Description of Tasks Responsibility Format1 Remarks

1. Get feedback back from Project Manager Customer Satisfaction

key stakeholders on Survey Template
their level of satisfaction
on project delivery

2. Prepare a report on the
lessons learned
Project Manager Project Closure Report This will cover
Template lessons from every
area of the project
like Project
Management, Risk
Management,
Defect
Management,
Coding, Design,
Requirements, etc.

3. Prepare Project Closure Project Manager Project Closure Report

Report, covering the Template
following

Evaluation of how
successful the
project was in terms
of scope, time, cost
and quality
Take an account of
outstanding risks
and issues

1- All templates are available at Agile Templates below.

Agile Templates
ADM Document Templates
Project Proposal
Project Plan Document
Project Kick Off Meeting Minutes Template
Business Requirements Document template
Customer Satisfaction Report Template
Project Closure Report Template
Templates for SIT and UAT artefacts
Change Advisory Board Templates
Other References
Essential Scrum: A Practical Guide to the Most Popular Agile Process