Release planning using feature points

[ release planning using Feature
Points ]
Madhur Kathuria, CST,CSC,CSP,CSM
CEO, AgiVetta Consulting
Chair, India Scrum Enthusiasts Community (ISEC)

[Accidental Agile Coach,
Status-quo Disruptor,
Transformation freak,
Behavioral mystic, nomad,
INDIAN]
13
years

4
The principles and values of Agility
Traditional vs Agile Release Planning
The Product Owner’s Dilemma
Estimation Units
̶ Story Points
̶ Feature Points
 Using Estimations
[ we will discuss]

[ so what is Agile ?? ]
All Agile processes are necessarily Iterative, but not all Iterative processes are Agile
A Process…
A Framework…
A Philosophy…

What Agile Is
• Structured and disciplined
approach to iterative development
• A set of practices that
accommodate changing
requirements
• A set of practices that will
significantly improve the quality of
your software
• An umbrella term for several
iterative and incremental software
development methodologies.
What Agile is NOT
• Fly by the seat of your pants
development
• Getting the same amount of work
done in less time
• A way for the business to change
direction on the fly
• A project management
methodology
• Process: Just for the heck of it

Enablers
Support & trust, Technical excellence, Simplicity
Results
Valuable SW &
satisfied
customer
Harness change
for competitive
advantage
Constant pace
Methods & tools
Face-to-face
Working
software as
primary
measure of
progress
Self-organizing
teams
Leading principles
Frequent
delivery
Close
communication
Reflective
improvement
[the Agile Principles]

Agile
Values
Trust
Accountability
High
Performance
High aims
Sense of
Urgency
Goal Driven
Approach
Self Growth
and
Excellence
[agile Values]

[traditional Release Planning]

PBI1
PBI2
PBI3
PBI4
PBI5
PBI6
…
SBI1
SBI2
SBI3
SBI4
…
Design
Develop
Test
Integrate
Deploy
1-2 weeks
Sprint
Release
Sprint Planning
Daily
Stand-up
Backlog
[the best way…]

SIT and UAT Sprint
1
SIT and UAT Sprint
2
Planning Sprint 1 Planning Sprint 2 Planning Sprint 3 Planning Sprint 4 Planning Sprint n
Sprint 1 Sprint 2 Sprint 3
Sprint 1 Sprint 2
Sprint 1 Sprint 2 Sprint 3
ReleaseHardening
Ordered Requirements Backlog
SIT Team + UAT team
Team
Backlog
Scrum Team
(Developers,
Testers, Dox,
Infra)
Team
Backlog
Team|
Backlog
Team
Backlog
MR 1 RC 1
DD Sprint 1 DD Sprint 2 DD Sprint 3 DD Sprint 4
Sprint 4
Planning Sprint 5
DD Sprint 5 DD Sprint n
Sprint 1 Sprint 2 Sprint 3 Sprint 4
SIT and UAT Sprint
3
Final SIT and
UAT
FRMR 2
4 weeks 4 weeks 4 weeks 4 weeks 4 weeksPO Council
Planning
Team
[a possible new way for large projects]
PO
PO
PO

14 © 2010 PegasystemsInc.
[traditional Estimation]
 Based on Metric Units (Hours, Days, Months etc .)
 Based on Gut feel of the person providing the estimate
 Dependent on skill and experience of the estimator
̶ E.g. a seasoned developer might estimate a work to be completed in 5
days whereas a new developer might estimate 15 days for the same
work
̶ Who is correct in estimation ?? What happens if in middle of work,
the new developer has to take on the remaining work for some
reasons??

15
[boehm’s Estimation Accuracy Graph]

16
Relative Estimation
 Does not use traditional metrics based approach (Unit
independent)
 A Measure of size and complexity of the problem at hand
 Even a new bee can estimate provided there is enough
knowledge about the problem available
But Isn’t complexity
experience
dependent???

[agile Estimates]
[The team estimates the size and complexity of
the PBIs]
[Typically, the team would estimate only few top PBIs ( and
not all)]
[Story Points and the Planning Poker game are a good way to
estimate the PBIs]
Estimate

[the Story Point dilemma for POs]
[The estimates come in too late]
[Are not common across the teams]
[Customers and Sales guys Do not understand Story
Points]
[Early Story Point estimation are prone to padding and
deviations]

