Skip to content
ProductManagement.com.br
ProductManagement.com.br

Um lugar aberto à discussão sobre produtos digitais

  • Product Management
    • Product Discovery – Dicas e Passos.
    • O Product Owner e o Business Analyst
    • Refinement Meeting: Por que e como fazer?
    • Visão geral do PO em projeto Ágil
    • Perfis legais para seguir no Twitter
  • Scrum
    • Scrum, o primeiro contato!
    • Ágil. Porque tantas tentativas falham?
    • O Product Owner e o Business Analyst
    • Ágil. Gestão do conhecimento, escopo, documentação, testes, falhas e mais…
    • Scrum. Gestão do conhecimento e mudanças de escopo
    • Ágil. Um pouco sobre documentação de regras, testes e comunicação
    • Refinement Meeting: Por que e como fazer?
    • Refinement Meeting: Respondendo as 6 dúvidas iniciais
    • Características de um bom Product Backlog – DEEP
    • Perfis legais para seguir no Twitter
  • English
    • Agile Product Ownership in a nutshell
    • Agile. Why so many projects fail?
    • Grooming the Product Backlog: Answering 6 initial questions
    • Great profiles to follow on Twitter
ProductManagement.com.br

Um lugar aberto à discussão sobre produtos digitais

Scrum. Gestão do conhecimento e mudanças de escopo

Daniel Baldini, March 5, 2017March 21, 2017

No mundo Lean/Ágil ao contrário do modelo tradicional, o projeto não tem um “conjunto de features pré-estabelecidas” e a partir destas o produto começa a ser desenvolvido visando desenvolver estas funcionalidades.

Tá bom, então como funciona?

A empresa possui a Visão do Produto, que nada mais é do que o problema que aquele produto pretende resolver.

A partir da visão do produto começam a serem feitas as análises para identificar se o produto é viável ou não. Neste momento começam a serem rascunhados: O tamanho do mercado; Quem são os usuários; Como nós imaginamos que ele gostaria que o problema fosse resolvido, etc…

Neste momento começam a surgir as primeiras “ideias de funcionalidades” que são adicionadas ao Backlog do Produto.

O Backlog do Produto nada mais é do que uma lista de itens ordenados por prioridade e ele deve existir enquanto houver o produto. Esta lista deve conter: Histórias de Usuários, Bugs, Tasks(!).

Para o Scrum não existe divisão entre o ciclo de projeto e processo evolutivo.

Tá bom, então como funciona? 🙂

Aqui precisamos falar sobre uma das atividades com duração limitada ou “time box events” do Scrum. O Sprint.*

Segundo o Scrum, o Sprint é um evento de duração limitada que deve ter de 1 a 4 semanas. O tamanho mais comum utilizados é de 2 semanas. Existem alguns parâmetros que devem ser levados em consideração para definir esta quantidade, mas tratarei deste assunto em um outro artigo.

Mas por que precisamos falar disso para tratarmos da divisão de ciclo de projeto ou processo evolutivo?

No caso do Sprint de 2 semanas, a cada 15 dias a equipe de desenvolvimento entrega os itens que foram combinados para aquele sprint e todo o Scrum Team se compromete a entregar um novo conjunto de itens presentes no Backlog do Produto.

Como o Backlog do Produto contém Histórias, Bugs e Tasks(!) que foram priorizadas pelo Product Owner de acordo com a Visão do Produto e com o feedback dos usuários, a cada 15 dias, os itens que trazem mais valor para o negócio entram para serem desenvolvidos. É como se pudéssemos mudar 100% do caminho do produto (escopo) a cada 15 dias.

Para fechar os dois pontos:

  • O conhecimento do produto está todo (passado, presente e futuro) documentado no Backlog do Produto.
  • Não existe mudança de escopo do projeto, existe mudança de prioridade das atividades que entrarão para desenvolvimento no próximo Sprint. Na média, a cada 15 dias.

 

* Usei “o Sprint” pois, para mim, trata-se de um evento e evento é masculino. 🙂 Estranho isso. Se você quiser usar a nomenclatura do Scrum que diz que é uma cerimônia, aí você pode usar “a Sprint”. No final das contas, isso não importa.

Ir para: Ágil. Gestao do conhecimento, escopo, documentação, testes, falhas e mais…

Product Management Scrum

Post navigation

Previous post
Next post

Related Posts

Características de um bom Product Backlog – DEEP

April 6, 2017November 7, 2020

O que é DEEP? DEEP é um acrônimo para: Detalhada, Estimada, Emergente e Priorizada. Originalmente: Detailed, Estimated, Emergent and Prioritised. Esses são alguns conceitos que são usados para definir se o Backlog do Produto (Product Backlog) “está bom”. Claro que para um Produto ser bem sucedido não basta apenas ter um Backlog de Produto…

Read More

Refinement Meeting: Respondendo as 6 dúvidas iniciais

February 25, 2017November 7, 2020

Refinement: Uma palavra e muitas perguntas. Qual é o conceito da ? Qual é o objetivo? Quais são as atividades? Quem participa? Quanto tempo é necessário? Quando fazer? Certamente estas são as primeiras questões que vem à cabeça daqueles que estão iniciando no Scrum quando se fala em Refinement meeting. Vamos às…

Read More

O Product Owner e o Business Analyst

October 3, 2017November 7, 2020

Qual é a diferença entre o Product Owner e o Business Analyst? Esta é certamente uma das primeiras perguntas que surgem quando começamos a estudar o Scrum. Há alguns anos venho me dedicando a isto e devo dizer que levei um bom tempo para encontrar a minha resposta. Poeticamente eu diria que:…

Read More

Últimos posts

  • Product Discovery – Dicas e Passos.
  • Refinement Meeting: Por que e como fazer?
  • O Product Owner e o Business Analyst
  • Características de um bom Product Backlog – DEEP
  • Ágil. Gestão do conhecimento, escopo, documentação, testes, falhas e mais…

Comentários

  • Urânia Reis on Ágil. Porque tantas tentativas falham?
©2026 ProductManagement.com.br | WordPress Theme by SuperbThemes