# data[].attributes.body
Scrum Release do Produto é a entrega de um ou mais incrementos do produto prontos, gerados pelo Time de Desenvolvimento em um ou mais Sprints sucessivos, para que sejam utilizados.

Projetos com Scrum realizam Releases frequentes, com intervalos máximos de alguns poucos Sprints entre elas.

A realização de Releases ao longo do projeto tem três objetivos principais: obter feedback frequentemente, prover retorno ao investimento dos clientes e dar um senso de progresso a eles.

Feito por: Mayra Carolina Arantes
Referência:
https://www.gp4us.com.br/scrum-release-do-produto/

# data[].attributes.body
Ao receber uma Release, os clientes do projeto e demais partes interessadas têm visibilidade do estado atual do projeto, isto é, o que já está pronto e o que vislumbram que ainda há a ser feito em direção à Visão do Produto.

A estratégia de Releases do projeto é de inteira responsabilidade do Product Owner, que deve defini-la e, sempre que necessário, modificá-la.

Essa estratégia estabelece, por exemplo, quais dos objetivos entre os descritos acima cada Release busca alcançar, o que inclui a frequência das Releases e quem irá recebê-las.

A estratégia de Releases também garante que as Releases estejam alinhadas com a estratégia de negócios do produto e que sejam tecnicamente viáveis.

Feito por: Luisa Caetano Araújo
Referência:
https://www.gp4us.com.br/scrum-release-do-produto/

# data[].attributes.body
Objetivos: o objetivo de uma Release é entregar os incrementos do produto gerados para serem utilizados. Dessa forma, são definidas funcionalidades a serem entregues em uma data estipulada para que os usuários finais, intermediários ou selecionados do sistema testem o produto e deem um feedback de possíveis melhorias a serem feitas. Além disso, uma Release apresenta aos clientes do projeto e demais partes interessadas uma visibilidade do estado atual do projeto e mostra o retorno dos investimentos realizados por eles.

Quando: as Releases são realizadas frequentemente, quando já se produziu o valor suficiente para ser utilizado. Sendo assim, a frequência de realização de uma Release pode ser definida por valor, por Sprint, por item ou por plano.

Participantes: as partes participantes de uma Release são: o Time de Desenvolvimento e o Product Owner.

Saídas: em uma Release deve ser entregue o produto utilizável e em funcionamento,  ou seja, as funcionalidades que foram estipuladas para aquela Release devem ser entregues e precisam ser funcionais para permitir aos usuários testá-las.

Feito por: Maria Eduarda Leal Silva
Referências:

Rafael Sabbagh – Scrum – Gestão ágil para projetos de sucesso

http://blog.acelerato.com/agile/graficos-burndown-x-burnup/

Scrum Product Owner (Published on Mar 28, 2010)

http://www.slideshare.net/Ridlo/scrum-product-owner

# data[].attributes.headline
4. Classificação das releases em relação a frequência 

# data[].attributes.subject
4. Classificação das releases em relação a frequência 

# data[].attributes.body
As releases podem ser classificadas quanto a frequência com que são realizadas e quanto a quem irá recebê-las. No âmbito de classificação por frequência temos basicamente quatro classificações detalhadas a seguir:

Por valor

Acontece quando o Product owner considera haver um bom valor de negócio no que foi realizado até o momento, podendo assim ser oferecida uma release.

Por Sprint

As releases são oferecidas ao final de cada Sprint, nesse modelo o feedback do usuário vem de forma rápida portanto alterações que melhorem o produto podem ser feitas com maior frequência.

Por item

Os itens são entregues durante a Sprint e avaliados pelo Product Owner como prontos para release ou não.

Por plano

Nesse caso é feito um planejamento para as releases feito normalmente em uma reunião específica para tal. Nessa reunião define-se o tempo que levará para ser oferecida a release, o que ela deve possuir, metas a serem alcançadas até a data da release. O progresso do projeto até a data da release deve ser observado durante as sprints, os gráficos de release burndown e burnup são  ferramentas utilizadas nesse acompanhamento em muitos dos casos.

Feito por: Maria Eduarda Soffiati Alves
Referências:
https://www.gp4us.com.br/scrum-release-do-produto/

https://annelisegripp.com.br/release-planning/

# data[].attributes.body
Finalidade do planejamento
O planejamento da Release serve como parâmetro para que o time tenha uma visão do que deve ser feito, quais recursos serão implementados e quando serão concluídos os incrementos.

Plano de Release
Geralmente é elaborado pelas 3 entidades do Scrum, que são o Product Owner, o Time de Desenvolvimento e o Scrum Master. No plano é indicado o objetivo a ser alcançado pela Release e quando isso ocorrerá. O plano abrange 3 fatores  principais:
- Objetivo de negócios em relação à entrega.
- Meta em relação à visão do produto.
- Data exata ou aproximada de entrega.
Para uma entrega segura e dentro dos prazos estipulados, os itens são desenvolvidos baseando-se no grau de importância e seguindo técnicas de priorização e de estimativas.

Agendamento e duração
A primeira reunião de planejamento de Release acontece antes dos inícios dos Sprints, ou seja, antes do começo do desenvolvimento do produto. É interessante, nesse momento, esperar dois ou três Sprints para se obter mais conhecimento sobre a capacidade de produção o Dev Team. As demais reuniões ocorrem durante o último Sprint da Release anterior.
Não há duração estabelecida para as reuniões de Release, porém é interessante determinar um tempo máximo para as mesmas.

Feito por: Marcus Paulo Oliveira
Referências:
https://www.gp4us.com.br/scrum-release-do-produto/
https://www.infoq.com/br/news/2014/07/estimation-release-planning/
https://annelisegripp.com.br/release-planning/

# data[].attributes.body
Reunião

É identificado dois tipos de cenário para a reunião de Release Planning.
•O primeiro cenário, é dada uma data para Realese, mas não identifica qual a meta a ser alcançada.
•No segundo cenário, é fornecido uma necessidade ou melhor a meta da Realease e pergunta-se quando será possível alcançá-la.
Em ambos os cenários, os itens suficientes do Product Backlog  devem estar estimados para que deem andamento ao planejamento. A partir da data da Realease, dados do product backlog estimados, o tamanho do Sprint e a velocidade do time de desenvolvimento é possível encontrar o conjunto de itens selecionados do Product Backlog e a meta da Realease.

Estimativa

O Product Owner deve verificar o Product Backlog esteja ordenado e  com os itens adequado para atender a essa necessidade. O Product Owner devera somar as estimativas de cada item dada pelo time de desenvolvimento, até considerar que já percorreu todos os itens necessários para atende a demanda de negócios.

OBS.: Essa estimativa é de baixa precisão e deve ser revista em cada Sprint .

Feito por: Maria Fernanda Baêta
Referencia:https://www.gp4us.com.br/scrum-release-do-produto/