________________________________________________________________________________

_______________________________________________________________
AGILE-ESTIMATION:
Estimation Challenges:
Requirements hard to estimate
Difficult to predict what exactly will be delivered, when
Estimating takes too long and we still don t get it right
Estimates are provided by the wrong people (not the one doing actual wor
k)
Software projects are unique and ambiguous; hard to provide exact estima
tes
Business customers promise unrealistic deadline then tell the team to ma
ke it work
Based on high-level estimates
Fixed scope, time, and budget
Why Do We Estimate:
Estimating helps in planning
Estimating helps in calculating Return on Investment (ROI) and Internal
Rate of Return (IRR), sizing and approving projects
Estimating helps the development team knows its velocity and be able to
commit to work accordingly to it
Estimating helps the product owner in decision making, prioritizing and
in overall release planning
Estimating helps tracking the progress on a release
What do we estimate?
Stories (single unit of business functionality)
Who estimates?
Development team
How do we estimate:
Relative sizing/Story points
Ideal Time
Wideband Delphi
Planning Poker
Affinity Estimating
Accuracy is more important than precision-->It is better to be roughly right tha
n precisely wrong
Cone of uncertainty: describes the amount of uncertainty during a project. At th
e beginning of a project, it s hard to estimate because little is known about the pr
oduct or the results. As you begin researching and developing the product, the u
ncertainty level will decrease and eventually reach zero percent, typically at t
he end of a project.
Estimates at beginning of project are very vague
Estimates and project plans need to be re-estimated on regular basis
Uncertainties should be built into the estimates
Uncertainties should be visible in project plans
Absolute vs. Relative Levels of Estimates
EPIC: T-Shirt Sizing: Focuses on magnitude
STORIES: Story Points: Focuses on size and complexity
TASKS: Ideal Time: Focuses on ideal times

* T-Shirt Sizing or story point relative method can be used for estimating Prod
uct Backlog Items
Estimation Scale

Fibonacci Sequence(1,1,2,3,5,8....)

