This is a guest post by Nishi Grover Garg.
Exit criteria is a list of items to check off that defines the end of any activity. Exit criteria can be defined for any activity you want to undertake: You can have exit criteria for cooking veggies to the desired doneness, or for a city tour to be sure you see all the sights, or for a meeting to assign action items for everyone! Exit criteria are helpful to tell you (and others involved) when to stop the activity.
For an agile project, having clear and concise exit criteria makes it easier to understand the scope and avoid going overboard while keeping a tab on your quality. Let’s look at some ways to structure your exit criteria at the sprint, user story, and task levels in an agile project.
Defining Exit Criteria
The first rule for exit criteria is to have them defined upfront, before beginning the activity.
For an agile project, let’s say we want to have exit criteria in place for the end of the sprint. We will need to work on defining them at the beginning of the sprint, or at the release-planning stage. Once the activity begins, the goal is to achieve all exit criteria by the end. We cannot have people defining or changing the planned exit criteria during the execution of the activity, since that will not be upholding the quality standards set in the beginning.
The second rule is to have standard exit criteria for all similar activities. So, exit criteria defined for the sprint level apply to all sprints in that release, and exit criteria defined for the user story level apply to all user stories in all sprints. This upholds the same standard of quality and expectation of work required for each of these work units.
In some special cases, we can have additional technical criteria added to a certain user story or sprints, like the need for a special type of testing or an additional design task. But more or less all items have similar exit criteria, and there is no leniency or special discounts on meeting these criteria once defined. Though it can be tough to follow through on this, it will ensure fewer issues and keep the accumulation of technical debt in check.
Sprint Exit Criteria
Exit criteria for a sprint should be defined based on the tasks, user stories, features, and work units in the sprint, at a generic level.
Here are some examples of sprint-level exit criteria:
- All user stories in the sprint backlog must be completed (see next section)
- All design tasks and special tasks picked for the sprint must be completed
- No critical issues must be open
- Regression testing of all features developed in all previous sprints must be executed
- The automated regression test suite must be executed at least once with no issues
- Anything else you would like to be done in the sprint
User Story Exit Criteria
Exit criteria for user stories should be defined for all user stories in a generic manner. All tasks should ensure that each unit of work produced is of high quality, continuously, but if deemed necessary, user story exit criteria can be made more stringent over time.
Here are some examples of user story exit criteria:
- All tasks defined for the user story must be completed (see next section, and note that this will automatically include development, testing and other tasks)
- Issues logged against the user story are triaged, resolved and retested
- No critical issue logged against the user story must be open
- Tests for the user story have been added to regression pack
- Automated tests for the user story have been added to the automation suite
- Code review was performed by a buddy developer
- A static analysis tool has been run on the code and resolved all code refactoring and reformatting errors
These criteria will ensure that all user stories achieve these goals before being deemed “done” at the end of the sprint. Not having completed even one of these items would mean the user story cannot be closed, so it would be considered a “spill-over” item at the end of the sprint.
Although this may seem harsh at times, it helps ensure quality. Say we did not have time to run the static code review tool report but did everything else on the list; would we want the user story to be shown as incomplete at the end of the sprint? If we give the story a pass this once, it may end up seeming unimportant and be repeated in the future. By the end of the release, we could have a pile of user stories that need to have the static code review tool report run, and correcting the issues would take days of effort — a luxury we may not have!
To ensure that this does not happen, we look at the user story exit criteria and create multiple tasks within each user story as we add them to our task board or any project management tool we may be using.
Each user story will have mandatory tasks for most of the exit criteria items and an owner for each task, so there are no chances of missing these items.
Task Exit Criteria
Each type of task can have its own exit criteria.
For instance, for a development task where the goal is to write code for the feature or user story, these are some possible exit criteria:
- Code must be written covering all requirements (all acceptance criteria must be met)
- Code must uphold professional standards, proper commenting and naming conventions
- Code must be checked in with all dependencies updated in the list
These are some possible exit criteria for a testing task that tests the user story:
- Test scenarios are written and updated in the test management system
- Test scenarios are reviewed by the team and feedback is updated
- Tests are executed and any defects are logged and linked with the user story
- Relevant tests are added to the main regression pack
You can also define exit criteria for code review tasks when a senior or peer developer reviews the code for a user story assigned to another developer. Having this as a separate task ensures accountability and also gives developers assigned time to do this step in addition to their own tasks.
For this task, possible exit criteria could be:
- Code review is done for the user story
- Feedback is provided and incorporated
Test automation tasks can be a separate category, since you may have different owners for testing and test automation for the same user story. If it requires additional environments, licenses, and setups, it may also make more sense to keep track of these tasks separately.
These are some possible exit criteria:
- Identified tests are automated from the test scenarios
- Scripts for automation of identified tests are created
- Created scripts are added to the full test suite with relevant tags
- Test scripts are executed at least once as part of the full test suite
Make Your Own Exit Criteria
There may not be one ideal list of exit criteria that fit every team’s needs, but there can be useful pointers you may be able to take from these sample exit criteria lists. You can decide on your own exit criteria based on your project and the team’s context, and you can decide to make them as lenient or as stringent as you want.
The important things to focus on are having the exit criteria defined upfront and ensuring follow-through by sticking to the criteria throughout your release cycle. Being consistent with checking off everything on your exit criteria list ensures a smooth flow of high-quality work. Learn more about exit criteria here!
Nishi is a corporate trainer, an agile enthusiast and a tester at heart! With 11+ years of industry experience, she currently works with Sahi Pro as an Evangelist and Trainings Head. She is passionate about training, organizing testing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
