He starts off with the image of a progress bar... ticking along at 10%, 20%, 50% done... but likely to get stuck at 95% with no way to guess when it's going to jump to 100%! Similarly, the traditional way projects are tracked gives us nice indicators... which don't really tell us when the work will be fully done. Too many projects fall into the scenario of being 80% done for months on end. Enter Scrum.
Hanselman goes over just-in-time task-level estimation, velocity, how burndown charts can help forecast delivery dates and feature reconciliation, and more importantly the concept of when a feature is said to be really done, ie. compiles, tested, integrated, checked-in and documented.
Chris Chapman notes, in his review of this podcast, that when we talk about a Product Backlog as indicating the size of a project, we are usually not talking about "real" days, but some relative measure allowing us to size the work to be done. Some use "story points", others "ideal days" (time it would take with all needed information and resources available and no interruptions). In fact, there are some teams that will apply a factor to ideal days to get real days... or a rough semblance thereof. It's not so bad if everyone understands that this is a SWAG estimate, having been done at such a high level. The key is to make sure this is understood, no matter what unit of measure is chosen . The potential for misunderstanding is a good reason to not estimate in real days.
Hanselman provides an anecdote that explains the name for his podcast site... a colleague points out that his estimate of 20 minutes is a lie... it's really in "Hanselminutes" (which means you'll have it in three hours). This illustrates the practice applied by many Agile teams of not pretending to estimate in "real" time... everyone's "minutes" are different, and with the Scrum method of task estimation, individual differences are accounted for. He notes that Scrum allows developers to work the way they like: on tasks they choose, which they have defined and estimated. Meanwhile, it also allows Product Owners to do what they like to do: track progress, daily if they want, in a transparent and meaningful way.His casting of the Scrum Master as a Project Concierge is a new one - nice analogy! The Scrum Master does whatever is needed to protect productivity - from buying software licenses to providing soft drinks.
He also talks about Sprint Retrospectives - how they encourage team feedback and engagement. For more on Retrospectives, see the new book by Diana Larsen and Esther Derby.
On the same page, Hanselman has provided an extensive list of Scrum links, compiled by Howard VanRooijen of Conchango, listing sites, podcasts, books, arcticles for further investigation of Scrum and related methodologies.