Our tester recently informed me that several stories we had completed in a previous iteration were failing tests. The functionality simply was not working. To make matters worse, at least one of the stories was actually coded and marked complete by me! I was dumbfounded. How could I mark a story complete when it was not done?
After pondering the situation for a while, I discerned at least one problem: We had no acceptance tests to define when a story was complete. Therefore, there was no failing test telling something wasn’t working. As a team we quickly implemented a two-fold policy: (1) No code may be written for a story until we first define its acceptance criteria, and (2) A story may not be considered complete until all its acceptance tests pass.
How well has it worked? Well, we have not had any missed requirements since implementing these policies. And our tester is thoroughly impressed with the increase in code quality. Furthermore, I have found that the process of coming up with the acceptance tests, gives us a much better understanding of the user story. We better understand the customer’s expectations, how they will use the functionality we are implementing, and why they need it. This helps us arrive at a more correct and complete design. It also helps increase the accuracy of our estimates since there are fewer unknowns, and more information. All in all, the introduction of acceptance criteria into our process has had an extremely positive affect on the project.
So, don’t forget those acceptance tests!
-=CE=-