The Wideband Delphi is a group-based estimation method for estimating the effort
s.
Moderator reads the story and reviews the functionality
Estimators are allowed to ask any questions and then they go away and es
timate their story in private
Moderator consolidates the estimates
Review and team discussion on variations
Repeat the process until consensus is reached(happens in rounds)
>Affinity Estimating:
Step 1: Silent Relative Sizing:
In this step, the team first defines simple guidelines which may help them in pe
rforming a relative sizing exercise. For ex:
Estimates include all work efforts including requirement analysis, codin
g, testing and completion as per definition of done.
Agree on relative sizing nomenclature, e.g. T-shirt size, or Fibonacci s
eries.
Some product backlog items may not be understood enough to estimate at a
ll. Place these on a space separate from the estimating wall so it will be discu
ssed and get clarified with product owner at later stage.
The team will the then silently post all backlog items relative to the size (sma
ll on left, medium in the middle and large items on the left as shown in the abo
ve board. Run the silent relative sizing until all product backlog items are up
on the wall
Step 2: Editing of Wall: In this step, team members read the product backlog ite
m, discusses and allows moving items around as needed in either direction.
During this part of the exercise the team discusses the efforts required to deve
lop the item including design, coding, testing, integration and other tasks. Tea
m can ask clarification from the product owner. This exercise will continue unti
l the team begins to settle down.
Step 3: Place Items into Relative Sizing Buckets: Once all of the product backlo
g items have been placed onto the wall and edited by the team. The next step is
to place each item in into a sizable bucket. Place the stories to indicate the c
omplexity, e.g. in the above diagram, five different sizes are used and items ar
e separated using x-small, small, medium, large, and x-large sizes.

Step 4: Product Owner Challenge : Product owner may request estimate clarification, an
if required, a re-size and re-order of the stories.
Step 5: Document the Estimates: In this last step, the team documents the discus
sed estimate and saves it for future use.
This exercise does not remove the need to conduct more in-depth estimating sessi
ons such as with planning poker as the product backlog evolves at latest stages.

>Various Levels of Top-Down Requirements:

Feature: Business solution, capability or enhancement that ultimately provides v
alue to the business and/or its customers
Source: Business/customer value, charter document, business case
Units: Points
User Story: Describes interaction of users with the system
Source: Feature
Units: Points
Story: Any requirement that isnota user story (e.g., technical enabling, analysis, r
eminder to have conversation)
Source: Development team, analysis work, large story decomposition
Units: Points
Task: Fundamental unit of work that must be completed to make progress on a stor
y
Source: Development team (during iteration planning)
Units: Hours
>Planning Poker:
Moderator Read Story
Product Owner Answer Questions
Each estimator provided Deck of Cards
Member estimates and simultaneously turned over and shown their number
Discuss the variations
Re-estimate until converge
________________________________________________________________________________
_______________________________________________________________
Risk Management:
Project risk is an uncertain event of condition that, if it occurs, has a positi
ve or negative effect on one or more project objectives such as scope, schedule,
cost and quality.
The objectives of risk management are to increase the likelihood and impact of p
ositive events, and decrease the likelihood and impact of negative events in the
project.
The task of risk management is to manage a project s exposure to risk by taking acti
on to keep exposure to an acceptable level in a cost-effective way.
Access to reliable, up-to-date information about risks
Decision making processes supported by a framework of risk analysis and
evaluation
Processes in place to monitor risks
The right balance of control in place to deal with those risks
Benefits of Risk Management
More and better information is available during planning and decision ma
king
Project objectives are verified
Improved communications
Higher probability of project success
Proactive approach
Project might be canceled
Traditional Risk Management Process

Identify Risks: The process of determining which risks may affect the pr
oject and documenting their characteristics
Perform Qualitative Risk Analysis: The process of prioritizing risk for
further analysis or action by assessing and combining their probability of occur
rence and impact.
Perform Quantitative Risk Analysis: The process of numerically analyzing
the effect of identified risks on overall project objectives
Plan risk response: the process of developing options and actions to enh
ance opportunities and to reduce threats to project objectives.
Control risks: The process of implementing risk response plans, tracking
identified risks, monitoring residual risks, identifying new risks, and evaluat
ing risk process effectiveness throughout the project.
Traditional Risk Management Artifacts
Risk Management Plan
Risk Register
Risk Matrix
Risk Response Planning
Strategies
Acceptance
Take it with Stride
No action needed
Only acknowledge it
Avoidance
Eliminate root cause
Change method, or approach
Change sequencing
Replace resources
Change timing
Implications: Cost, Time, Scope
Transfer
Outsource
To a Consultant
To a Contractor
Buy Insurance
Need to Budget for it
Mitigation
Prevent or reduce the Probability
Prevent or reduce the Impact
Need to Budget for it
Contingency Planning
Fallback Plan Plan
Reserves
Monitoring & Control
Monitoring

Agile Risk Management Principles

Transparency: Make visible and accessible all risk artifacts used to und
erstand, communicate and manage risks within the project.
Balance: Establish clarity about the nature and distribution of risk and
reward throughout the project.
Flow: Ensure that risks do not inhibit the project and that the agile pr
ocess itself is capable of withstanding perturbations arising from risk.
Agile Risk Management Stages
Understand project objectives, context and risk environment.
Risk Scoping. Identify Risk Drivers and Appetite.
Risk Tailoring. Embed Risk Management in Agile Process.
Risk Management. Identify Analyze, Manage and Monitor.
How Agile Addresses Core Risks
Intrinsic Schedule Flaw (estimates that are wrong and undoable from day one, oft
en based on wishful thinking)
High level planning/estimation is done at the beginning of the project and a det
ailed estimation is done at the start of each iteration
Specification Breakdown (failure to achieve stakeholder consensus on what to bui
ld)
Assignment of a product owner who owns the backlog of work
Scope Creep (additional requirements that inflate the initially accepted set)
A change is expected and welcome, at the beginning of each iteration
Personnel Loss
Self-organizing teams experience greater job satisfaction
Productivity Variation (difference between assumed and actual performance)
Demos of working code every iteration
Risk Management in Scrum:
Risk Identification
Identification of risks is harder than one might imagine as the biggest problem
is conflating uncertainties and effects.
A simple but effective technique for risk identification is to brainstorm what m
ight occur (effects) and then in each case, ask why it might occur (risks). Once
identified risks should be recorded in a risk log
Risk Analysis (Uses Risk Modified Kanban Log)
The purpose of risk analysis is to determine a course of action and prioritize i
t accordingly. Risks should be assessed in terms of likelihood and impact for wh
ich T-shirt sizing (i.e., S, M, L) usually suffices.
Accept: Undertake no action to manage the risk, but instead have a contingency p
lan in place in the event that the risk is realized.
Exploit/Reduce: Enact measures to increase/decrease either the likelihood or the
impact of the risk.
Share/Transfer: Endeavour to share/transfer the risk to other parties in exchang

e for a share in the rewards or a fee for assuming the risks.

Avoid: Refrain from taking part in the task that gave rise to the risk.
Risk Analysis (Actions):
Do nothing (but plan): Accept that the risk might occur and think about
what would need to be done if it were realized.
Risk Tasking: Create a task that deals with the risk (e.g., exploit, red
uce, share or transfer it).
Risk Tagging: This refers to the selection of an agile technique specifi
cally chosen to cater for a risk (e.g., pair programming) and which is applied t
o a class of activities (e.g., all GUI related tasks).
Task Dropping: Remove the task from the Kanban that is giving rise to th
e risk.
Managing Risk via Product Backlog
Risk reduction items may be avoidance, mitigation, or acceptance.
Risk Monitoring
Risk monitoring provides a visual cue of what is being done to tackle risk whils
t at the same time acknowledging the systemic nature of risk within the project.
Risk monitoring requires the assigning of scores to risk exposure bands when ass
essing both inherent and residual risks.

________________________________________________________________________________
_______________________________________________________________
________________________________________________________________________________
_______________________________________________________________
________________________________________________________________________________
_______________________________________________________________
________________________________________________________________________________
_______________________________________________________________