Every project phase has a beginning and an end.

This means that some criteria will need to be satisfied in order to start a phase and some other will need to be satisfied in order to mark the phase as completed.

Very often we care about the requirement to start (entry criteria), but we do not give enough attention to the requirements that mark the end of a phase (exit criteria), unless they were specified within the contract.

Not being able to respect or not fixing correct exit often causes problems to the later phases or, even worse, if many teams are involved: for example when the development team gives control to the maintenance team it is really important that the documentation respects strong requirements in term of quality, in case not, even the easiest change will imply the analysis of the source code, which can be a really time consuming practice.

Exit criteria do not need to be complex, nevertheless they should include at least the following:

• Deliverables list
• Required quality for the deliverables
• List of deliverables that are going to be produced but not completed
• List of what is not going to be done and/or completed

There are different ways to define, communicate and monitor exit criteria. What is important is that everthing is prepared at the beginning (ideally during the planning phase), kept as simple as possible and used in project control.

Some examples of exit criteria:

• All analyses are completed, technical design is completed. This criteria is relevant before starting programming to understand if it is possible to start programming with a low risk level, completing a minimal set of functions.
• All planned deliverables are completed. Usually once all deliverables are completed the phase is considered as completed and the milestone reached.
• Bug counts is up to a fixed level. Indeed there are meny ways to measure bug levels. Usually exit criterias should specificy the maximum amount of accepted bugs for each bug category.
• Specific test are passed. There may be a set of test condition that may be used to determine if the milestone was reached. If we use the criteria of test passing, then this criteria can be combined with some bug criteria (e.g. 90% of defects of category "Medium" are solved). It will be possible, eventually, to express the condition that a given percentage of test are passed to consider the test passed.
• Performance metrics. For example the application must finish within a defined limit or the average duration of a group of transactions must be lower that a well defined limit. It is also possible to specify, as a criteria, a percentage of increase in the performance of an application (e.g. reduction of wait time to access the db of 10%).
• Documentation. That means the documentation attached to the technical deliverables. If the organization is mature enough we should be able to include some quality condition on the documentation
• Time/Cost. Time is one of the simplest exit criteria: when a certain time interval is gone, the milestone must be reach (here we speack of timebox projects). Costs are a good exit criteria as well: once the budget is gone, the project is ended.

If we take as example the completion of a milestone :

• All deliverables of the phase completed;
• 90% of documentation completed and baselined;
• At least 50% of documentation must have passed a formal inspection;
• All test on critical functions must have been completed without errors;
• At least l'80% of test on accessories functions must be completed correctly.

Another example about completing the Integration Test:

• The new application was installed and correctly integrated in the test environment;
• The integration test responsible (or his team) completed correctly 100% of the tests;
• All priority found during the tests 1 bugs are solved;
• In case of changes documentation was modified and later baselined to reflect modification to the application;
• All executables are in baseline together with release notes.

From the examples we see that without clear exit criteria it is not possible to specify what we mean by "phase completed". It is clear, moreover, that without exit criteria we simply create additional risks for later phases on a project, as there is no assurance of what the new phase will expect to receive.

To some extents specifying exit criteria it is a risk management process, since the idea is not only to get a clear end to a phase, but also to guarantee quality levels that will allow other team members, users or who will maintain the system to have a minimal set of expectations once they will start working on the product.