Agile E0

Objectives of the Session

Traditional Approach
What is Agile and its Principle?
Overview of Agile related Terms and Process
How we are using Agile in our teams

Traditional Waterfall Approach

Sequential Design Process ( Conception, Initiation, Analysis, Design,
Construction, Testing, Implementation and Maintenance)
Relies on a heavy up-front analysis and documentation of the need and
problem, along with the proposed solution.
Process is sequential, once step has been completed, developers cant go
back to a previous steps not without scratching the whole project and start
from beginning.
No room for change or error so a project outcome and a extensive plan
must be set in the beginning.
Critical factors for waterfall methodology stresses meticulous record
keeping.

Need for Agile

Rapidly changing market and technology-the need to be cutting

edge.

Requirement Change
Needs Change
Priorities Change
Technology Changes
Fashion Changes

Shrinking the time to market of products and increased

innovation demands for customer.
Reduction of testing and experimentation costs ( Simulation and

automation).

Customer value is delivered at point of sale, not at the point of

plan.

Need for an adaptive method of development rather than

traditional, predictive methods.

The Agile Manifesto

Individuals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile Principles
Our highest priority is to satisfy the customers through early and
continuous delivery of valuable software.
Welcome Changing requirements, even late in development. Agile Process
harness change for the customers competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference for the shorter timescale.
Business people and developers must work together daily throughout the
project
Build projects around motivated individuals. Give them the environment
and support they need and trust them to get the job done.
The most efficient and effective method of conveying information to and
within a development team is face to face communication.

Agile Principles (contd..)

Working software is the primary measure of progress.
Agile Processes, promote sustainable development. The sponsors
,developers and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances
agility.
Simplicity- the art of maximizing the amount of work not done is essential.
The best architectures, requirements and designs emerge from self
organizing teams.
At regular intervals, the team reflect on how to become more effective and
then adjusts its behavior accordingly.

Agile Planning and

Monitoring

Business Justification
Demonstrates the reasons for undertaking a project
Value based Prioritization
Factors used to determine the Business justification
Business Needs
Compliance or Regulatory Requirements
Opportunity
Project Costs
Major Risks

Estimation of Project Value

PV Present value is based on the time of value money economic
theory that a dollar today is worth more than dollar today. PV is a
way to take time out of the equation and evaluate how much project
is worth right now
IRR is a finance term used to express a projects return as an
interest rate.
RoI- Assesses the expected net income to be gained from the
project.
ROI= (Project Revenue-Project Cost)/Project Cost

10

Planning Levels in Agile

What, Who, Why, When, Constraints and Assumptions

Product Vision
Releases, Date, Theme/Feature set, objectives, Development
Approach

Product Roadmap
Release Plan
Iteration Plan

Iteration Team Capacity, Stories Priority ,Size, Estimates,

Definition of Done
Stories-task, Definition of done, level of effort, commitment
What did I Yesterday ?

Daily Plan

What will I do today ?

What is blocking me ?

11

Product Backlog
All Possible system features are
captured in a prioritized list- the Product
Backlog

High
Priority

New features can be added at any time

to the Product Backlog by anyone.

Each new feature

is prioritized and
added to the
stack

Features have only gross estimate of

efforts and value

Feature may be
re-prioritized at
any time

Focus on business value derived from

the releases (Value based prioritization)
Product Owner prioritized the product
backlog
One Product Backlog for all the team
Include non-functional requirements

Each Sprint
implements high
priority values

Feature may be
removed at any
time

Low
Priority
12

Product Backlog (contd..)

The Product Backlog should be DEEP, which is an acronym stand
for
Details Appropriately The user stories should contain neither too much
nor too little detail. They should have enough for the team to began
working to deliver value, but it is expected that the customer will need to
involved to clarify some aspects
Estimable The user stories near the top of the backlog should have
enough detail to be estimated for every story point or ideal days by the
team
Emergent The backlog grows and changes over time as user stories
are completed. It is not static

Prioritized The user stories that will deliver the most value should be
at the top of the backlog

13

Identify Project Stakeholders

Individuals and Organizations that are actively involved in the
project or whose interests may be positively/negatively affected as a
result of project execution or completion.
Stakeholders can be outside or inside of the project
Sponsor a project, or
have an interest or gain on successful completion of a project
may have positive or negative influence on project completion

