Chap 02:
Why
Planning Fails
·
Planning
Is By Activity Rather Than Feature
·
Features
Are Not Developed By Priority
·
Estimates
Become Commitments
·
Multitasking
Causes Further Delays
·
We
ignore uncertainty
Chap 03:
An
Agile Approach To Projects
·
Work
as one team
·
Work
in short iterations
·
Deliver
something each iteration
·
Focus
on business priorities
·
Inspect
and adapt
An
Agile Approach to Planning - Multiple Levels Of Planning – Onion Planning
Chap 05:
Estimating
In Ideal Days:
·
Ideal
time and elapsed time are different.
·
The
ideal time of a game of American is 60 mins. However, elapsed time (with all
interruptions) could be 3-4 hrs.
·
Estimating
in Ideal Days is easy than estimating in Elapsed days.
·
Estimating
in elapsed days requires to consider all of the interruptions that might occur
while working on the story.
·
In
this way, ideal days are an estimate of size, although less strictly so than
story points.
·
When
estimating in ideal days it is best to associate a single estimate with each
user story. Rather than estimating that a user story will take four programmer
days, two tester days, and three product owner days, it is better to sum those
and say the story as a whole will take nine ideal days.
Chap 06:
The
Estimation Scale
Two
estimation scales I’ve had good success with are:
·
1,
2, 3, 5, and 8
·
1,
2, 4, and 8
There’s
a logic behind each of these sequences.
·
The
first is the Fibonacci sequence. I’ve found this to be a very useful estimation
sequence because the gaps in the sequence become appropriately larger as the
numbers increase. A one point gap from 1 to 2 and from 2 to 3 seems appropriate
just as the gaps from 3 to 5 and from 5 to 8 do.
·
The
second sequence is spaced such that each number is twice the number that
precedes it.
These
non-linear sequences work well because they reflect the greater
uncertainty associated with estimates for larger units of work.
Deriving
an Estimate
The
three most common techniques for estimating are:
·
Expert
opinion
·
Analogy
o
When
estimating this way you do not compare all stories against a single baseline or
universal reference.
o
Instead,
you want to estimate each new story against an assortment of those that have
already been estimated. This is referred to as Triangulation.
·
Disaggregation
Chap 08:
Choosing
Between Story Points and Ideal Days
1.
Why
Story Points:
·
Story
points help drive cross-functional behavior
·
Story
point estimates do not decay or has longer shelf life
·
Story points are a
pure measure of size, Ideal Days are Not
·
Estimating
in story points is typically faster
·
My ideal days are
not your ideal days
2.
Why
Ideal Days:
·
Ideal
days are easier to explain outside the team
·
Ideal
days are easier to estimate at first
·
Ideal
days make velocity predictions easier
Chap 12:
Splitting
User Stories
·
Splitting
Across Data Boundaries
o
Splitting
US – Support Local & International phone numbers.
o
Splitting
US - Payoff my loan & Refund if paid more
·
Splitting
On Operational Boundaries (CRUD)
·
Removing
Cross-Cutting Concerns
o
Splitting
US – One with and Other without support for the cross-cutting concern
(security, logging, error handling, and so on)
·
Don’t
Meet Performance Constraints
o
Splitting
US – Functional & Non-Functional Requirements
·
Split
Stories of Different Priority
o
If
the user enters a valid user name and password, she is granted access.
o
If
the user enters an invalid password three times in a row, she is denied access.
o
If
the user is denied access, she is sent an email stating that an attempt was
made to use her account.
·
Don’t
Split A Story Into Tasks
Chap 13:
Release
Planning: Release planning
(3-6 months) is the process of creating a very high-level plan that covers a
period longer than an iteration.
Why
Release Planning:
·
Helps
the product owner and the whole team decide how much must be developed and how
long that will take before they have a releasable product
·
Release
conveys expectations about what is likely to be developed and in what
time-frame for strategic planning activities.
·
Release
plan serves as a guidepost toward which the project team can progress. Without
the concept of a release, teams move endlessly from one iteration to the next.
How
to Create Release Plan:
·
Determining
The Conditions Of Satisfaction / Success Criteria
·
Estimate
The User Stories – May be a Feature Level
·
Select
an Iteration Length – Two or Four Weeks
·
Estimate
Velocity
·
Prioritize
User Stories
·
Define
Release Plan (Based on Velocity, Launch Date & US Priorities)
·
Feature
Driven -
If the project is feature-driven, we can sum the estimates of all needed
features and divide
by the expected velocity. This will give us the number of iterations necessary
to complete the desired functionality.
·
Date
Driven -
If the project is date-driven, we can determine the number of iterations by
looking at a calendar. Multiplying
the number of iterations by the expected velocity will tell us how many story
points or ideal days will fit in the release.
Chap 14:
Iteration
Planning
·
Velocity-Driven Iteration Planning
·
Commitment-Driven Iteration Planning
(Preferable)
Chap 15:
Selecting
an Iteration Length
Factors
in Selecting an Iteration Length:
·
How
long priorities can remain unchanged
·
Willingness
to go without feedback
·
The
overhead of iterating
·
The
length of the release being worked on
·
A
feeling of urgency is maintained
·
The
amount of uncertainty
·
The
ease of getting feedback
Chap 16:
Estimating
Velocity
You
have the following three options:
1.
Use
Historical Values - Before using them, ask yourself questions like these:
o
Is
the technology the same?
o
Is
the domain the same?
o
Is
the team the same?
o
Is
the product owner the same?
o
Are
the tools the same?
o
Is
the working environment the same?
o
Were
the estimates made by the same people?
2.
Run
an iteration
3.
Make
a forecast
Chap 18:
Planning
the Multi-Team Project
Planning
a large, multiple team project may require:
·
Establishing
a common basis for estimates
·
Adding
detail to their user stories sooner
·
Lookahead
planning
·
Incorporating
feeding buffers into the plan
Regards,
Arun Manglick