Backlog Entities Release VehicleProduct/Architecture
Release
Goal
Product
Portfolio
Milestone
Release
Backlog
StoryScrum Team
Epic
Sprint
Theme
Feature

21
[ estimating Release Backlog ]
 The Product Owner works with the business departments and the
development organization to develop estimates (to analyze, design,
develop, document, and test the functionality, i.e. whole lifecycle), usually
in feature points.
 Work with people who will be staffing the project teams to make the
estimates. If they aren’t known yet, have people of equal skills and project
domain knowledge make the estimates. Do not have experts or outsiders
make the estimates. Their estimates are irrelevant to those who will
actually be doing the work.

22
[estimating Release Backlog]
 Estimating is iterative. Estimates change as more information emerges.
 If you can’t get a believable estimate for a top priority backlog item, lower
its priority (to delay working on that item until you know more about it).
Alternatively, keep them high priority but reclassify them as an issue. The
work to turn this issue into required functionality might take ten days; so
estimate the issue at ten days.
 Lower priority product backlog is vague, a placeholder for further
investigation/thinking as its priority increases. The estimates are not very
reliable.

[introducing Feature Points]
StoryPoint
FeaturePoint

24
[estimating the epics]
 Identify 2 epics from the last release and two estimates from the current
release which are simple and small
 Estimate them relatively based on complexity and size
 These become the reference epics for this release
 Relatively estimate all epics in current release based on reference epics
 Typically you can use higher Fibonacci series numbers at this level e.g. 20,
40, 60, 100, 160 and so on
Size of Release = Sum of all committed Epics for the release

25
[estimating Features]
 Break down Epics into Features.
 Estimate the features relatively (like previous step)
 In case the sum of Feature points for features does not match the Epic
points, update the Epic estimate with sum of feature estimates. Remember
this will change the release size too

26
[planning Poker Aka Adapted Delphi Wideband Approach]
1. Gather together the customer and the developers. Bring along the story
cards. Distribute a handful of blank cards to each participant.
2. The customer selects a story at random and reads it to the developers. The
developers ask as many questions as they need.
3. When there are no more questions, each developer writes an estimate on a
card, not yet showing the estimate to the others.
4. When everyone has finished, the estimators turn over their cards so
everyone can see them.
5. If estimates differ, the high and low estimators explain their estimates.
6. The group discusses it for up to a few minutes, the customer clarifies
issues. The developers estimate again write their estimates on cards. In
many cases, the estimates will already converge by the second round. But,
if they have not, repeat the process.
7. If the estimates differ slightly, reach group consensus on one value. Follow
the rule “Optimism wins” (team members whose optimism burned the
team once will learn to temper that optimism).

27
[yesterday’s weather]
 Say you’ll do as much today (in the next sprint) as you actually got done
yesterday (in the last sprint).
 Emergent properties of this rule:
̶ We won’t habitually overestimate our abilities. We have to use actual
accomplishment. If we overestimate once, we won’t be able to the next
time.
 If we are overcommitted, we will tend to try to finish some items in any
given time period instead of half finishing them all. It is so embarrassing
to tell the customer they can have zero features next time.
 On the other hand, if we have a disastrous period, we are guaranteed a
little breathing space to recover.
̶ Everyone learns to trust our numbers because they are so easy to
explain.
̶ Our estimates automatically track all kinds of changes – changes to
the team, new technology, dramatic changes in product direction, etc.
The first estimate (at the beginning of the project, when there is no yesterday)
is the hardest and least accurate. Fortunately you only have to do it once.
From: Kent Beck/Martin Fowler: Planning Extreme Programming

[adjusting Estimates (1/2)]
• To reflect any factors that reduce team
effectiveness. Scrum assumes an optimal
work environment. This activity forces an
understanding that suboptimal product
factors have a cost.
• The guidelines for adjusting estimates to
reflect complexity are just that: guidelines.
This is not a precise science.
• The estimated time for each item can be
adjusted by a “complexity factor.” reflecting
the degree of complexity due to
requirements and technology that will affect
the estimates.
• Keep adjustment for complexity separate
from the base estimate.
• Apply the complexity factor only to a known
horizon. If it is possible that the team
environment will change, don’t apply
complexity factors past that horizon.
• Diminish the impact of the complexity
factors as the team can be expected to
master the technical and business domain.

