Review 1 – When the Confluence / Jira Documentation is updated.

Review 2 – On Completion of development, there will be a demo to exhibit business functionality and a code review to measure code quality.

The process needs to be redone if the expected standards are not met.

The Business analysis will be all complete and approved at this stage. All development tasks will be broken up into Jira tickets that match the development task according to the architecture. A ticket should only contain work for not more than one day.

The list of tickets in the sprint needs to be all tickets that are required to be completed within the sprint.

All meeting activities need to be setup on outlook and sent through to the relevant role players.

This is a task before the sprint starts.

All tasks / tickets for the sprint need to be in the sprint on Jira.

The Sprint will be delayed until this is completed.

The Statistics related to task delivery and management will be measured.

Daily from a technical perspective and weekly from a compliance perspective.

The outcome will define the set of tasks that were executed and the order.

Each development task needs to be defined by a matching Jira ticket. If the task was not catered for during planning, a new ticket needs to be created.

A work activity should be broken up into multiple tasks. The idea is that no task should take longer than one day to complete. Ideally multiple tasks needs to be completed per day.

If you look at a sprint board, you should have an idea of what has been done, what is in progress and what is outstanding for the sprint.

The main report will be drawn at the end of the sprint in the form of a burn down chart. This chart will show the rate at which tasks have been executed.

Any tasks not completed will be carried over to the next sprint. The report will also demonstrate if the ticket management system was used effectively.

Every Class and Method should have individual corresponding test case:

The test cases need to test the normal functioning scenario, the most positive scenario, the most negative scenario. The same rationale needs to be followed for failure scenarios.

*The case of a test that tests multiple classes and methods should be used to prove overall functionality but does not replace testing of each class and method.

The final review will take place at code review time by the Tech Lead.

The final outcome will be that the test cases cover every possible scenario identified during the analysis process.

If the standard is not met, the process needs to be repeated up until all possible scenarios are covered.

The final review will take place at demo and testing time by the dedicated tester.

The final outcome will be that the implementation covers every possible scenario identified during the analysis process.

If the standard is not met, the process needs to be repeated up until all possible scenarios are covered.

Meets the following criteria:

·       Matches business requirements

·       All unit Test cases are completed and running successfully

·       Code meets coding standards

·       Code is efficient

·       Code follows predefined architecture.

The final review will take place after a feature is completely developed by the Tech Lead.

The final outcome will be that the output matches the business requirements and that the quality meets all necessary standards.

If the standard is not met, the process needs to be repeated up until all possible scenarios are covered.

The Sprint Demo is used to showcase all of the work that has been completed during a sprint.

The meeting needs to be structured and the agenda needs to be communicated in the form of a Power Point Presentation in the beginning of the demo.

All tasks planned for the sprint needs to be completed, Jira needs to be updated with all tasks completed. 

The Sprint Demo is conducted at the end of the sprint.

The content of the demo will exhibit all functionality build during the sprint.

The business and technical team will determine if all objectives have been met.

The business and technical owner will determine success of the delivery.

If the delivery does not meet expectation of a particular role player, the enhancements or additional functionality needs to be planned for in the next sprint.

The Statistics related to task delivery and management will be determined.

All documentation should have been updated in Confluence.

This objective improves the quality of the development process.