Great article from David about “evolutionary architecture” and a nice example about it from the Microsoft Word ribbon.

David explains desirements and requirements as:

A desirement is a non-compiled request for software to change. Examples include specification documents, Team Foundation Server Work Items, index cards, and hope expressed with Microsoft Word.

Everyone can state a desirement and throw it on the bottom of the wishlist.
The interesting part is when a desirement gets closer to be a requirement (bubbles up) and the team discusses about the details and writes acceptance tests with the business to confirm them. 

A requirement, on the other hand, is an automated test proving desired behavior exists in software. Requirements (tests) must pass before software may ship.

This leads to creating a ATDD Ready Backlog, which is a great way to make sure you have “always releasable software”.

Full article from David Starr:
http://visualstudiomagazine.com/articles/2013/01/07/leveling-up-agile-requirements.aspx

Great insights into Elisabeth’s daily troubles. Worth the 30minutes

My favourites (which I see a lot)

• Why doesn’t separation of duties between engineers and testers work?
   (01:49)
• What’s wrong with the approach of writing and executing manual test scripts?
  (07:53)

http://continuousdelivery.com/2012/10/elisabeth-hendrickson-discusses-agile-testing/ 

TL DR;
ATDD + TDD significantly improve code quality and reduce maintenance costs, 
and also contribute to faster project delivery and thus reduced project costs.

The article cites 2 studies:

1. teams using agile development practices including in particular ATDD and TDD delivered projects 31% faster with 4 times fewer defects
2. TDD significant improves the quality of the code (in terms of the defect rate)

There is always a cost involved in learning something new… and the gains might take some time to cristalize!

Acceptance Test Driven Development (ATDD) is a very effective development practice that essentially involves writing specifications in the form of documented and automated examples. These automated examples become automated acceptance tests that validate the features being delivered. The process of writing these examples encourages teams to focus on where the business value of a feature is coming from, which in turn helps developers aim for the most appropriate solutions in business terms.

Nice!

code written using good TDD practices is significantly easier to understand and maintain.

Same experience here

Full article by John Ferguson Smart
http://weblogs.java.net/blog/johnsmart/archive/2012/09/12/does-atdd-really-save-you-time

Great explanation from fellow trainer Ralph Jocham about ATDD + Scrum, where he explains how to approach testing in Scrum with the goal to have a “ATDD Ready Sprint Backlog”

This is one of the topics ATM that I am most excited about

BTW: Steve Freeman has exactly done this with an XP team in London
My recap 

Sustaining an XP team over 7 years
http://gfader.tumblr.com/post/19004526097/qconlondon-recap-sustaining-an-xp-team-over-7-years  

Ralhp’s article here
Creating an ATDD Ready Sprint Backlog in Scrum http://www.methodsandtools.com/archive/atddreadysprintbacklog.php

Best part

ATDD isn’t about a tool like FitNesse, Cucumber, or Robot Framework. ATDD is about making sure that your development team develops the right product

What I was missing in that article is

#1 “Gherkin” as a DSL that helps discuss a specification between shareholders, business people and developers

#2 Distinction between Feature and Scenarios

Getting Started with ATDD: Overcoming the Biggest Mistakes Right from the Start
http://www.informit.com/articles/article.aspx?p=1905549

Great article with the history behind of BDD and the “differences” between ATDD and BDD.

A great statement can be found in the comments:

I also conclude in that video that the difference doesn’t matter – as long as we’re delivering products that matter.

http://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/