Know your requirements
Requirements management is extremely important to developing a quality product. One aspect of quality is known as functional quality. Functional quality is a measure of what the software does vs. what it is supposed to do. You need to be able to capture requirements and convey them to the development team to be able to measure quality.

One of the most widely used products for capturing requirements for .NET developers is Visual Studio with Team Foundation Server. Visual Studio is the development environment for .NET and Team Foundation Server that extends Visual Studio to add full ALM capabilities.

In agile development, requirements are captured using user stories. A user story is a story of what the user does or needs to do as a part of his or her job. It is not a comprehensive description of their entire job, but a small vertical slice of functionality. Good user stories fit into a single sprint of work that usually lasts about two weeks.

Any user story longer than a single sprint is referred to as an epic. Epics should be broken down into two or more smaller user stories. Consider the testing of the functionality when creating a user story too. If you find that the test for the functionality is more than the sprint allows, then your user story is still an epic and you need to break down the functionality further into multiple user stories.

Breaking down functionality into small manageable user stories (i.e. functionality) is a best practice and helps later on during the testing phase. You will find it is much easier to write tests, and over time you will be able to build up a suite of tests for the product.

Create a definition of done
All user stories should have acceptance criteria, which are the requirements that have to be met for a user story to be assessed as complete. One cannot measure functional quality without specifying acceptance criteria. No user story should be started unless there is acceptance criteria associated with it.

Ensuring functional quality is not enough to develop quality software. There are a number of non-functional quality measures that affect the overall quality of the application. Non-functional quality has an impact on the impression of the application. Examples of non-functional quality measurements are performance, throughput, code readability, and test code coverage.

One way to help ensure that both functional and non-functional quality is addressed is to create a definition of “done,” which is a listing of those steps that a developer must do before he can mark a task as being complete. The following is an example of a definition of done:

  • Code written using development standards
  • Code commented on appropriately
  • Builds with no warnings or errors
  • Code committed to source control
  • Unit tests written and passing
  • Tests with expected and unexpected conditions
  • Minimum code coverage achieved
  • No TODOs left in the code
  • Peer and/or team code review completed
  • Tasks marked as completed

This might seem unattainable to some, but I am here to tell you that it is absolutely attainable. You just need unwavering commitment. I have found that not following a definition of done such as this has always led to some form of regret. That regret often manifests itself in extra work that you did not plan on doing.