When I first started working as a Software QA Engineer 4 years ago, I remember being unsure when a job was really ‘done.’ As I gained more experience, I quickly realized the importance and value of establishing explicit user stories in each development phase.

After conducting some research, my team and I decided to use the “INVEST” structure to standardize our user stories.

I – Independent (of all others)

N – Negotiable (not a specific contract for user stories)

V – Valuable (every user story must add value)

E – Estimable (to a good approximation)

S – Small (enough to fit within an iteration)

T – Testable (in principle, even if there isn’t a test for it yet)

Reference: www.agilealliance.org/glossary/invest/

Let’s put it this way: imagine that your team is working on a new application, and the first task is to create the login page for premium users. The first user story can be as simple as the following scenario:

User Story:

– As a user with special privileges, I want to log in to see premium articles.

Acceptance criteria:

– Given I’m a user with special privileges, when I log in successfully, the message “Welcome, <name>” is visible in the navigation bar.”

– Given I’m a premium user, I can access any premium article when I log in successfully.

Out of scope:

– Paywall implementation.

To start the project, we can say that the UX team takes the user story and starts creating all the necessary mockups.

Once the mockups are done, it’s time for the development team to start working on the code. When the code is finished, the QA team uses the user story to execute all the necessary tests.

Finally, the user story is appropriately installed in the production environment.

In the example above, the process from user story –> design –> development is smooth but can quickly become complicated if the team involved hasn’t defined a set of checklists to identify when each stage of work is “ready” or “done.” 

To avoid confusion within a team, we need to understand the following concepts: DoR (Definition of Ready) and DoD (Definition of Done). These concepts are checklists or agreements defined by the team. Each stage can have a DoR and DoD. 

Let’s establish the DoR and DoD for the different stages of the project in our example above.

DoR and DoD for the UX stage of the project:

 DoR:

• Devices defined (Desktop, Mobile, Tablet, etc.)
• Accessibility elements and rules identified (Labels for each web element, avoid using only elements like arrows without text, etc.)
• Standard colors (Primary colors, contrast, etc.)

DoD:

• Mockups documentation in a tool
• Mockups approved by the product owner
• Mockups for all the screens related to the user story (Login page, the home page, message errors, premium articles list)

DoR and DoD for the DEV stage of the project:

 DoR:

• The mockup is ready
• Dev environment is set up correctly
• Proper access to the application
• Acknowledgment of the technologies and tools implemented in the project

DoD:

• Unit tests passed successfully
• Pull Requests documented (Description, tests involved, how the code works, etc.)
• Builds passed successfully in the pipeline

DoR and DoD for the QA stage of the project:

 DoR:

• QA environment setup
• Test data defined
• Proper access to the application
• Test plan defined (preconditions, scenarios, steps, expected results, etc.)

DoD:

• All tests passed successfully (two negative scenarios for each positive scenario)
• Exploratory testing
• Automated tests passed
• Test results documented

In conclusion, if we don’t define the DoR and DoD in our Development Software Life Cycle from the beginning of every project, we must take the initiative and build a proposal to establish them before development begins.

DoR and DoD apply for each stage of the cycle and help remove any ambiguity, which results in a proper work process.

While creating a DoR and DoD, note that there is no standard. They can vary based on the project necessities and must be an agreement between the entire team to achieve a better and organized working process.