Much has been written about the commonality or even the lack of it between Agile and CMM. CMM claims to be a flexible model that can be tailored and adapted to many life cycles. The continued discussion is evident enough that it is not sufficient to compare practice to practice and arrive at any reasonable conclusion about their overall compatibility. The one difference that seems to have earned consensus amongst most of the published literature on the subject is "the people aspect" of these models. 

While working with Product Owners over the years I have learned some rules of thumb that help make their Product Backlogs more manageable. Some of these rules of thumb I learned from other people and some were learned through trial and error.

Remember that the statements contained in this article are just rules of thumb intended to help guide your management of a Product Backlog. They are not rules to adhere to no matter what. Always use common sense when applying a rule of thumb to your particular context.

The title alone should generate imagery ranging from destructive rumors to the macabre. Who are these dead, and who is speaking ill of them? "The dead" are former team members, the ill speakers are those who blame problems on them, and we are taking a critical look at this complaining with just a touch of irony. We are talking about the culture of blaming current problems and challenges on team members who are no long with the team for whatever reason. Almost anyone who has been involved in the software development life cycle has experienced this behavior, and very possibly taken part in it even with the best intentions in mind.

Untruths about software testing are common. Managers, programmers, and other people on software projects don't always mean to deceive. Quite often, they fool themselves into believing what they want to believe. But sometimes they lie deliberately and even pressure testers to lie. And testers can also practice deceptions and self-deceptions of their own. In this column, Fiona Charles describes four categories of common deceptions and self-deceptions in testing and outlines what testers need to do to address them.