Planning and developing new features at the fast pace of agile is a hard game. Knowing when you are really done and ready to deliver is even harder.
Having predetermined exit criteria helps you be able to make the decision that a feature is truly ready to ship. In my article published at TestRail Blog, I compiled a list of exit criteria you must add to your user story to make it easy to bring conformity and quality to all your features.
All Tasks Are Completed
This first one sounds obvious, but it may not be. I still see many teams struggling with getting their testing done within the sprint. Developers work on a user story and deem it done, while testers are left to play catch-up in the next sprint.
Put that practice to an end once and for all by making sure that no user story can be proclaimed done without having all tasks under it completed, including development tasks, testing tasks, design and review tasks, and any other tasks that were added to the user story at the beginning.
Ensuring all tasks are completed in a sprint also mandates that you begin thinking in depth about each user story and the tasks necessary for each activity to be completed, so that you do not miss out on anything at the end.
Tests Are Automated Whenever Possible
As our agile teams move toward continuous delivery and adopting DevOps, our testing also needs to be automated and made a part of our pipelines. Ensuring that test automation gets done within the sprint and is always up to pace with new features is essential.
By having test automation tasks be a part of a user story delivery, you can keep an eye out for opportunities to automate tests you are creating, allocate time to do that within the sprint, and have visibility of your automation percentages.
I have used the following exit criteria:
- At a minimum, regression tests for the user story must be added to the automation suite
- At least 50% of tests created for the user story must be automated
- Automated regression must be run at least once within the sprint
Depending on what your automation goals are, decide on a meaningful standard to apply to all your user stories.
Critical Defects Are Found and Addressed
It might be easy to get caught up in the pace of the sprints and keep tackling new features to develop, but without testing as we go, you may end up with a pile of defects that render those features useless. It is imperative to test features within the sprint and focus on the defects your testing finds.
A good start would be to link all issues related to the feature to its user story. When you look at the user story task to mark it complete, you must be able to see the issues found and then decide if the feature can actually be called “working software” based on the open defects. Read More->
Tasks Have Been Peer-Reviewed
We have all heard that an ounce of prevention is better than a pound of cure. A great way to prevent defects is incorporating reviews and static tests into your sprint.
Be it test plans, architectural designs or help documents, anything that can be reviewed can be added as a review task so that you ensure it gets done before the user story is deemed complete.Read More->
*No Exceptions Please!*
Adding meaningful exit criteria to a user story is important, and so is following through on them. Once you decide on a set of exit criteria, stick to them and make no exceptions. It may be hard at first to see a user story not meet the criteria and have to spill over into the next sprint, especially if it’s due to a small thing that was missed. But over time, it will make you and your team better at keeping up with the criteria and bring you closer to your quality goals.
Read the full article published at TestRail Blog -> https://blog.gurock.com/four-exit-criteria-user-stories/