Thursday, May 25, 2017

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

No comments:

Post a Comment