Awesome idea!

I guess most of these tools grow as a personal side project. But even then we should try to follow best practices… at least when we release to the wild…

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 :-)