[adjusting Estimates (2/2)]
Drag on team productivity
– When teams haven’t worked
together before, when they are not
familiar with the technology, and
when they aren’t familiar with the
business domain.
• Adequacy of working environment
– When the team is not together in
an open environment with
adequate work and conference
rooms. Usually a factor of 0.2
• Multiple teams
– Due to management and
communications overhead caused
by multiple teams. Usually an
additional factor of 0.1
• Adjusted Estimate = Raw Effort * (1 +
complexity factor + drag + working
environment + multiple teams)

30
[sprint and Release Velocity]
 Based on the mechanism provided on earlier slides, identify
the no of FPs all the teams working on that particular backlog
were able to complete in their last sprints collectively
 This becomes the backlog Feature Velocity per sprint
 Based on the feature velocity now you can predict how many
epics/ feature can the teams complete in this release or how
many more sprints might be needed to complete all the
features the PO Wants

31
[who Does it ?]
 Epic Estimations
̶ By POs, Product Architects and Senior SMEs
 Feature Estimations
̶ Tech Leads, Senior Test Architects, Senior Engineers etc.
 Story Estimations
̶ Scrum Team

32
Feature
Stories
Epic
Project
Scope Progress – Bottom Up Approach
Project A
120
Epic A
40
Epic B
60
Epic C
20
Feature
A
40
Feature
B
40
Feature
C
20
Feature
Points
Given
by
Product
Teams/
TLs
Story Points
Given by
Scrum
Teams
Feature
D
20
Story
A
50
Story
B
50
Story
C
60
Story
E
25
Story
F
5
Story
D
45
Story B
is 100%
Done
Feature
A is 50%
Done
Epic A is
50%
Done
Project A
is 16.7%
Done

33
Features
Stories (WU)
Epics
Project
[scope progress – Add Epic]
Project A
120
Epic A
40
Epic B
60
Epic C
20
Epic A
40
Epic B
40
Epic C
20
Epic D
20
Story
A
50
Story
B
50
Story
C
60
Story
E
25
Story
F
5
Story
D
45
Epic A is
50%
Done
Project A
is 16.7%
Done
Epic D
20
Project A
140
Project A
is 14 %
Done
Story B
is 100%
Done
Epic A is
50%
Done

34
[principles of Agile Estimation (1/2)]
 Don’t estimate waste, don‘t look too far into the future.
̶ Estimate up to 2 sprints into the future (fine grain). Estimate up to 2
releases into the future (coarse grain).
 Estimate as a team (development + customer).
̶ This reduces the “blame game”, you can no longer point accusing
fingers at the person who made the plan.
 Estimate your own work.
̶ You feel committed as an individual for the development of the self-
selected tasks.
̶ You feel committed as a group for delivering the iteration goal.
 Base estimates on facts, rather than on speculation. Use actual data. Use
what happened in the past.
̶ Yesterday’s weather, team velocity, triangulation
 Estimate early.
̶ Start getting estimates as soon as you write stories.
̶ You will know what questions to ask if you can’t estimate a story.

35
[principles of agile estimation (2/2)]
 Estimate often. Learn from experience.
̶ At the beginning of an sprint/ release.
 Estimate small features.
̶ Stories of several days up to 2 weeks
 Keep it simple. Use simple rules.
 Communicate the constraints / assumptions of your estimates rather than
just the numbers.
 Estimate total effort for implementing a story (development, testing,
documentation etc.)
 Don’t bring initial estimates (from release planning) into sessions for
detailed estimates (iteration planning). Otherwise, the estimators will be
tempted to force fit the task estimates to sum to the story estimate.
 rack the effort spent and the effort still open until completion. Don’t ask
for a percentage. Only count a story as implemented if it has passed the
acceptance tests.

38
[if I can be of any help]
My space
̶ madhur@indiascrumcommunity.org
̶ www.madhurkathuria.info
̶ Twitter: madhurkathuria
̶ Skype: madhur.kathuria

Release planning using feature points

Release planning using feature points

More Related Content

What's hot

Viewers also liked

Similar to Release planning using feature points

More from Madhur Kathuria

Recently uploaded

In this document

Release planning using feature points