Normally the project may have the following main stake-holders

Project Sponsors
Project Customers
Performing Organization
Agile Team

14

Agile Analysis and Design

15

User Stories/Story Cards

A User Story Describes Functionality that will be valuable to either
a user or purchaser. A user stories are composed of 3 aspects
A written Description of the story used for planning and as a reminder
conversion about the story used for planning and as a reminder
tests that convey and document details and that can be used to
determine when a story is complete.

As a <who/user> I want <what/goal> so that <why/reason>

A user can post her resume to the website
A user can search for jobs
A company can post new job openings

Project Initial stories are often written in story writing workshop,

but stories can be written at any time throughout the project
A short description of functionality can be written into Note or
Story Card or any electronic system tools.
16

User Stories/Story Cards (contd..)

The customer team writes the stories cards because they are in
best possible to express the desired features.
A story card is the visible part of a story but the important parts are
the conversion between the customer and developer about the story.
Stories are prioritized based on their business value to the
organization. While prioritizing following points need to consider
The desirability of the feature to be broad base of users or customers
The desirability of the feature to a small number of important users or
customers
The cohesiveness of the story in relation to other stories.

Technical dependency evaluated while prioritizing user stories

Each Story is assigned an estimate in story points, which indicates
the size and complexity of the story relatives to other stories
Each user story should be tag with the acceptance test criteria
17

Value Prioritization
Customer value based prioritization places primarily importance on
the customers and strives to implement with the highest value first
Below are the Prioritization schemes in order to determine the
high-value features
MoSCoW Prioritization derives its name from the first letters of the
phrases Must have, Should have, Could Have and Wont have
100 Point Method It involves giving the customer 100 points they can
use to vote for the features that they feel most important
Kano Analysis- Developed by Noriaki Kano and involves features or
requirement into four categories based on customer preferences
Exciters/Delighters Features that are new and high value to
customer
Satisfiers Features that offers value to the customers
Dissatisfiers Features if not present, are likely to cause a
customer to dislike the product, but do not affect the level of
satisfaction
Indifferent Features that will not affect the customer in any way
18
and should be eliminated

Attributes of Good User Story

To create good user stories, customer should focus on the below

attributes (INVEST)
1. (I)ndependent Each user story should be independent of
one another.
2. (N)egotiable A user story should leave opportunities for
conversation or negotiation with the customer.
3. (V)aluable Every user story must be set of value to the
customer.
4. (E)stimable The story should be such that it is easy for the
developers to estimate
5. (S)mall- A well written story should be small in efforts
6. (T)estable In order to confirm that story is done, it needs to
be testable. Anything that cant be tested should not be
19
developed

Acceptance Criteria
Acceptance test provides basic criteria that can be used to
determine if a story is completed.
Acceptance criteria answer the question, How will I know when
Im done with the story
Write Test before coding
The customer specifies the tests
Developer Responsibilities
Responsible for automating the execution of acceptance tests.
Responsible of thinking about additional acceptance tests when you
start development of a new story
Responsible for unit testing of code ( Definition of done), so that
acceptance tests do not need to be specified for all the minutiae of a story
Customer Responsibilities

Responsible for writing of Acceptance tests

Responsible for executing the Acceptance tests

20

Themes/Epics and Features

A theme is a group of user stories that share a common attribute
and for convenience they are grouped together
An Epic ( sometimes called Capability) is large user story that
cannot be completed into single sprint. Epics can be split into two or
more user stories of smaller size.
A User can search for a job
A feature is something that add values to the customer. Features
are generally small in efforts to implement. They are expressed as
Verb Noun
A User can view information about each job that is matched
by a search
A user can view the Job description
A user can view the Job salary range
A user can view the location of a Job

MMF is the smallest grouping of functionality that can add value to

the user and it is important is Agile.

21

Agile Estimation

22

Story Points Estimation

Unit of measure of for expressing the overall size of the user story,
feature or other piece of work.
Story points are assigned to each user story
Story Points are relative, not absolute
Estimate as a Team
Story points are used to calculate the team velocity.

23

Velocity
Definition

Points delivered by a team per sprint

How to calculate?

Summation of the Story Points delivered in one iteration

Keep in mind

How to use?

Used to determine sprint scope

Used to calculate approximate costs of a release
Used to track release progress

Velocity without a quality metric is not useful

