Done, done, done and done

While working in big projects we often try to get some story points instead of making story done. After some time we are not even sure if functionality is still working correctly. But there is a solution.

I recently read very interesting book: The Art of Agile Development by James Shore. Between many important information I found one thing that is really crucial.

When story is done?

As author says it is done when it is production ready and is:

  • Tested (all unit, integration, and customer tests finished)
  • Coded (all code written)
  • Designed (code refactored to the team’s satisfaction)
  • Integrated (the story works from end to end—typically, UI to database—and fits into the rest of the software)
  • Builds (the build script includes any new modules)
  • Installs (the build script includes the story in the automated installer)
  • Migrates (the build script updates database schema if necessary; the installer migrates data when appropriate)
  • Reviewed (customers have reviewed the story and confirmed that it meets their expectations)
  • Fixed (all known bugs have been fixed or scheduled as their own stories)
  • Accepted (customers agree that the story is finished)

In my opinion we are often missing one item here. We should have automated test for each scenario of a user story. I know that in perfect world we should get some tests with story requirements, but often that doesn’t happen. Instead we should extend definition of Done and add there

  • Has automated acceptance tests (we will get feedback as soon as other changes break this functionality)

Without this we can forget to add those tests or when we are in hurry before release we can skip this phase on purpose. This can lead us to aggregating technical debt which is not directly connected to poorly written code, but to lack of confidence while refactoring and implementing new features.

Often, few releases later we will be wondering, why some functionality is not working any more, and when somebody broke it. This is the only way I know to prevent this. Integration tests are not enough, because usually we skip UI part and focus only on core components of the system.