Last week I introduced the notion of a team to-do list, and how important this artifact is during the development of a feature.  That list should be curated once the work is done.  How that curation is accomplished the the subject of this episode.

One of the most powerful tools available to the team when conducting Acceptance Test-Driven Development, or any kind of requirements analysis, is also one of the simplest ones.  This episode is all about that tool.

In agile processes, we need discrete definitions of every important aspect of our work, so that we can work efficiently and effectively together, and to know when organizational goals have been achieved.  Part of this is knowing when the work is "done", and that's what this episode is all about.

Part 3 of my analogy on product quality.

Part 2 of my analogy on product quality.

Part of the Agile approach, as well as the tenets of Lean, say to "build quality in."  This seems wise, but what specifically is meant by "quality"?  Also, how can we know if we have imbued our product with enough of the required qualities to make it releasable?  The next three episodes will examine the notion of quality using a hopefully familiar analogy.

TDD can help you to improve your product design for many reasons.  One of them is that it is difficult, if not impossible to write a good test for a bad design.  But what is a good test?  How would we know if it's good in the right sense?  That's what this episode will explain.

This episode relates a story that an ex-student and current colleague of mine related to me over lunch.  I felt it was an extremely revealing and useful example of how requirements are misunderstood, the disasters than can result, and what to do about this.

Scenarios, like requirements, can often be too large to work with effectively.  In this episode we'll examine why this is a problem, and some example of how we can deal with it.

The world has changed, and so has the technology we use to automate it.  But a lot of the traditions that guide our efforts to control automation projects are based on the realities that existed in the past.  Agile is a response to this, and this episode is all about why, and how this is so.