Velocity of two teams are not comparable
Velocity changes with team composition
Velocity increases with teams tenure
Velocity is not productivity
Do not include bugs and rejected stories

24

How do you track progress?

25

Task Board
Task board is used to plan and track progress during each Iteration.
Contains four columns to indicate the progress of the estimated
tasks for the sprint
To Do column for the tasks not yet started
In Progress column for the tasks started but not yet completed
Testing column for tasks completed but in the process of being
tested
Done Column for the tasks that have been completed and
successfully tested

Task Board preferably maintained manually on the paper or

whiteboard, but also can be maintained electronically
Task board is also known as KANBAN ( Originated from Lean),
Kanban is Japanese word means signal
Team members will be responsible for updating this board
themselves.
26

Task Board ( Contd..)

Stories

To Do

In Progress

Testing

Done

1
2
3
4
27

Release Burn down Chart

The Release burn down chart shows the amount of work

remaining at the start of each iteration

Vertical axis shows the # of story points remaining in the

project
Horizontal axis shows the # of iterations for all the story
points
A powerful visual indicator of how quickly a team is moving
towards its goal

28

Release Burn down Chart ( Contd)

300

250

Points

200

150

100

50

0
1

Iterations

8
29

Agile Methodologies

30

Agile Methods
Agile Methods to be considered as

Lightweight
People based rather than plan based

No Single Definition
Agile Manifesto closet to definition

Several Agile Methods

No single Method
Scrum more popular

31

Scrum in 100 words

Scrum is an agile process, a light weight framework for delivering
the highest business value in the shortest time.
It allows us to rapidly and repeatedly inspect actual working
software ( every two weeks to one month)
The business sets the priorities. Our team self manage to
determine the best way to deliver the highest value priority features
Every two weeks to a month anyone can see real working software
and decide to release it as is or continue to enhance for another
iteration

Scrum is most useful in

Developing cutting edge technology products
Frequently and untimely changing requirements
Developing products in hyper competitive environments
A regular need for feedback due to complex requirements
32

Scrum Framework
Scrum Roles :- Product Owner, Scrum
Master, Team
Ceremonies :- Sprint Planning, Sprint
Review, Sprint Retrospective and Daily
Scrum
Artifacts :- Product Backlog, Sprint
Backlog and Burn down charts

33

How Scrum Works

34

Sprint
Definition

A Time boxed iteration from one week and more 30 days

Scope

All Activities in scrum happens within the confines of

sprint
Incomplete product backlog or sprint backlog item(s)
are not allowed
Sprints occur one after another, with no pause or
breaks between sprints

Fixed

Free from
distractions

A time box may not be extended or contracted after

a sprint has been begun
The Sprint Goal may not be altered by the product
owner or the stakeholders, after the team has made
their commitment to complete the sprint goal
Once underway, the team is given freedom and
autonomy to self manage their efforts as they work
to complete their sprint goal
Team may choose to pull help, advice information
and support from the surrounding organization
35

Definition of Done
Definition

A checklist of activies,standards,guidelines or conventions

that each product backlog item must complete

Scope

Definition of done is applied to all Product Backlog

items.
No Product backlog items may be considered
complete until it satisfies all the criteria in DOD
Product Backlog items which do not meet the
definition of done may not be demonstrated in Sprint
review

Creation

The Definition of done is the result of a negotiation

between the team, the Product owner and stakeholders
Regardless of the wishes, desires and hopes of the
Product Owner, Scrum Master and the Stakeholders
,the team has the final word on what should be
included in their definition of done.

36

Definition of Done (Contd..)

Maintenance

No one may change the definition of done once the

team has begun has sprint
The Scrum Master, Product Owner, any team member or
any stakeholder may suggest additions or deletions to the
definition of done

Enforcement

Responsibility to enforce the Definition of Done lies

with the Team alone
If the Scrum master feels a Product Backlog item does
not meet the Definition of Done, they are obligated to
inform both the team and the product owner

37

The Product Backlog

A Prioritized list of functional and non-functional requirements
necessary to develop and launch a successful product.
The Product backlog is owned and prioritized by the product owner
Each product backlog item can be a single feature, function,
technology, enhancement, bug fix or deliverable expected for the
product
Every Product backlog item should have a clear acceptance criteria
and is estimated by team
Any Individual of the team may suggest features to add to the
product backlog but the product owner has the final say on it
Product backlog items are ordered by business value, from highest
value at the top to lowest at the bottom
Every product backlog item must be ranked
No Items may have the same ranking as another
38

