Feature Quality: QC/Dev Alignment

During Agile work, as a team, we care about customer satisfaction by getting earlier feedback during Agile sprints, but at the same time, we need to represent sprint work with high quality and we need to make customers happy. We want to make them say: "That's exactly what we expect!" So, in order to accomplish that, let's look at the sections below.

Feature Quality Tips and Tricks

As an Agile team, we represent each feature in multiple user stories.

After the user story is refined, team members should develop acceptance criteria, preferably one that also includes indirect scenarios.

Acceptance criteria should be written from the user perspective, so it is recommended to write them using the "Scenario Oriented" format.

Example:

Given I have the app open,  when I am writing on the doc,  then the bell icon should update to show unread notifications with the count.

The whole team can share during writing acceptance criteria for better brainstorming and ensure that the development team has checked them already.

User story planning using "expected dates to deliver."

User stories are refined, acceptance criteria are written for each, so now, it's time for setting dates!

Setting the expected date, per each user story to deliver, helps the quality team and project lead/manager to set expectations, and set planning.

Setting the actual date of the user story being delivered helps the team to get to the root cause of variance if occurred, which will help them for better future planning; this can be discussed during the retrospective meeting.

Happy scenarios test cases are assigned for the development of team members.

Quality control members write test cases based on acceptance criteria per each user story. They can then assign test cases that cover happy scenarios to development team members to make sure that the feature/user story is released to the quality team with at least the happy scenarios functioning as expected.

Happy scenarios test cases are executed by the development team members on the testing environment, not only the local.

Sometimes a development team member says that this feature/user story is ready to be tested on the testing environment by the quality control members, while it is not deployed/merged yet to the testing environment. This could be for some reasons such as that the pull request has not been approved yet, not completed yet, and so on. So, I recommend that the development team member execute happy scenario test cases on the testing environment.

References: 

Scenario Oriented format