Definition of done

Definition of done

In “User Stories Are For Technical, Operational and Risk Stories Too!” we made the case that user stories are not just for customer facing user interfaces.  But, we only partially answered the question:

“I would like to see some sample user stories in infrastructure projects such as network migration or upgrade, storage provisioning, or server provisioning.  I think storage provisioning would be a little bit complex due to hardening and other security requirements.”

The nuance in the question centers on the phrase “hardening and other security requirements.” There are two approaches that I often use for stories with nonfunctional requirements.  The first (and not my favorite) is through a final hardening sprint. The second approach is splitting the user stories into thin slices and then incorporating the nonfunctional requirements into the definition of done.

The first solution is leveraging a final hardening sprint. In this scenario an integrated solution is assembled, tested and tuned. Many organizations wait to perform security testing until they have a fully integrated system. In some cases, such as a high security environment or scenario where entire solution is not available to integrate into a single environment, this approach is difficult to avoid. The difficulty with this approach is that it puts off gaining valuable feedback on security and integration until very late in the project. Finding problems late in the project can imperil delivery or cause defects to be pushed into production (Go fever is the pressure to implement even though there are known problems).

The second solution begins by incorporating hardening and security requirements into the story’s definition of done. The definition of done is the requirements that the software must meet to be considered complete. Adding hardening and security requirements to the definition of done will cause the team to add specific tasks to both ensure the requirements are built into the solution of the story and then prove they are implemented. The added tasks will either require the team to accept fewer stories into the sprint or to more thinly slice each story.  This approach is optimal in organizations that continually integrate and test functionality as it is built, however I recommend it for any organization even when an overall final test is required.

A better approach is to combine the both options.  For example, a manufacturer of financial hardware I spoke with recently develops hardware and software on different development tracks which requires a final integration, security and a stress test sprint. In order to avoid potential shipping delays, which are viewed as potentially catastrophic to the business, security and hardening requirements were added to the definition of done for both hardware and software stories. Teams built testing appliances and harnesses to generate early feedback on the nonfunctional requirements.     

Security and hardening are nonfunctional requirements that affect how hardware or software requirements are built, tested and delivered.  These nonfunctional requirements are tasks, not separate stories.  Task and process requirements are better suited as components in the definition of done that are applied to stories and help teams plan their work.