The objective of the Release Planning is to plan all the customizations, features, corrections that should be delivered in the next release of the product. This planning can be reviewed and modified in case priorities change during the project. The development team uses the stories written before to estimate implementation effort. The practice 'the planning game' describes that a release should have stories that adds value to the customer business, in other words, stories of higher priority to the customer, in accordance with the Deployment Manager priorities. The development team then estimates how many stories will be implemented in the following iterations based on their velocity and on each story complexity. The Release Planning has to consider effort estimates and risk factors. Stories of high risk should be scheduled in the first iterations to mitigate risk. Research stories are also high risk stories, because there is not enough information on how to implement them.

This worlflow is about planning the next iteration. In the same release we can have several iterations. In the Iteration Planning the estimates defined in the release planning are reviewed and it is defined which and how many stories will be implemented in the next iteration. The analysis of each story individually is part of the iteration activities. Each story is break up into small tasks. During this analysis, if the story is too large to estimate the team can decide to divide it in more than one story. Research stories can also be created when there is not enough information to estimate effort for it. The development team should try to improve effort estimates defined on the release planning The Deployment Manager is the one to determine the set of stories to be implemented. This whole process should be guided by 'the planning game' practice. The software engineer is responsible for defining implementation effort of each story, while the customer along with the deployment manager assign priority levels to each of the stories based on their business value. Priorities should be based on customer priorities and project priorities. In other words, customers set their priorities and deployment manager set priorities for stories according to customer importance.

In this workflow, functional tests for the system should be written. Functional tests are produced from the requirements defined in the Change Definition Document (CDD). The CDD document is the input for the key activity of this workflow. In this approach, tests should be written by a Test Engineer assisted by a Software Engineer. The customer does not take part in the Test Written on site. In this approach, relationship with customers and their location generally makes it impossible to be held with the customer on site. The output of this workflow is the Test Scenarios that will be used to validate system features. These scenarios can be automated or not, it is up to the Engineering team. The main objective of the functional tests is to test the most complex functionalities of the system, while unit test validates class methods.

The Development workflow includes activities such as design, implementation and test of a unit of work. One of the main objectives on the Customization of Software Products should be to avoid changes to core functionalities of the product. Therefore, design definitions that can affect the architeture and business logic of the system should be out of scope from the customizations standpoint. When changes to system core are needed, there must be a general agreement beteween fields operation team and product development team in the sense that individual efforts to each customer is minimized. If a change to the product is a common need it can be shared among customers and can possibly be allocated to the product development team. It is up to the Field Operations team to decide whether to wait for a new version of the product or to perform the adaptations to the current version in order to fill customer needs. Changes should be designed, specified, implemented and tested. The specification should be performed using unit tests. If it is desired to control all the changes details it can be added to the design document the relevant code changes (e.g class and methods changed, changes to database, triggers, procedures and tables).

Continuous Integration of the code to the repository should happen often and ideally changes should never wait more than one day to be submitted to repository. Each sofware engineer is responsible to integrate their own code and whenever possible break features in logical units. Integration should happen when 100% of the unit tests are successfully execute or when a part of the feature is done. System integration requires functional testing. This means that all the changes that are integrated to the repository have to be fully tested by the software engineers through their unit tests to prevent errors on features that were already tested.

After your system testing proves successful, the customer must perform acceptance testing, a process in which they determine whether the system truly meets their needs This test stage is critical to the success of the system because it is during this stage that you determine if the system is suitable for release to your user community Acceptance tests are created from user stories that are selected in every new iteration and translated to acceptance test. A story can only be closed if all test cases related to it were successfully performed. Test Scenarios are supposed to give guidance during this activities and it can be automated or not. The test results can be reported on a result sheet or on a change control tool. Acceptance tests are also called black box tests and can be used as regression test that precedes release to production environment.