O objetivo do Planejamento da Release é fazer o planejamento das customizações que vão ser entregues no próximo release do produto. Este planejamento também pode ser revisado e alterado caso mudem as prioridades do cliente e de acordo com o andamento do projeto. O time de desenvolvimento utiliza as histórias escritas anteriormente para estimar a sua dificuldade de implementação. A prática "o jogo do planejamento" descreve que um release deve conter as histórias que agregam maior valor para o negócio do cliente, ou seja, as de maior prioridade para o cliente, de acordo com as prioridades que o Gerente atribui a cada um dos clientes, e o time de desenvolvimento então estima quantas histórias eles poderão implementar nas diversas iterações do release com base na experiência que possuem sobre a sua velocidade de trabalho e com base nas estimativas de dificuldade de cada história. O planejamento do release deve levar em conta estimativas e fatores de risco. As histórias de alto risco devem ser escaladas primeiramente para amenizar o risco. As histórias de investigação também são consideradas de alto risco, pois pouco se sabe sobre sua implementação, por isso devem ser escaladas nas primeiras iterações.

Neste fluxo de trabalho é onde acontece o planejamento da iteração. Em um único release de um conjunto de features do produto podem ocorrer várias iterações. O planejamento da iteração procura refinar as estimativas feitas no planejamento do release e verificar quantas e quais histórias serão implementadas na iteração. A análise de cada história é realizada como parte de cada iteração. O objetivo da análise de cada história é finalizar o detalhamento da mesma. Cada história é destrinchada em pequenas tarefas e durante esta análise o time pode julgar necessário dividir uma ou mais histórias alocadas para a iteração corrente ou ainda criar uma história de pesquisa quando não houver informações suficientes para estimar a história. O time de desenvolvimento tenta medir o esforço de uma forma mais precisa e melhorar cada estimativa feita anteriormente no planejamento da release. O Gerente de Implantação é que tem a responsabilidade de escolher as histórias a serem implementadas. Todo este processo deve ser orientado pela prática do jogo do planejamento. O engenheiro de software é o responsável pelas estimativas do esforço necessário na implementação de cada história, enquanto o cliente, junto com o Gerente de Implantação, é responsável pela atribuição de prioridades para cada história com base em seu valor de negócio. As prioridades de cada história são definidas com base nas prioridades do cliente e nas prioridades do projeto. Ou seja, os clientes definem suas prioridades e o Gerente decide que clientes têm mais prioridades.

Neste fluxo de trabalho são escritos os testes funcionais do sistema. Os testes funcionais são escritos com base nos requisitos que estão definidos no Documento de Mudanças (CDD). Este documento serve como entrada para a atividade chave deste fluxo de trabalho. Nesta abordagem os testes são escritos pelo Engenheiro de Testes com o auxílio dos Engenheiros de Software. O cliente não participa diretamente da escrita dos testes, pois nestes projetos o tipo de relacionamento com o cliente e a sua localidade normalmente inviabilizam a utilização da abordagem padrão que considera que sempre haverá um único cliente on-site. O produto final deste fluxo é a definição dos Cenários de Testes utilizados para validar as funcionalidades do sistema. Estes Cenários podem ser na forma de testes automatizados ou não. Esta decisão cabe ao time de engenharia. O objetivo dos testes funcionais é testar as funcionalidades mais complexas do sistema, enquanto os testes unitários visam testar métodos de classes.

O desenvolvimento de uma feature compreende as atividades de projeto, implementação e testes de uma unidade de trabalho. No contexto de Customização de Produtos de Software um dos principais objetivos do processo é evitar mudanças às funcionalidades core do produto. Portanto, decisões de projeto que venham a impactar a arquitetura e a lógica de negócios base do sistema devem estar fora do contexto da customização. Quando alterações de base forem identificadas como sendo necessárias, deve haver um consenso entre a equipe de campo e a equipe do produto no sentido de minimizar os esforços individuais para cada cliente. Caso uma nova feature seja identificada como uma necessidade comum que poderá ser compartilhada por vários clientes, a mudança pode ser escalada para a equipe do produto. Cabe à equipe de campo a decisão de esperar por uma nova versão do produto ou realizar uma adaptação na versão corrente para atender às necessidades do cliente. Cada uma das features deve ser desenhada de maneira a minimizar ao máximo grandes mudanças às funcionalidades padrão do sistema. Em seguida as features são especificadas, implementadas e testadas individualmente. A especificação da feature é realizada através de testes unitários. Os esforços devem ser concentrados nas tarefas de maior importância para o cliente. A depender do nível de controle desejado pelo time, pode ser interessante incluir como parte do documento de projeto todas as alterações realizadas no código durante o desenvolvimento da feature (ex. classes e métodos alterados, mudanças na base de dados, triggers, procedures, tabelas, etc.).

A integração contínua do código gerado com o repositório de código deve acontecer com freqüência e idealmente as mudanças nunca devem passar mais do que um dia para serem integradas ao repositório. Cada engenheiro de software é responsável por integrar o seu próprio código e sempre que for possível quebrar a feature em unidades lógicas. Isto deve acontecer quando 100% dos testes de unidade forem executados ou quando uma pequena parte da funcionalidade planejada for finalizada. A integração das funcionalidades compreende a realização dos testes funcionais. Isto significa que as funcionalidades que forem integradas devem estar 100% testadas pelos engenheiros de software através dos testes unitários para evitar que uma nova funcionalidade quebre alguma feature do sistema que já esteja testada funcionalmente.

A intenção dos testes de aceitação é garantir que os requisitos do cliente foram atendidos e que o sistema é aceitável, ou seja, o objetivo deste fluxo de trabalho é verificar se as funcionalidades estão de acordo com as necessidades e expectativas do cliente. Estes testes são críticos para o sucesso da aplicação porque durante este estágio é que será determinado se a aplicação pode ser liberada para os usuários finais. Os testes de aceitação são criados a partir das histórias que devem ser selecionadas a cada nova iteração e traduzidas em testes de aceitação. Uma história só é considerada finalizada quando os testes de aceitação são concluídos com sucesso. Os cenários de teste escritos servem para guiar a realização dos testes que podem ou não ser automatizados. O formato da reportagem dos resultados dos testes é decidido pela Engenharia. Estes resultados podem ser reportados através de uma ferramenta de controle de bugs, como o Bugzilla, por exemplo. Ou em forma de planilha de resultados. O ideal, porém, é uma combinação das duas opções, a utilização da planilha seguida do registro de bugs na ferramenta. Os testes de aceitação, considerados como testes caixa-preta, também são usados como teste de regressão que antecede um release de produção.