The Definition of Done and QA

What actually "Done" means

This ambiguity is often a source of frustration for Product Managers and Development teams. That frustration might be overcome by using the Definition of Ready and the Definition of Done - a well-known method from the Agile world to ensure that the entire team understands what “Done” actually means. Very often it comes as a checklist defining what criteria has to be met to allow us say "It's done".

Let's take the example checklist for the "DoR" and "DoD" of the Task for one of the maintenance projects:

The Definition of Ready and The Definition of Done

As a general rule our primary goal is to get the card moving from the left to the right as soon as possible. Your responsibility is not only pull the issue into in-progress and then pass it into UAT or Testing. Every time we're pulling the issue into IN-PROGRESS, we’re starting to be responsible for that task to be READY and DONE. And our definitions of ready and done are:

1. Do I fully understand what is both the: business and technical goal of the task?

2. The source code is created on a separate branch - is it merged into the master branch?

3. After work is finished pull request has been merged to the 'staging' branch. Have I merged (or rebased) master into my FB before making a pull request?

4. Was the code peer-reviewed?

5. I've tested my own source code, and it was working well?

6. UAT Scenario for the tester has been created, or the task’s goal is clear based on the task description?

7. Did I make sure that the result of my work is accessible on staging? If the issue is waiting too long on Testing you should check what is wrong - why does your work not move right?

8. Has the issue been tested on staging by the Customer or authorized QA Team member? (We don't want to prod-deploy without customer acceptance)

9. Have I remembered to merge the FB into the devel branch after the issue had reached the Ready to GO LIVE column?

10. Was I present during the deployment - have I checked my solution on production during the deployment?

11. Is the task signed off by the Product Owner into the Done column?

Until we don't answer YES for all the above questions, our work cannot be stated as DONE.

Sometimes, we cannot clearly state if the business goal has been really achieved, even after the production deployment is done and all the tests passed. That’s why our Quality Assurance team is adding one extra point to the DoD:

Is the business value delivered?

Let's consider the following task. We want to increase the user experience on the website and SEO potential by increasing the Google Page Speed result to be “green” for 85% of the customers visiting the webpage.

The development team plans out the list of tasks that has to be completed to bring us closer to the goal. Lazy loading images/videos, reducing font numbers, reducing the js execution time, working on the critical css, and much more. Work is done in iterations, integration tests are executed after each deployment. But we still cannot state right after the production is updated if we reached the goal, as the real user data is accumulated over time - so QA Team is adding it to the list to check later and bring back or sign off once we have the data.

The definition of High Quality eCommerce website

Moreover, once we hit the milestone - this doesn’t mean it would stay that way forever. Google evaluation metrics are changed over time, and the new features are developed all the time - so we should actually make sure the scoring is still high even after weeks or months... That way, the Definition of Done of one task is starting to formulate something bigger- the Definition of High Quality eCommerce website - which means - it has to be monitored all the time.

More about how we do it and how our QA defines and track the High Quality eCommerce in our next posts.

For your convenience, we have prepared DoR and DoD to download.

DoR and DoD Hatimeria.pdf