Agile Estimation and Planning

I just finished Mike Cohn's Agile Estimating and Planning, a thorough and very readable treatment of how Agile works as a project planning methodology. Here are my takeaways:

• Avoid false precision, by planning long range by story point (a rough estimation of relative size), by stating project time estimates as ranges, and by estimating story points in Fibonacci bucket: Is it a 1, 2, 3, 5, or 8? Use planning poker as a way to derive team consensus estimates.
• Confront risk early by scheduling risky features early on.  The biggest risk to a project is building the wrong product.  The way to inoculate against this risk is to get the product in the customers's hands as soon as possible. 
• Plan the release by story point, plan the iteration by task hours, and plan the day by deciding who will do what.  The process moves towards greater precision as the time horizon shortens.
• Keep tasks to a 1 or 2 day in duration to keep work flowing through the team.
• Each iteration should result in a clean start, to avoid slowing down the process with half-completed work.
• The team is accountable, and succeeds or fails as one.
• Neat trick #1: Derive a planning buffer by capturing two estimates for each task--how much time to be 50% confident of completion, and how much time to be 90% confident.  The difference between the 50% and 90% mark gives an estimate of risk. Taking the square root of the sum of the squares to get a planning buffer for the iteration.
• Neat trick #2: When surveying prospective users, ask how much they would like having a feature and how much they would dislike not having it.  If users will dislike not having it, it's a mandatory feature (e.g. Save functionality on a word processor).  If users like having it, but don't mind its absence, then it is an "exicter," not expected, but generating enthusiasm, like the ability to play movies on an iPod.