I’m Robert Dempsey, CEO and Founder of Atlantic Dominion Solutions. We developed Scrum’d: http://www.scrumd.com. A great post and an excellent challenge. To answer your questions:

# Your Definition of Done

We define done for each user story. Acceptance criteria includes the behavior a user can expect from the app when using it, the workflow for the feature, that it needs to be tested (and how it will be tested), any validations that occur, and if there is documentation for the feature that it is updated.

# Whether you use TDD? Or at least Unit Testing?

We do full TDD for all of our stories. We didn’t start out that way, however now that we have a full test suite we keep it that way. Also, if a bug is found, then a test needs to be written for that and then the code fixed.

# What do you do for Acceptance Testing?

We have staging servers set up for internal testing. We also have a few select customers that we let into our staging servers, and I show (in person) some of our current and potential clients the features to get their feedback as well. In addition, we use Get Satisfaction for our support site, and ask that commenters who suggested features that we implement to check out the release and see if it’s what they wanted.

# How often do you release?

This depends. We try to do monthly releases. Sometimes it longer, but typically it’s less. The release schedule really depends on the importance of features to our user community.

# What did you learn in your last retrospective?

You don’t always get it right the first time, however anything you do release needs to work correctly. Also, continuous integration is a huge help as your product gets bigger, and of course, testing is an absolute necessity. We would rather delay a release to ensure quality than release stuff that won’t work.

Our DoD for stories:
- code meeting minimal requirements committed,
- unit tests passing,
- feature is working under FF, Chrome and Opera,
- feature is working without any significant failures under IE
- feature is tested and accepted by at least one team member that was not implementing the story

Our DoD for release:
- WAR and .exe distros built successfully,
- all unit test passing
- all functional bugs fixed
- all UI bugs fixed or small UI bugs (mostly for IE) at least scheduled to be fixed
- installation and upgrade documentation updated
- installation tested on Windows and Linux
- new features list updates at product web site

Do we use TDD? Well I would not say that becuase our coverage is not 100% which means some of our code is not unit tested (glue code), but yes we do unit testing with “test first” style for all domain and business logic code and we tend to shift into BDD style right now.

As our Product Owner is also one of active developers, for acceptance testing we tend to verify features within a team as we have strong and common vision of a product within the team (see also acceptance in our DoD for stories). It’s a low ceremony process (as all our processes in the team)

How often do we release? Every 2-3 months.

What have we learned from our last retrospective? That we need to shift into feature branches to be able to release small stories more often while the big ones are still in progress.

So what tool is it :-)? It’s tinyPM
Do you see any flaws or warning signs in what I’ve posted here? Go on, say it… we’re always happy to improve…

Regards,
Marcin Niebudek

So for me of course 100% coverage is not a goal itself (we’re rather pragmatic on this), but in other hand not having 100% coverage is an evidence of not doing full TDD. If pursuing the full TDD is a good thing or not that is completely different question and I’m not going to start any religious war here :-)

“Another noteworthy point was that almost all of the groups we interviewed acknowledged that they didn’t use any well-defined process themselves (not even the agile methods they preach). When asked, “Do you use XP [XP]?” or “Do you use Scrum?”, they invariably replied that their developers used a mix of best practices that didn’t strictly adhere to any published rulebook. None of the interviewees were defensive about this; all clearly believed that they had above-average developers who could be trusted to use pair programming, test-driven development, and whatever else was appropriate in context. This emphatically does not mean that their processes were chaotic: in all cases there was close and frequent coupling between development on one hand and requirements gathering and feature prioritization on the other. However, the day-to-day mechanics of actually producing high-quality code was trusted to developers and their consciences. It remains to be seen whether the users of the tools do follow specific agile methods or, as the tool developers’, they just use their own mix of agile practices.”

So I suspect the relevant tools vendors (Rally, VersionOne and Mingle) could all give good answers to these questions.