Mike Cohn - Agile Concepts

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