Definition of Done and Acceptance Criteria – the most important factors for more predictability in software development

We all hate uncertainty, in all the aspects of our lives. We hate when the weather changes “unexpected” and ruin our weekend plans, we hate when a traffic jam disarrange that important meeting we have, we hate when the stock market crashes right after we’ve just invested our savings.

Predictability brings us comfort. We like to have a plan, even a plan B. We like to “count on” something and not to be surprised, especially unpleasantly surprised.

But predictability it’s a trap! The truth is you can never be sure. That’s one of the main reasons for which the waterfall methodology keeps losing followers and more and more companies embrace agility and frameworks like SCRUM are so popular.

However, with every new release (or at the end of each sprint in SCRUM), people expect to find predictable results. The increment should work, and it should work in a way they are expecting. When this last thing doesn’t happen there is a problem and everyone in the organization is upset and confused: stakeholders don’t see what they expected to see and developers are frustrated because they “did their job”. Then, where is the problem?

The key to avoid this situation is a good, solid, Definition of Done (DoD).

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

The Scrum Guide

In other words, the Definition of Done (DoD) should contain all the criteria to be applied before work is considered done and typically this means both functional and non-functional requirements. The difference between these two is that functional requirements describe what the system should do while non-functional requirements cover all the remaining requirements which are not covered by the functional requirements.

Many times a poor definition of done is considering the functional requirements but tend to ignore one or more of the non-functional requirements. This happens when the organizational standards are ignored and it is the job of the Product Manager to be aware of them or to ask about them if he or she it’s new in the organization or working as a temporary contractor.

Some typical non-functional requirements are:

  • Performance (Response/Loading Time, Downtime, Utilization, etc.)
  • Scalability
  • Capacity
  • Recoverability
  • Maintainability
  • Security
  • Data Integrity
  • Usability
  • Documentation
  • and so on…

There are several ways we can make non-functional requirements visible in an Agile context.  The most common ways of doing this are with an explicit backlog item, as Acceptance Criteria, or as part of the team’s Definition of Done.

Integrating non-functional requirements into the Definition of Done should be done when certain non-functional requirements are applicable across the entire solution, like a comprehensive checklist indicating what “Done” looks like both in terms of functionality and non-functional quality attributes.

Specifying the non-functional requirements for individual backlog items can be done as “Acceptance Criteria” at the end of each User Story from the product backlog.


Example:

As a customer, I want to see my order history in my account so I can quickly reorder or print my invoices.

Acceptance Criteria:

  • System is loading the most recent 10 orders and the loading time should not exceed 2 seconds;
  • The page should re-authenticate the user if any of the orders contains sensitive products, making sure only the owner can see them and not anyone else in case he forgot to logoff;

Both Definition of Done and the Acceptance Criteria must be met in order to complete a User Story. The product increment is not considered complete unless both are checked.

Transparency is one of the core values of Agile, critical to the success of organizations and groups adopting this methodology and one of the three pillars of SCRUM framework. And even if we cannot be sure of anything, transparency is the key to at least try reaching a better predictability in software development. And having a good Definition of Done is the key to this achievement.

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 3

No votes so far! Be the first to rate this post.