Sprint Planning
A time boxed meeting at the beginning of each sprint for the team
and the product owner to negotiate on what the team will deliver and
demonstrate at the review
The sprint planning meeting shall not exceed eight hours
1st of half sprint planning, the focus of the conversations between the
product owner and the team discuss WHAT product backlog items team
will build
2nd half of sprint planning, the conversation shifts to the team as they
talk through HOW they are going to build the product by decomposing
the product backlog items into sprint backlog items

Sprint Planning it facilitated by the ScrumMaster

The Team member, Product owner and ScrumMaster are required to
attend the sprint planning.
Product owner is expected to provide the unifying theme which
summarize the business value the team is expected to provide at the
end of the sprint
39

Sprint Planning (Contd..)

Each Team member selects the sprint backlog items(s) that
interests them and write their initials on the item to indicate they are
responsible for completing the work
It is the responsibility of the Team to ensure the work is fairly and
evenly distributed across the team

40

The Sprint Backlog

A list of all the tasks identified by the team representing their
current understanding of how they plan to achieve the sprint goal
The sprint backlog is owned and maintained by the team alone
A single task, activity or deliverable, defined and estimated by a
team member
Sprint Backlog is an artifact for the team to inspect and adapt their
work. It is offered in the spirit of openness, not as in invitation of
micromanagement
All Team members are expected to contribute and estimate the
tasks that makes up the sprint backlog
Team members may work as individual, subgroups or as one large
group to identify and estimate the task
Task should range from four to sixteen hours
Any Team member may add or remove items to the sprint backlog
Any Team member may update an estimate for a task in the sprint
backlog

41

Daily Scrum

Parameters
Daily
15-Minutes
Stand up
Not for Problem Solving

Three Questions
What did you do yesterday?

What will you do today ?

What obstacles in your way

Chicken and Pigs are invited

Only Pig can talk

42

Sprint Review
Time boxed meeting at the end of sprint on the product and their
progress till date.
A Hands on Demonstration of the working product by the Product
Owner and the team
The Sprint Review is facilitated by the Scrum master
Only working product may be demonstrated at a Sprint Review
The working product must be demonstrated in an environment
which mirrors the customers environment
Only Product backlog items that meet the acceptance criteria and
the definition of done may be encountered
Outcomes
No Change , move to next sprint
Reprioritize the Product Backlog
Release the functionality to customers
Delete Product backlog items based on changing business requirements

43

Sprint Review (Contd..)

Outcomes (contd..)
Add new Product Backlog items based on the feedback
Reformulate the team by adding or removing the members including
Product Owner and Scrum Master
Add more team member to increase the pace
Stop further investment in the product by disbanding the team

44

Sprint Retrospective
A time boxed meeting at the end of each sprint for the team to
reflect their progress
The Retrospective is for the team
Each member provide feedback to one other and inspect and adapt
This meeting is a conversation between team member and Scrum
Master facilitated the Retrospective
Product Owner, Scrum Master and Team is required to attend this
meeting
The Team is responsible for capturing and implementing any action
items(s) which may arise
The Team owns the information generated at the retrospective, only
the team has authority to share this information with others.

45

Time-Box Duration for Scrum

Meetings
Sprint
(1 to 30 days)
Retrospect Sprint
Daily Standup

Meeting ( 4 hours

Meetings

One-month sprint)

(15 Minutes)

Time-Box
Meetings
Durations
Sprint Planning
Meetings

Sprint Review

(8 hours one month

Meeting (4 hours for

sprint)

One month sprint)

46

Scalability of Scrums
Normally a Scrum team consist of 6 10 people
Multiple scrum team can be formed to work on the project
The Convene of scrum of scrums process facilitates coordination
among scrum teams , enabling effective implementation in larger
projects
Scrum of scrums meeting, conducting among various scurm teams
Representative from each scrum team attend the meeting
Frequency and duration of the meeting is not fixed or detemined
4 questions per team
What has my team been working on since the last meeting?
What will my team do until the next meeting?
What were other team counting on our team to finish that remains?
What is our team planning on doing that might affect other teams ?
47

Thank You

48